🇮🇳India @ranjith_kumar_k_u

Lendude → credited ranjith_kumar_k_u → .

Added test, please review

The variable $term is initialized at the first part of the function and after that, we made some updates to that term through UI, so the following code
$term->setUnpublished()->save();
is updating the term to the previous state and that is also causing failure to the tests after this, so that is why the code is updated like this

    // Unpublish the term.
    $this->drupalGet('taxonomy/term/' . $term->id() . '/edit');
    $this->submitForm(["status[value]" => 0], 'Save'); 

ranjith_kumar_k_u → made their first commit to this issue’s fork.

Hi, I updated the tests, I hope this will be enough

Change record - https://www.drupal.org/node/3373587 →

smustgrave → credited ranjith_kumar_k_u → .

Added upgrade path and test, please review

There was an error with the functionality, so fixed that error and added tests.

The current MR was created against 9.5x and I don't have permission to edit the MR , so created patch

Added upgrade path and test, please review

Updated the tests.

ranjith_kumar_k_u → created an issue.

Hi, the last patch was failing tests due to the following issue https://www.drupal.org/project/drupal/issues/3039185 🐛 Allow field blocks to display the configuration label when set in Layout Builder Fixed , now that issue has been fixed on 10.1x and 11x, So here last patch tests are passing now.

Hi, In your example the view(content) has exposed filters so which is why exposed variables are added to the "more link" and this came from the following code

    // Merge the exposed query parameters.
    if (!empty($this->view->exposed_raw_input)) {
      $url->mergeOptions(['query' => $this->view->exposed_raw_input]);
    }

on the getMoreUrl() function.

In our tests, we are testing the following view test_display_more and this doesn't have any exposed filters. So It only returns the following result
ie: node/[view:id] => /node/test_display_more

ranjith_kumar_k_u → made their first commit to this issue’s fork.

Added one more condition to the existing fix($field_type === 'boolean') and also added tests, please review

Removed some unrelated changes and added new tests

Created a change record - https://www.drupal.org/node/3367586 →
updated issue summary with before and after screenshots

Added tests, please review

@PrabuEla please ignore this issue, this is my testing environment

Attached patch for 11.x

Addressed #47, please review

Added tests, please review

we added radio option values as 0 and 1 and also there is type casting in the default value section as well as the saving part, so no upgrade is needed for the existing sites.

Added tests, please review

Added text "User not found" instead of "/" and also updated the tests.

Addressed #11, I didn't make any changes on 11.1.

this feels kind of artificial
do we have any details of how this bug can be encountered by correct use of APIs?

We can't reproduce this bug by using correct node deletion methods (programmatically($node->delete()) or deleting the node through the interface), I'm not sure about the migration part

Added tests, please review

Added tests, please review

Added tests please review

User interface changes

do we need any meaningful text here instead of "/"?
or empty?

The bookTreeAllData() internally uses the doBookTreeBuild() function, so if we do not provide the $min_depth then doBookTreeBuild() will consider min_depth as 1.

There were no tests for the bookTreeAllData() function.

Created a change record - https://www.drupal.org/node/3361444 →

Resolved the merge conflict

Fixed test failures and added new tests, please review

Added test to show the issue, please review

I have removed unrelated code changes on the previous patch and added tests, please review

The above patch fixed the problem in the "Default value" section but introduced a problem to the content-adding section.
The "Add another item" button is not working on the first click, added screen recordings below.

Note: The problem only exists in the content-adding section, not in the "Default value" section.

The date format value in the error message is a dynamic one(The Field_label date is required. Please enter a date in the format 2023-05-10 05:19:38.), and the date format value is created on the basis of when the validateDatetime function is calling.

So I have added one more assertion to verify date format value is not empty and is in the following format "YYYY-MM-DD HH:MM:SS".
$this->assertMatchesRegularExpression('/^(\d{4})-(\d{2})-(\d{2}) (\d{2}):(\d{2}):(\d{2})$/', $arguments['%format']);

Added tests, please review