If you enable Content Moderation along with the Lightning Workflow transitions, and create a user with permission that can create and edit a specific content type but only allows them to View Latest Version and View Own Unpublished Content, they will be unable to view a new revision for content they did not originally create. Immediately after saving they will be presented with an Access Denied screen.

Here are the permissions said user has:

permissions:
  - 'access content'
  - 'access content overview'
  - 'access contextual links'
  - 'create and edit custom blocks'
  - 'create page content'
  - 'edit any page content'
  - 'use editorial transition create_new_draft'
  - 'use editorial transition review'
  - 'use moderation sidebar'
  - 'view latest version'
  - 'view own unpublished content'
  - 'view page revisions'

The issue appears to be due to the fact that the user cannot view the latest revision because the original content was not authored by them. The fix is to assign them the permission "View any unpublished content", but this is not desirable as they can then access unpublished content for bundles they technically should not have access to.

Looking through the code the offending line may be this:
File: core/modules/content_moderation/src/Access/LatestRevisionCheck.php
Lines: 63-64
Code:

$owner_access = AccessResult::allowedIfHasPermissions($account, ['view latest version', 'view own unpublished content']);
$owner_access = $owner_access->andIf((AccessResult::allowedIf($entity instanceof EntityOwnerInterface && ($entity->getOwnerId() == $account->id()))));

Alter this to be the following so the revision UID is also checked means that this method now returns TRUE for a newly created revision, but the Access Denied message is still returned.

$owner_access = AccessResult::allowedIfHasPermissions($account, ['view latest version', 'view own unpublished content']);
$owner_access = $owner_access->andIf((AccessResult::allowedIf($entity instanceof EntityOwnerInterface && ($entity->getOwnerId() == $account->id() || $entity->getRevisionUserId() == $account->id()))));

I expected the above change to be the only thing needed to get this working, but evidently not. Is this an actual issue or is there an alternative method to get this working without modifications to the code?

Additional People to Credit

There were several issues that had patches that were combined into this one. Additional people to credit, who worked on the other issues:
#3043460: Convert automated_cron module hook_help() to topic(s)
vadim.hirbu
BramDriesen
shwetaneelsharma

#3047585: Convert ban module hook_help() to topic(s)
lisagodare@gmail.com

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the automated_cron, ban, dblog, syslog, system, update, and user modules

Exception: Functionality in the System module that is related to themes should go in #3055055: Convert appearance-related modules: breakpoint, color, layout_builder, layout_discovery, field_layout module hook_help() to topic(s) instead.

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

When accessing Layout Builder overrides via REST (i.e. when accessing an overridden entity's layout field), the contents of sections appear empty.

Proposed resolution

We should add a normalizer for the layout_section DataType, which ensures that sections can be properly serialized and unserialized via the serialization API (and REST).

Remaining tasks

Write a patch, possibly discuss what setting (unserializing) sections looks like via an API like REST.

User interface changes

None.

API changes

A new normalizer will be added for the layout_section DataType.

Data model changes

None.

Problem/Motivation

When the referenced item is deleted targted_id is still present in the reference field, so existing EntityReferenceItem::isEmpty() will return FALSE
This issue causes other functionality to fail. E.g. jsonapi_extras (check child issues).

Proposed resolution

Always check against an entity existense.

Suggested commit message

git commit -m 'Issue #2928906 by amateescu, tstoeckler: The field schema incorrectly stores serial fields as int and is missing keys and indexes'

Problem/Motivation

This was discovered in #2841291: Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field.

The field schema does accurate store the schema of ID fields: Fields that are stored as serial in certain tables are actually stored as int in the field schema of those tables.

Proposed resolution

Move the ::processIdentifierSchema() calls from process*Table() to getSharedTableFieldSchema().

Problem/Motivation

The changes I made to the D7 source while working on #3008028: Migrate D7 i18n menu links caused an unexpected and unrelated error,

[error] Attempt to create a field field_text_plain_filtered that does not exist on entity type node. (/opt/sites/d8/core/modules/field/src/Entity/FieldConfig.php:312)

while running d7_field_instance_label_description_translation migration. That migration should not be trying to save to a field that does not exist and it even has a skip_on_empty to prevent that.

There are several issue already for improvements and fixes to migration_lookup but I didn't see this particular problem there.

  exists:
    -
      plugin: migration_lookup
      migration: d7_field_instance
      source:
         - entity_type
         - objectid
         - type
    -
      plugin: skip_on_empty
      method: row

However, the skip does not skip when the field does not exist. When the field does not exist migration lookup returns an array with 3 elements, all NULL and thus there is no SkipRowException.

Proposed resolution

Option 1) Change migration_lookup to return NULL when all elements of the return array are NULL.
Option 2) Alter all the migration yml that have a migration_lookup where an array of NULL might be returned and that is followed by a skip_on_empty to include a callback process with array_filter. I guess that will work.

