Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Generalize the taxonomy module's TaxonomyIndexTid plugin to be available for all entity reference fields and migrate the existing taxonomy filters to be based on the new generic filter plugin.

How to use

1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
2. Create a view displaying this entity type.
3. Add a filter on the view for field_test_reference.
4. Configure the entity selection mode and the widget display mode.
5. Configure the filter behavior (ex: required, multiple, etc.)
6. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Remaining tasks

• ☑ support for content entity reference
• ☑ support for configuration entity reference
• ☑ support for content with and without bundles
• ☑ taxonomy filter rebased on generic entity reference
• ☑ settings forms to configure the filter
• ☑ display widget in select or autocomplete
• ☑ filter values based on reference view
• ☑ filter values based on bundles
• ☑ maximum filter values in select list for performance concerns
• ☑ sort for filter values when in bundle selection handler mode
• ☑ argument support for when view selection handler is used
• ☑ views configuration schema update
• ☐ existing configuration migration
• ☐ fix select option (#208, #215)
• ☑ tests

Post tasks

• ☐ conversion of the "authored by" filter to use the entity reference filter
• ☐ extract selection handler form logic in separate plugins that will specialize for rendering and validating the filter selection config form
• ☐ caching of the value form?
• ☐ documentation updates

User interface

Known issues

• CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
• FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
• FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

API changes

None.

so, I just updated to 8.7.8, and the fixed 3021452 issue is persisting for me. I see a title is provided for my example youtube video.

VIDEO: https://www.youtube.com/watch?v=6X8f9CLBoB8

EMBED JSON URL: https://www.youtube.com/oembed?format=json&url=https%3A%2F%2Fwww.youtube...

EMBED JSON:

{
    "provider_url": "https://www.youtube.com/",
    "author_name": "The Four on KTVU",
    "height": 270,
    "thumbnail_height": 360,
    "provider_name": "YouTube",
    "author_url": "https://www.youtube.com/channel/UCHTnUyoYpA4txfWEVoY1Ysg",
    "width": 480,
    "version": "1.0",
    "html": "<iframe width=\"480\" height=\"270\" src=\"https://www.youtube.com/embed/6X8f9CLBoB8?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen></iframe>",
    "thumbnail_width": 480,
    "thumbnail_url": "https://i.ytimg.com/vi/6X8f9CLBoB8/hqdefault.jpg",
    "type": "video",
    "title": "New Sensor Network Reveals Telltale Patterns in Neighborhood Air Quality"
}

GENERATED IFRAME IN RENDERED DRUPAL 8.7.8 PAGE:

<div class="embed-media embed-media--video-youtube">
<iframe src="https://www.youtube.com/embed/6X8f9CLBoB8?feature=oembed" allowfullscreen="allowfullscreen" width=" 480" height="270" frameborder="0"></iframe>
</div>

I've even tried deleting the iframe and re-creating it. No luck. The title just doesn't get appended to an attribute in the <iframe> tag.

My CKEditor Media Embed module is configured to use Provider Url: //noembed.com/embed?url={url}&callback={callback}, which does show an iframe without a title, but does include the title data in the json:

GENERATED IFRAME URL: https://noembed.com/embed?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%...

EMBED JSON:

{
    "html": "\n<iframe width=\" 480\" height=\"270\" src=\"https://www.youtube.com/embed/6X8f9CLBoB8?feature=oembed\" frameborder=\"0\" allowfullscreen=\"allowfullscreen\"></iframe>\n",
    "version": "1.0",
    "height": 270,
    "thumbnail_url": "https://i.ytimg.com/vi/6X8f9CLBoB8/hqdefault.jpg",
    "thumbnail_width": 480,
    "title": "New Sensor Network Reveals Telltale Patterns in Neighborhood Air Quality",
    "author_name": "The Four on KTVU",
    "url": "https://www.youtube.com/watch?v=6X8f9CLBoB8",
    "width": 480,
    "provider_name": "YouTube",
    "thumbnail_height": 360,
    "provider_url": "https://www.youtube.com/",
    "type": "video",
    "author_url": "https://www.youtube.com/channel/UCHTnUyoYpA4txfWEVoY1Ysg"
}

If I am missing something about how the 13282573 fix is supposed to work, can someone please walk me through it?

P.S. My Basic HTML editor has the title attribute enabled for iframes, so I doubt its being filtered out (and wouldn't expect it to be anyways):

P.S.S. For what it is worth, I have also tested using iframe.ly as the source and also am not getting a title in that case.

<iframe src align frameborder height width scrolling type title bgcolor allowtransparency>

The new version of Coder - 3.7 - dropped the Drupal.WhiteSpace.OperatorSpacing in #3082623: Is it still necessary to override OperatorSpacingSniff? however it is still used in phpcs.xml.dist by core.

Proposed resolution

Replace:

<rule ref="Drupal.WhiteSpace.OperatorSpacing"/>

by:

<rule ref="Squiz.WhiteSpace.OperatorSpacing">
    <properties>
      <property name="ignoreNewlines" value="true"/>
    </properties>
  </rule>

Problem/Motivation

The actual password reset mechanism exposes a user enumeration security vulnerability defined as Testing for User Enumeration and Guessable User Account (OWASP-AT-002) by OWASP - Open Web Application Security Project.

When resetting the password, the actual status messages displayed to the user, depending if the user exists and is active, are:

1. The username (or Email) belongs to a valid and active account: Further instructions have been sent to your email address..
2. The username (or Email) belongs to a blocked user: %name is blocked or has not been activated yet.
3. No account exists for that username or Email: %name is not recognized as a username or an email address.

The last 2 cases are helping a potential attacker, that is doing a user enumeration, to restrict the list candidates and identify usernames or user Email addresses that are real active users (as well as blocked users).

Along with the security aspect comes also the privacy side. Think of the following scenario:

Alice wants to check if her fiancé Bob is registered at "adult-dating.example.com", a well known Internet dating site run by Drupal. She visits adult-dating.example.com/user/password and enters his mail address bob@doe-family.example. If she gets the message "Further instructions have been sent to your e-mail address.", she'll know that there is a user registered with Bobs mail address (= Bob himself) or with a username matching his mail address (unlikely that it would be someone else).

Proposed resolution

Always show Further instructions have been sent to your e-mail address.

[to be discussed] Maybe we should change the wording of this message then (adding something like "if matched any account").

Remaining tasks

None.

User interface changes

Same message regardless the user exists, is active or blocked.

[to be discussed] Make the message configurable.

API changes

None.

Data model changes

None.

Problem/Motivation

Currently claro_preprocess_field_multiple_value_form() assumes the table header structure created by template_preprocess_field_multiple_value_form(). But other extensions may change the structure of it (e.g. by adding sub-items in that particular cell). , The Paragraphs module e.g. does this for its action buttons in the table header. This has been no problem yet, because its preprocess hook was last in line, due to the fact, that the other core themes did not implement one on their own.

With Claro as the new admin theme though, this acts on top of the changes the Paragraphs module makes and reverts it back to the "default" structure for adding its custom CSS class on the field label.

Proposed resolution

• Discuss where to fix this issue. There are several locations that might need some changes for this:
  • template_preprocess_field_multiple_value_form() which might add the label with a dedicated key as a sub-item of the data property of the cell (so others can easily work on it)
  • claro_preprocess_field_multiple_value_form() which should be take in mind, that other contribs may change the structure of the table header cell's variable structure
  • paragraphs_preprocess_field_multiple_value_form() which may be tried to be moved to the end of the chain to work with the variable structure as usual... or a completely different approach may also be used?!

Remaining tasks

TBD

User interface changes

n/a

API changes

• A potentially new variable structure for the table header cell, if a solution is chosen that changes the structure on core level

Data model changes

n/a

Release notes snippet

n/a

Problem/Motivation

#2757007: Convert all book web tests to BrowserTestBase uses a method for this, but I believe it should be added to WebAssert. I've already seen similar implementations in contrib.

Proposed resolution

Add the method to WebAssert.

Remaining tasks

• Search for @todos connected with this issue and update to use new assertions.

User interface changes

API changes

Testing additions.

Data model changes

Problem/Motivation

To stick to the design system approach for claro the implementation for components should stick to predefined variants.

Proposed resolution

Since Add support for Dropbutton variants (3057581) is moved forward claro can rely on it.

Remaining tasks

- Test patch
- Figure out how to solve views display settings: https://git.drupalcode.org/project/claro/blob/8.x-1.x/claro.theme#L435

Problem/Motivation

When creating or modifying a translated date format which uses the abbreviated month name (M), the translations (Jan, Feb, Mar, etc.) will not use the 'context' related interface translation.

For example, the French interface translation for 'May' should provide two source strings; May and May with context: abbreviated month name. Assume we translate May to peux and May with context to mai. All content date fields which uses the date format with the abbreviated month (M) will display the month of May as peux when it should be mai.

Steps to reproduce:

1. Clean drupal 8.6.1
2. Modules: Language, Configuration Translation, Content Translation,Interface Translation
3. Install second language (example; French).
4. Allow content to be translated (and date field). /admin/config/regional/content-language
5. Date and time format; add custom medium date with abbreviated month (M). For example: Name=shortened_medium_date Format String= M d, y/admin/config/regional/date-time
6. Add a French translation for the custom medium date. For example: Format String= d M, y/admin/config/regional/date-time/formats/manage/shortened_medium_date/translate
7. Update language translations (French). /admin/reports/translations
8. Using Interface Translation, search French Language for 'May' and set May to peux and May with context: abbreviated month name to mai. /admin/config/regional/translate
9. Modify basic page, add a date or timestamp field, and set the field display to the custom medium date format created in step 5.
10. Create new basic page content and set date field to May 1, 2018.
11. Translate the new basic page to French and set date field to May 1, 2018.
12. View the new page with /fr/. The date should be 1 mai, 2018 but it will be 1 peux, 2018.

Proposed resolution

Modify the DrupalDateTime format function to set context = Abbreviated month name when code = M.

Remaining tasks

• Create patch. (Done)
• Test.

User interface changes

none

API changes

none

Data model changes

none

Original report by [username]

none

Problem/Motivation

Opening the Drupal 9 branch allows a few things to happen.

1. We can upgrade Drupal's PHP requirements to require Symfony 4 or higher (and Twig etc.)
2. Contrib modules can test against the Drupal 9 branch to ensure they still work
3. We can begin removing deprecated code, and backwards compatibility layers

In order for the Drupal 9 branch to be useful, we need to be able to do the below things soon after the branch is opened.

Proposed resolution

The 9.0.x branch opened alongside 8.9.x according to the normal release schedule.

Must-haves prior to tagging Drupal 9.0.0-alpha1

1. DONE: Contrib modules must be able to test against Drupal 9 without having to make an entire new code branch. #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches and #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning enable this
2. DONE: Make 9.0.x installable without depending on the core compatibility constant and resolve any other test failures: #3087874: [meta] Make 9.0.x branch pass testbot
3. DONE: #3079791: Bump Drupal's minimum PHP version to 7.2 as soon as 9.0.x is branched (a higher version may be required later)
4. Update Drupal's major PHP dependencies:
   1. DONE: #3088369: Update Drupal 9 to Symfony 4.4-dev
   2. DONE: #3094007: Update the 9.0.x branch to Symfony 4.4-beta2
   3. DONE: #3088754: Update to Drupal 9 to Symfony 4.4.0
   4. DONE: #3041076: Update Drupal 9 to Twig 2
   5. DONE: #3094146: Update Drupal 8 to the latest stable/compatibe Symfony 3.x versions
5. Remove deprecated dependencies:
   • DONE: #3087685: Remove deprecated jQuery UI components and fork remaining source code into core
   • DONE: #3067216: [meta] Deprecate (in 8.8) and remove (in 9.0) polyfills that are no longer needed
6. DONE: #3016471: Make localization file download major version agnostic
7. #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

Once these issues are resolved, a Drupal 9 branch becomes useful, because it allows for contrib testing of the upgrade path and updated dependencies. The release notes for the alphas will specify that deprecated code has not yet been removed entirely and that any use of deprecated code by contrib/sites will be incompatible by beta1.

Requirements for beta1 are at #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1.

Should-haves

• #3094007: Update the 9.0.x branch to Symfony 4.4-beta2
• #3073936: [policy, no patch] Policy for Drupal 10 deprecations
• #3075954: Remove duplicate scaffold files
• #3091418: Update composer dependencies on 9.0.x

Remaining tasks

User interface changes

API changes

Data model changes

First issue:
When using a list field as an exposed grouped filter with the checkbox to remember selections, I get the following error: "An illegal choice has been detected. Please contact the site administrator.":

Filter settings:

Second issue:
When using a Boolean field as an exposed grouped filter with the checkbox to remember selections, I get the following error: "An illegal choice has been detected. Please contact the site administrator.":

Steps to reproduce:
- Import configs
- Add 6 nodes with filled fields (list_field_test: 2(Nodes) - Active, 2 - Inactive, 2 - Locked and test_status: 3 - Published, 3 - Unpublished)
- Go to path /test_list_view
- Select filters:
List Field Test (Inactive), Test Status (Not Published)
or
List Field Test (Inactive), Test Status (- Any -)
- Submit search
- Go to any path
- Again go to path /test_list_view

In different variations of the search query - we get an error:
An illegal choice has been detected. Please contact the site administrator.

Problem/Motivation

Drupal's theme system does not support tables with more than one row of table headers. Browsers support rendering multiple table headers and it can be useful for grouping/hierarchies of table header cells.

The idea of this feature request is to let users build table via the FAPI just as it was until then, but also to allow them to add one more depth level and let them build complex table header.

Further info:
http://jsfiddle.net/7pDqb/
http://stackoverflow.com/questions/18680044/how-can-i-construct-a-table-...

Proposed resolution

Update template_preprocess_table() method to let analyse headers with one more depth level, in a backward compatible way.
Update all table.html.twig files to reflect this change and support multiple rows of table headers.
Build a test to show the new feature and keep existing table test to show it's backward compatibility.

This would result in the ability to create this kind of headers via FAPI:

Remaining tasks

Design a solution and implement it.

User interface changes

none.

API changes

'#type' => 'table' FAPI element will support multiple row headers, that means the 'header' key would allow a one more depth level.
It may request another speical key to be achieved, but the exact API changes have to be discussed during implementation.

Problem/Motivation

Related to #2313075: Allow users to upload webp files in image fields

Since webp is becoming popular, it would be nice if contrib could change the supportedTypes of GDToolkit without needing the extend the class, or even better add support for WebP out of the box.

PS: PHP 5.5 has build in support for WebP and since PHP 5.4 will be abandoned somewhere in 2015, it might be easier to just add support for it.

Proposed resolution

@todo

Remaining tasks

User interface changes

@todo

API changes

@todo

Data model changes

@todo

Release notes snippet

@todo

Problem

• WSOD. No error. Nothing.

Cause

Symfony\Component\HttpKernel\Kernel.php:

    public function init()
    {
        if ($this->debug) {
            ini_set('display_errors', 1);
            error_reporting(-1);

            DebugClassLoader::enable();
            ErrorHandler::register($this->errorReportingLevel);
            if ('cli' !== php_sapi_name()) {
                ExceptionHandler::register();
            }
        } else {
            ini_set('display_errors', 0);
        }
    }

Details

• index.php calls
  

  $kernel = new DrupalKernel('prod', FALSE);
  

• The second argument is $debug, tacked onto $this->debug by the Kernel's constructor.
• The rest is visible in the pasted snippet above.

node.module, line 1505
The node_permission() function defines permissions: e.g. "View published content" with the machine name "access content".

I'm guessing that "access content" is legacy, and "View published content" is much clearer for a site admin. However it's a little confusing for (new) module developers that the displayed permission names don't match what you need to put in the access arguments array.

Maybe the official names could be displayed alongside in the Permissions page when the two values differ? Or the proper values could be listed in the API/documenation.

When creating new content, only the title is displayed.
Already uninstalled modules, which could cause this problem.
Body is turned on in content type display.
When displaying Teasers with views, you can see the content.
When choosing Default for the view, only title is been shown.
When I click the preview button, before saving, I can see the content on the page.

Website fistly encountered a "missing filter-plugin: Filter_Null error" on the logs page. This problem was solved by opening php filter and saving it. Now no error is logged...

Do you have any ideas for the solving problem? Problem started after updrading from 8.7.0 to 8.8.0.

Problem/Motivation

I try to post a comment using jsonapi and simple oauth module.
I use a user with 'post comments' permission.

If i add the user relationship to the comment, i got this 403 error :

The current user is not allowed to POST the selected field (uid). The 'administer comments' permission is required.

But if i remove the user relationship, the comment is created with anonymous user as author (not with the current logged user)
Did i miss soemthing ? Is there a way to post a comment with my current user ?

Thanks for you help

Experimenting with wysiwyg media embedding with 8.8.0-rc1 and finding that with basic_html, I do not see an edit button for controlling alignment and choosing view modes.

The problem appears to be something in my setup, as a clean install on simplytest.me works as expected. However I have discussed the problem on Slack with someone else having exact same difficulty. @phenaproxima also suggested on Slack that a bug could not be ruled out.

In the console I see a js error as below.

Uncaught TypeError: Cannot read property 'insertBeforeMe' of null
    at h._setUpEditButton (plugin.js?t=q1mipb:242)
    at plugin.js?t=q1mipb:174
    at Object.success (plugin.js?t=q1mipb:320)
    at c (jquery.min.js?v=3.4.1:2)
    at Object.fireWith [as resolveWith] (jquery.min.js?v=3.4.1:2)
    at l (jquery.min.js?v=3.4.1:2)
    at XMLHttpRequest.<anonymous> (jquery.min.js?v=3.4.1:2)

I do have some contrib modules and also some ckedititor plugins at work on my node edit forms, but I have disabled these as well a quite a number of contrib modules, to no effect.

This may be due to a conflict with other filters. Per @catapipper in #11:

I narrowed down the issue. If you have Convert line breaks into HTML (i.e.
and

) enabled for the text format then it throws the error. If it is not enabled the edit button shows up and works just fine. As to why this is conflicting with that particular setting, I couldn't tell you. Although I have checked this with multiple different text formats and several of our platforms and this seemed to be what the issue was for us.

After upgrading Drupal from version 7.67 to 7.68 it started to show a plenty of the messages below. I am currently using PHP 7.3.9-1.
At https://www.drupal.org/project/drupal/releases/7.68 we have "This is the first release to fully support PHP 7.3. Please test and report any bugs in the issue queue.". So I am reporting this and expecting some help.

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in include_once() (line 24 of /var/www/website/sites/all/modules/webform2pdf/webform2pdf.install).

Notice: Undefined property: stdClass::$uri in theme_file_link() (line 783 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$uri in theme_file_link() (line 803 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in theme_file_icon() (line 849 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 893 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_map() (line 936 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in theme_file_link() (line 815 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filesize in theme_file_link() (line 815 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filename in theme_file_link() (line 821 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$uri in theme_file_link() (line 783 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$uri in theme_file_link() (line 803 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in theme_file_icon() (line 849 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 893 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_map() (line 936 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in theme_file_link() (line 815 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filesize in theme_file_link() (line 815 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filename in theme_file_link() (line 821 of /var/www/website/modules/file/file.module).

Thanks in advance.

Problem/Motivation

In #3094304: Create tests that cover contrib non-full releases and contrib patch versions we realized that \Drupal\Tests\update\Functional\UpdateCoreTest::testNormalUpdateAvailable()
Does have support for the current major and the next both being supported.

\Drupal\Tests\update\Functional\UpdateCoreTest::testMajorUpdateAvailable() in test cases the current major version is not supported.

Proposed resolution

Update \Drupal\Tests\update\Functional\UpdateCoreTest::testNormalUpdateAvailable() with this test coverage.

#3094304: Create tests that cover contrib non-full releases and contrib patch versions has a version for contrib that we can work from

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

n/a

Problem/Motivation

The 'not in' operator of the ModerationStateFilter uses an OR conjunction, so when more than one filter value is selected, the query reads 'not in VALUE1 OR not in VALUE2'. Since the moderation_state only has a single value, it's bound not to be in one of those, so the condition returns FALSE for all entities.

Proposed resolution

The 'not in' operator should use the 'AND' conjunction.