Populate the userInfo in the various SearchManagementRepository methods

[epugh]

We support a history of users doing changes in the reporting, but right now that is NOT wired in. This PR adds support.

[epugh]

I disabled BasicAuth, and tested and confirmed we get the Anonymous Search Manager user info in the report!

[epugh]

Now passing userInfo for all the actions

[epugh]

Okay, this is complete! I'd love some review... @mkr would you be comfortable reviewing this PR?

[pbartusch]

Hey @epugh , thanks for the changeset.

I understand, the userInfo will only get extracted when SMUI's BasicAuthAuthenticatedAction is configured. But this method only allows the configuration of one user (no more). As there cannot be a distinctive user responsible for changes, SMUI does not write a username, but instead takes the username configured with toggle.display-username.default (as a display property only). That is the one you're seeing as the 'Anonymous Search Manager' (default), but this can be set to a proper username corresponding to the one configured with BasicAth.

Although, SMUI's CRUD operations should pass the username (like you suggest), it does not really make sense in case of BasicAuth, as there will always just exist one authenticated user for one editing user in the whole system.

Am I missing something here?

[epugh]

Hey @epugh , thanks for the changeset.

I understand, the userInfo will only get extracted when SMUI's BasicAuthAuthenticatedAction is configured. But this method only allows the configuration of one user (no more). As there cannot be a distinctive user responsible for changes, SMUI does not write a username, but instead takes the username configured with toggle.display-username.default (as a display property only). That is the one you're seeing as the 'Anonymous Search Manager' (default), but this can be set to a proper username corresponding to the one configured with BasicAth.

Although, SMUI's CRUD operations should pass the username (like you suggest), it does not really make sense in case of BasicAuth, as there will always just exist one authenticated user for one editing user in the whole system.

Am I missing something here?

So, it did seem to work with BasicAuth, and you got back the anonymous search manager. However, with the username version of the auth, then it did populate.

Longer term, I wonder if we end up deprecating BasicAuthAuthenticatedAction since a big part of the value of SMUI is tracking all the individual users.

[pbartusch]

Yes, you are right. It might be a bit confusing as the userInfo field was introduced a few versions ago, but not used properly. mainly for anticipating multi-user support in the future as this might affect SMUI's data model.

For BasicAuth I can review and add the changes (maybe introducing some additional tests), but then we maybe should think about removing the display username.

I am also in favor of removing support of BasicAuth in a short to mid term. It was introduced for more illustrative purpose in the beginning anyway. But then, the question is where the userInfo will come from, and we are talking about alternative authentication methods suddenly.
I think, it makes sense, to learn more about your use case and setup SMUI is used in. Will DM you.

[pbartusch]

In order to move authentication in SMUI a step forward:

• The changes in this PR will be merged, especially that the userInfo can be used in the ApiController
• I will review the test scenarios, and see if all relevant operations pass the userInfo and if there is a lightweight approach to end-2-end test the new feature.
• I will add a WARN (log) for all history entries, carrying no valid userInfo, to prepare for a migration strategy of <3.14 versions.

fyi: @epugh and @Paul-Blanchaert introduced a comprehensive evolution of the whole authentication (UX & backend) with:

https://github.com/o19s/smui/tree/work_on_admin_screens_for_teams

Thanks for that! This change will ultimately bring userInfo logging for search management activities alive for production cases (as BasicAuth configured with SMUI seems not to be a broadly used feature). As such, I will deprecate BasicAuth with this PR as well. As new SMUI installations & versions should also be integrated with a proper user management, I will also deprecate, the toggle.display-username.default setting.

[pbartusch]

Remotely related: userInfo is currently not logged (or taken into account in the data model) for DeploymentLog events. I created #100 addressing this.

[pbartusch]

Just to create transparency (as @epugh and I had a discussion on that):

I will skip the effort adding tests to ensure None userInfo entities will be handled correctly by the ApiController (and repository respectively) as SMUI should head into a near-term future, in which unauthorized access will not be possible any more.