Hello,
I have reviewed the patch in #8, and I noticed it removes the destination query parameter. I believe this is not the intended behavior, as the destination parameter is essential for the entity edit form and other pages. The language switcher provided by Core operates similarly. it retains the destination parameter.
Patch #5 works well, but there is an additional concern. When the language is changed, the destination parameter retains the old language prefix. So, if a user changes the language on the entity edit form and submits it, the system will redirect to the old language based on the destination parameter. This issue also exists in the Core language switcher.
+1 Facing similar error, I have an eck entity referenced in the user entity, where the eck entity is created on the user register form using IEF. This entity has workflow already attached to it, After using the latest version 1.8, I am getting this error when saving the user register form This value should not be null
#11 worked perfectly, but since we are revoking the permission which is not valid, it would be handy if those permissions are displayed as logs. I have modified patch #11 and added the code that logs the invalid permissions before revoking them.
Hello,
I'm using the 2.1.0 version with Drupal 10.1.7. I'm getting an error on visiting the new form mode (?machine_name).
Warning: Undefined array key "#type" in Drupal\Core\Form\FormHelper::processStates() (line 211 of core/lib/Drupal/Core/Form/FormHelper.php).
Hello, the patch in #5 was not getting applied for 8.x-1.0-rc3 version. Re-rolled the above patch.
Hello, The patch available for lightning_scheduler #33 🐛 Scheduler needs to maintain its base fields properly Needs review was not getting applied to lightning_scheduler as a sub-module. Re-rolled the patch.
Had the same issue, where node_type defined in block configs and block configs were in config ignore. #13 worked successfully. Thanks @smulvih2
Patch #15 and #41 do not get applied for the 4.0.0 version. Re-rolled the patch with the latest changes.
Hey,
Here is the patch.
In the patch, I have added a number field on the config form to configure the number of QA accounts. By default, it has the value of 1. I have also added validation of the QA accounts should not be more than 10 as I guess that will be enough.
Each QA account for example will be uniquely identified as qa_administrator_1. The numerical suffix denotes the count of users per role.
I have also added an update hook to change the existing username to a new username.
Hey,
Here is the patch.
In the patch, I have added a number field on the config form to configure the number of QA accounts. By default, it has the value of 1. I have also added validation of the QA accounts should not be more than 10 as I guess that will be enough.
Each QA account for example will be uniquely identified as qa_administrator_1. The numerical suffix denotes the count of users per role.
I have also added an update hook to change the existing username to a new username.