Remaining tasks

Write a patch
Add some tests
Review

User interface changes

N/A

API changes

Migration lookup returns NULL instead of an array where all elements are NULL

Data model changes

Release notes snippet

Thanx for this really useful module Alex ;)

...in fact I think it should be in core. Since D8 is a long way still, I'll set this to postponed for the time being.

Problem/Motivation

#253157: Add "Translate own content" permission, rename "Translate content" to "Translate all content" was committed in earlier versions of Drupal 8 which allowed users to translate their own content. However, this feature was later removed from the core and it made https://www.drupal.org/node/1776752 obsolete.

Nowadays, multilingual community sites still have a requirement to allow users to translate their own content.

Proposed resolution

Add a new single global permission, allowing the user to translate any content (entity) that the user can edit.

Remaining tasks

The permission currently looks like:

translate editable entities:
  title: 'Translate editable entities'
  description: 'Manage translations for any entity editable by the user'

Decide if we should rename that to something else instead.

User interface changes

API changes

Data model changes

Background information

[PHP 7.3] Fully support PHP 7.3 in Drupal 7

Currently some tests fail:

https://www.drupal.org/pift-ci-job/1115582

and this should be fixed.

Task: Enable php 7.3.x tests (core maintainer must do this) for issues and commits

Problem/Motivation

Because of #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches Drupal 9 may need to retrieve modules that start with 8.x-.

These maybe compatible with Drupal.

Proposed resolution

1. Do not send \Drupal::CORE_COMPATIBILITY(8.x) in update requests. Replace this with 'all'
2. Determine if more information needs to be returned from the update server to determine if the module is compatible with the current version of Drupal. It may need the new core_dependency key added in #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I noticed that the deprecation warning about defaultTheme links not to the change record, but to the issue. I think it would be more helpful to link to the change record, which has the relevant information in a condensed form, rather than the issue which loads slower because it has over 130 comments, and would require searching for the recommendations.

Three nodes relate to this deprecation, the change record: https://www.drupal.org/node/3083055
and these two issues
https://www.drupal.org/node/2352949
and https://www.drupal.org/project/drupal/issues/3082655

Proposed resolution

Change the node id 2352949 to 3083055 in the deprecation warning.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#597236: Add entity caching to core added the entity cache to core, but unfortunately it did not consider enabling it when loading an entity by revision ID.
There are contrib modules such as Entity Reference Revisions, Paragraphs and core modules such as Content Moderation, which rely heavily on loading entity revisions.

A developer might build a system where she is using ContentEntityStorageBase::loadRevision() to load a default entity revision and by doing so one will currently not profit from the entity cache.

ContentEntityStorageBase::loadRevision() is neither using the static entity cache nor the persistent entity cache, which has as a consequence that the function is inconsistent with ContentEntityStorageBase::load(), as if you retrieve an entity multiple times in a single request with the latter one it will always return a reference to the same entity object, but if you retrieve it multiple times with the former one you will always get a new entity object and thus a completely different object reference.

The attached test demonstrates all the problems.

Proposed resolution

1. Enable static entity caching for ContentEntityStorageBase::loadRevision() for all revisions.
2. Enable persistent entity caching for ContentEntityStorageBase::loadRevision() for all revisions.
3. Ensure that ContentEntityStorageBase::load() and ContentEntityStorageBase::loadRevision() return a reference to the same entity object, if loading the default entity revision.
4. To ensure backwards compatibility $storage::resetCache() will be invalidating all cached revisions. Include an optimization to invalidate only the default revision when the entity has only revisionable fields.

Remaining tasks

Review.

User interface changes

none

API changes

1. \Drupal\Core\Entity\RevisionableStorageInterface::loadRevisionUnchanged() to load an entity revision bypassing the static cache.
2. \Drupal\Core\Entity\RevisionableStorageInterface::resetRevisionCache($revision_id) for reseting the static and persistent cache for specific revision IDs
3. $storage->loadRevision($revision_id) === $storage->loadRevision($revision_id)now evaluates to TRUE
4. $storage->load($id) === $storage->loadRevision($revision_id)now evaluates to TRUE if $revision_id references the current default revision

