🇧🇪Belgium @svendecabooter

Related change record: https://www.drupal.org/node/3404140 →

svendecabooter → created an issue.

Thanks for the patch & review. Fixed now.

Merged updates by the bot. Setting back to active in case more changes come in.

Created MR to fix this + attached as .patch file as well.

svendecabooter → created an issue.

Thanks for the suggestion. Updated the behavior name.

svendecabooter → created an issue.

Added this extra check, although Drupal 8 & 9 is no longer really supported by this module.

Merged into 2.0.x
Setting the status to "Active" to let the bot update the MR if needed.

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

This will be postponed until the patch it depends on ( https://www.drupal.org/project/route_condition/issues/3178792#comment-13... → ) is committed.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

svendecabooter → created an issue.

Thanks, merged!

svendecabooter → created an issue.

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

This issue is dependent on 📌 Automated Drupal 11 compatibility fixes for image_widget_crop Needs review

seantwalsh → credited svendecabooter → .

seantwalsh → credited svendecabooter → .

This is probably related to ✨ Usability: let admin choose which email to send Active ?

svendecabooter → created an issue.

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

Thanks for the merge request.

An update hook would indeed be required, to grant all users that currently have permission to resend the email, that new permission.
Or alternatively, we could adjust the access check as follows:

Either you have access via the new permission OR you have access via the current access check logic.

That would avoid automatically adding permissions to users, which is maybe not what all site owners want to happen automatically...

Merged in. Ticket remains in active state, for when new D11 updates would come along.

Probably related to 🐛 Update to OpenID Connect Module 2.0 Fails Due to Missing 'authmap' Table Required by Externalauth Dependency Active ?

It seems the openid_connect module activates the externalauth module within an update hook openid_connect_update_8203() and then migrates over its own authmap data to the externalauth one openid_connect_update_8204().

I'm not sure why upon installation of the externalauth module, the {authmap} table would not be created. It is defined via hook_schema(), and has been there from the start of the module.

I'm really clueless as to why this would happen. Seems it only occurs in combination with the openid_connect module then?
Something must go wrong with installation of the module then, or the schema definition might not have been updated yet by the time openid_connect_update_8204() gets called (some caching issue?)

This does not change the type of the field, but rather the length?
Is there a specific reason the authname should be longer? i.e. compared to the Drupal username field (60 chars), the authname length of 128 is already double.
I don't mind increasing the length, but this would need some more testing with real installations, to make sure this does not break things, as changing database tables always feels a bit risky to me.

Thanks for the analysis roderik.
I have updated the logic for the delete link, to not render if $row->uid is not set.
So the only reason why it would still trigger an error, is if that value is set, but to an empty string for example.

I created a merge request that more thoroughly checks if $row->uid actually has a valid value, and also provides a fallback to the $row->users_field_data_authmap_uid value, since that is indeed more consistent among different module releases, from what I can see.

Can people experience this issue try out this MR fork and see if it resolves the issue for them?
If not, can you double check you are testing the View provided by ExternalAuth, not by the samlauth module?

svendecabooter → created an issue.

Thanks for the MR and review!
Merging this in now. Will leave the issue open though, for new automatic suggestions by Project Update Bot

svendecabooter → created an issue.

svendecabooter → created an issue.

MR added to fix this issue, but making the View optional.
Not sure if this is desired, since it does not add the View to my installation now... still need to figure out if I actually need that View or not.

svendecabooter → created an issue.

Still 2 PHPStan issues to fix - related to 🐛 Unable to move media items due to overwritten rendered entity in the custom media library widget Active

I think it is used for the refresh logic when the modal dialog is closed - see \Drupal\contextual_image_widget_crop\Form\MediaAjaxForm::ajaxCloseDialog().

However, the code is also flawed, in that the $image_style variable is just the last one from the $image_styles array that could contain multiple image styles, so it just randomly picks the last one, from what I can tell.

Will need some extra investigation.

svendecabooter → created an issue.

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

svendecabooter → created an issue.

Ok thanks for the clarification. Misinterpreted the change then.

The MR seems broken since the changes in 📌 Remove dependency on jquery_ui_datepicker Needs work .
JQuery UI datepicker library seems to be removed since release 6.0.6.
So the MR should be updated, to be able to set the desired date format in another way.

Shouldn't the 'datepickers' library (js/bef_datepickers.js) also be removed within this change?
Or am I missing something?

borisson_ → credited svendecabooter → .

borisson_ → credited svendecabooter → .

BramDriesen → credited svendecabooter → .

BramDriesen → credited svendecabooter → .

BramDriesen → credited svendecabooter → .

BramDriesen → credited svendecabooter → .

borisson_ → credited svendecabooter → .

That's weird.

Can you check your database, whether you have records in the authmap table that do not have a numeric value for the `uid` column?
E.g. by running the SQL query SELECT count(*) FROM authmap WHERE uid = ""; and getting a result other than 0?

BramDriesen → credited svendecabooter → .

BramDriesen → credited svendecabooter → .

Thanks justafish, that seems like the correct approach.
I have merged the MR now.

BramDriesen → credited svendecabooter → .

Thanks for catching this regression.
I have added a fix and will create a new release with this fix included.

svendecabooter → created an issue.

Oops pushed this in the 2.x branch instead of in the MR branch.
Pipeline does not seem to run automatically though. Will have to figure out what's wrong.

svendecabooter → created an issue.

This is fixed in 🐛 All role bulk actions hidden due to inconsistent role config/API structure Fixed

Looks good to me. Thanks for the MR!

svendecabooter → created an issue.