Improve the Audit Trails views

[MikeAlhayek]

Fix #17105

[Piedone]

These details are already tracked by Audit Trail.

[MikeAlhayek]

So we have a way to view the user object as we do in content? I am not sure.

It's useful to that that info in the user object as we do in contentItems

[Piedone]

This can be useful if the properties are included in UserIndex too, so one can filter/order on them. Without that, I don't see the benefit of duplicating these without the rich contextual info that Audit Trail provides.

[MikeAlhayek]

@Piedone I don't think we should add these info to the UserIndex unless there is a need for it. We don't query against that date.

However, to make this more useful, I added it to the audit trail so that info is more useful over time.

User Event

Content Event

[Piedone]

The last modified, created dates for content items are there for historical reasons (these predate Audit Trail) and because it's useful to query on them. I think it's the same for Users. Why would we just store the same data that's already stored in Audit Trail, and better? And then not make querying available, for which they'd be actually required (for e.g. "list the most recently registered users first" or "list users who registered in November").

Having a separate section for the general Event Info and the specific one below for Audit Trail events is nice, but I don't get why duplicate things for users:

• Created at UTC should be the same as the event timestamp.
• Created by user ID is in the event info.
• The Modified* ones are the same, and we shouldn't display fields with blank values for different events (since there's also a User Updated event, recorded with all the basic details too).

[MikeAlhayek]

@Piedone okay. I dropped the CreatedUtc, CreatedBy, ModifiedUtc and ModifiedBy. Instead, I updated the trail audit views so they are grouped in such a way someone will understand what the values mean. I think with this format, It's easier to determine who did what.

[Piedone]

But why not also keep them, just add them to UserIndex? I do think with that, it's useful (but not without).

[MikeAlhayek]

Why would we inflate a index with data that isn't used?

Also, @sebastienros kinda mention in the meeting today that he is also not a fan of these properties as you originally suggested

[Piedone]

Because querying on users by these is a use case I can imagine being useful. But not insisting on it if we throw out the properties anyway.