Data model changes

none

Problem/Motivation

As PHP reuses the object hashes (evil!) it's near impossible to tell two objects apart during a longer session. Content entities have an especially long and complex lifecycle and it'd be quite great if we could tell one another apart.

Proposed resolution

Add a debug id. The cost in complexity, maintenance et al is absolutely negligible.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

My specific use case is that I want to be able to control the output of a collection in a drupal multifield as easily as i can a collection displayed through views and to have the full range of layouts available to collections as there are in views (and paragraphs etc).

use cases: display a multifield entityreference collection in a carousel, tab items, accordians or in any other region defined by a layout.

naive question: can views already do this? Both a view and a multifield are both collections, can views be used to render a multifield?

This does not relate to controlling the layout during entity edit/selection (which entitybrowser does very well) but to the rendered page of multifield collections.

thanks

Problem/Motivation

      @trigger_error('Automatically creating the first item for computed fields is deprecated in Drupal 8.5.x and will be removed before Drupal 9.0.0. Use \Drupal\Core\TypedData\ComputedItemListTrait instead.', E_USER_DEPRECATED);

\Drupal\Core\TypedData\Plugin\DataType\ItemList::get() should include field name/entity type or so in the message, because it's pretty annoying to even track down right now what is causing it.

Proposed resolution

Add more context.

Remaining tasks

Do it!

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

We are now able to create inline blocks from the Layout Builder but they are always set to non-reusable. It would be nice to have a checkbox to decide of the block should be reusable or not, similar to functionality in FPP for Drupal 7. This would allow editors to create reusable blocks while editing layouts for individual pieces of content, rather than having to jump to the "Block layout" section.

Proposed resolution

• Add a "Reusable" checkbox to inline_block plugins in Layout Builder
• If checked, it'll expose an "Admin title" field for naming the reusable block
• Once saved, it'll convert the underlying content block entity to reusable, and convert the inline_block plugin on the Section to a block_content plugin
• Allow editing the content block referenced by block_content plugins, and include a warning that let's editors know that their changes will be reflected globally

Remaining tasks

• Determine if this is something we should tackle in core
• Write tests

User interface changes

• Adds checkbox and admin title field when editing inline_block in Layout Builder:
  
• Adds content block fields and warning when editing block_content in Layout Builder:
  

API changes

None.

Data model changes

None.

Release notes snippet

TODO

Problem/Motivation

In #3084983: Move all the code related to path aliases to a new (required) "path_alias" module the core Path Alias subsystem was deprecated in favor of a new, required, path_alias module. We need to get rid of the legacy code and make the path_alias module optional.

Proposed resolution

Do it

Remaining tasks

TBD

User interface changes

None

API changes

TBD

Data model changes

None

Release notes snippet

TODO

Problem/Motivation

We are in the process of deprecating jQuery UI in core. jQueryUI dialog is among the components that need to be removed/replaced.
As mentioned in the parent issue: #3067261: [Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions
The OpenJS Foundation lists jQuery UI as an Emeritus project in https://openjsf.org/projects/ which is described as:

Emeritus projects are those which the maintainers feel have reached or are nearing end-of-life

This issue was originally proposed as specifically looking for a polyfill, with the following explanation:

dialog.js always aimed at using the HTML5 dialog spec. Chrome just added experimental support for dialogs in it's dev branch: http://demo.agektmr.com/dialog/

We should let chrome use native dialogs when needed, it actually solves a bunch of messy issues, two of which are:
#2072037: Drupal dialog modal background z-index is set too low to reliably occlude core UI components
#1836392: In the Views UI, the interaction pattern of “All displays”/ “Override this display” is confusing

The problems mentioned above should absolutely be considered wile investigating what to use in place of jQueryUI dialog, but the options should be expanded to include different libraries - whatever option can best facilitate removing jQuery UI.

Proposed resolution

Refactor dialog JS to allow use of Native dialogs when available, and do so in a way that provides a consistent user experience regardless of browser. This will double as an effective way to swap libraries in the future, as it requires removing the library-specific assumptions of the current implementation.

Implement the replacement(s) so the dialogs have the same structure/classes as the current jQueryUI implementation. This will allow core to continue using jQueryUI's CSS styles and reduce the overall number of changes that result from this change (desired changes to the styling/structure of dialogs can obviously be done later, it just won't happen here to keep the issue's already-huge scope from getting huger.

