Updating to v2.0.4 causes authmap view to produce an unexpected error

Automatically closed - issue fixed for 2 weeks with no activity.

Same error with 2.0.5. Only downgrade to 2.0.3 solve problem.

The issue is back after 2.0.5, I can also confirm.

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?

I ran into almost this same exact issue using the samlauth module. There is a merge request with a working fix available in that issue that might help resolve this issue. See https://www.drupal.org/project/samlauth/issues/3424834 🐛 Error encountered when accessing SAML authentication mapping configuration page Needs review .

Observations from a quick test:

• In 2.0.3, the UID is present in two properties: $row->authmap_uid and $row->users_field_data_authmap_uid
• In 2.0.4/5, the UID is present in two properties: $row->uid and $row->users_field_data_authmap_uid
• I did not see errors in any version. Also not when downgrading.

Working theory:

• authmap_uid changed to uid because of the changes to hook_views_data in 2.0.4.
• In hindsight, I didn't delete / re-import the view after updating to 2.0.5. Maybe users only see the error when they 'newly import' the view on 2.0.5? (Or maybe only when they do not do that... if I made some testing mistake?)
• Then again... After looking at the changes @svendecabooter made in his commit linked here (that is part of 2.0.5), It seems very strange to me that anyone would still see the reported error. (A blank field: ...sure, maybe. But not the error. The error would only be present in... the dedicated view that samlauth ships.)
• The two fields in the row are for "the base field" and "the uid field" respectively.
• I guess using "the uid field" for the link is just as good / better, conceptually, than using "the base field". (Which I didn't think of, when initially coding this thing.)
• From that perspective, switching to $row->users_field_data_authmap_uid might be better - especially since it sidesteps the change introduced here.

Also I'm not really sure I agree that 'uid' should be defined 'the base field' in views data, because it's not unique?

But I don't know all this for sure yet; I'm going to postpone looking at the views code (and any possible effects of the views data change on samlauth) to $some_time when I have more time. So I'm also probably not going to commit the samlauth fix until that time. At that point, I'll likely incorporate the 'fortification' that was committed to 2.0.5 here.

(This is just a braindump so I don't forget the details until then.)

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?