Remaining tasks

Refactor JS to provide conditional use of native dialogs -- this implementation should hopefully make it relatively easy to add the replacement library once one is found.

Find a library that meets these requirements

1. Able to open/close dialogs via Javascript. It can't rely on being coupled with buttons or other UI elements.
2. Supports non-modal dialogs (i.e. there has to be the option for the entire page to be interactable even when the dialog is open)
3. Multiple dialogs can be open at the same time, for situations such as adding a custom block in Layout Builder and triggering the media library embed modal via WYSIWYG. They should be able to stack in the order they were opened.

(Chrome native dialogs have been tested and confirmed as meeting these requirements)

The best candidate is currently https://github.com/GoogleChrome/dialog-polyfill -- this meets all the requirements, is actively supported and initial tests/prototypes are promising.

If we are fortunate enough to find multiple libraries that meet these requirements, they should be compared using criteria such as: Code Style, Maturity, Responsiveness, Accessibility, UX, UI, Modularity, etc.

Libraries reviewed so far:

• Tingle - https://robinparisi.github.io/tingle/Missing requirement #2
• Micromodal https://micromodal.now.sh/Missing requirement #2
• Jquery Modal https://github.com/kylefox/jquery-modal : modal onlyMissing requirement #2
• Vex https://github.com/HubSpot/vex : modal onlyMissing requirement #2
• Rmodal - https://rmodal.js.org/ : modal onlyMissing requirement #2
• Van11y dialog https://van11y.net/downloads/modal/demo/index.html - no way to open/close via JS, it's all tied to input elements.Missing requirement #1
• a11y dialog http://edenspiekermann.github.io/a11y-dialog/example/Missing requirement #1
• Nyro modal (jquery) http://nyromodal.nyrodev.com/ : Meets the requirements but hasn't been updated since 2014.
• JqModal http://jquery.iceburg.net/jqModal/#where : Meets the requirements and even has a companion resize library. Hasn't been updated since 2016
• Deque Cauldron pattern library - https://github.com/dequelabs/pattern-library. (Demos at https://pattern-library.dequelabs.com/composites/modals).Missing requirements #1 and #2. Unsure about #3. Reviewed in #26.
• sweetalert2 https://sweetalert2.github.io/: Needs review

.

Libraries to review

• GoogleChrome/dialog-polyfill. Initial review in #12, needs another review to answer all the requirements.
  • repo - https://github.com/GoogleChrome/dialog-polyfill
  • demo page - http://demo.agektmr.com/dialog/

Implement the library

Add additional tests for important dialog use cases that aren't part of existing coverage. Before doing this review Layout Builder's test coverage as it indirectly tests a wide variety of Dialog use cases.

User interface changes

Yes, TBD.

API changes

TBD.

Data model changes

Release notes snippet

Attached is the patched used to make the following work (minus the scrolling element, that's hardcoded CSS).

What needs to be done is making sure our API can handle native dialogs when available and that pretty much means we need to not use jQuery UI or in a very different way than today to avoid wildly different UX between native and polyfill.

When you create a required single-value entity reference field, for example a term reference, then the referenced entity is deleted, the _none option disappears. When the widget is loaded up it defaults to the first option in the list, and the user can easily save the new value without noticing. Steps to reproduce below.

1. Install Drupal with the standard profile
2. Change the Tags field to Required, Allowed number of values to 1
3. Change the Tags widget to Select list
4. Create two terms in the Tags vocabulary, "foo" and "bar"
5. Create an article node, set the Tags field to "foo"
6. Delete the "foo" term
7. Edit the article node, the widget now has "bar" selected
8. Save the article node

I believe this tracks back to OptionsSelectWidget::getEmptyLabel() which checks for !$this->hasValue. It doesn't consider whether the stored value is actually present in the available options.

Problem/Motivation

This is step one of #3087227: [META] Split up and refactor MediaLibraryTest, to make the very large and disruptive MediaLibraryTest more manageable and docile.

Proposed resolution

Split MediaLibraryTest into several smaller tests that make sense, sharing a common base class containing helper methods. The actual testing business logic should NOT be changed in this issue.

Remaining tasks

The thing I just said.

User interface changes

None.

API changes

None. MediaLibraryTest is not an API.

Data model changes

None.

Release notes snippet

None.