Log who created and last updated partners, users and calendars

kimadactyl commented 5 months ago

User story

As PHT, we need some basic record keeping about who created partners and users in order that if there's any kind of incident we can work out who we need to talk to about it.

As an organiser, I want to be able to see who has created and edited partners in my partnerships, in order that I can work with that person instead of cross purposes.

Created as part of the cycle 29 scoping workshop

Acceptance criteria

[ ] Partners store which user created them, and when
[ ] Users store which user created them, and when
[ ] Calendars store which user created them, and when
[ ] Partner creation and last updated info is visible in the admin interface to anyone who can view the partner
[ ] User creation and last updated info is visible in the admin interface to anyone who can view the user
[ ] Calendar creation and last updated info is visible in the admin interface to anyone who can view the caldendar
[ ] Deleting the user that created a partner, calendar or user doesn't case everything to break
[ ] Bonus: it's possible to see this info in the partner, calendar and user index (appreciate this will take a rethink of what columns are visible though so maybe easier to skip until we have a feature like togglable columns ready to go)

Implementation notes & questions

Previously I think we were tracking this with the paper_trail gem.

Do we need this for calendars too? We may not but seems weird not to do it for completeness?

This is being done as a stopgap until we can resolve this fully https://github.com/geeksforsocialchange/PlaceCal/issues/2256

Implementation plan

To be written by the developer

ivan-kocienski-gfsc commented 5 months ago

Seems like this approach may be helpful here.

Create a model ActivityLog that stores the actions (create, modify, (delete?)) and then "log" activity in the controller.

Root users can then pull up a Partner, Calendar, Site etc. and see who did what when.

kimadactyl commented 5 months ago

Hmmm that sounds like a lot of interface to me compared to adding fields to our existing models? I do like it though that makes a lot of sense. Just sounds like a load of work.

Another option would be to just use Rails.logger to just make a regular text log file?

katjam commented 5 months ago

This probably needs a couple of heads together to come up with a minimal effort set of first steps AC. The use case that has come up most recently is for a partnership admin to be able to see a list of the partners they recently added, so the text logs wouldn't be sufficient. If we wanted to implement this for infosec compliance then we'd probably need to work out a comprehensive & consistent logging strategy and to implement log rotation on server or they'd fill up pretty fast.

So, we maybe need to get back to considering what the actual urgent problem is that we are trying to solve.

kimadactyl commented 5 months ago

OK I think roughly in order for me:

As PHT, we need some logs of who is adding people in case a partner gets funny with us and we need to work out what happened (i.e. so we can fulfill our duties under privacy / tos). Or if a partner turns out to be nasty/bad and we need to remove them, which will require knowing who added them so we can address it properly.
As PHT, we need to see who is active and adding partners so we can support them properly reviewing them as they go up (checking for new calendar formats, checking for errors and seeing how people are using it, stuff like that)
As organisers, they need to not be working cross purposes and see if someone else is editing partners that are in more than one partnerships (i.e. prevent people having an edit battle without realising, or worse have things edited without them realising)
As organisers, it's really helpful to see if a partner themself has made the changes or another organiser
As partners, its important to have a receipt if an organiser has changed your listing

katjam commented 5 months ago

It's too late in the day to do any new feature - but as an minimum we could log out messages on create and edit of whichever models we care most about (partner?).

Partner [id] created by User [id]

This seems the most minimal thing we could do to at least have a record that we can look at if we need to - but it also feels like the least useful to our users.

ivan-kocienski-gfsc commented 5 months ago

Dokku wraps Rails in a stateless container so logging is not written to a file but handled by dokku (plugins?) or a third party log persistence facility

See the docs.

kimadactyl commented 5 months ago

It's too late in the day to do any new feature - but as an minimum we could log out messages on create and edit of whichever models we care most about (partner?).

Partner [id] created by User [id]

This seems the most minimal thing we could do to at least have a record that we can look at if we need to - but it also feels like the least useful to our users.

I think this will knock the first one off the list and sounds good - at least we have the potential to audit what's happened if something goes wrong! It should also be really quick to implement using just Rails.logger

Dokku wraps Rails in a stateless container so logging is not written to a file but handled by dokku (plugins?) or a third party log persistence facility

It can log to the existing persistant storage device too, don't think this should be an issue?

https://dokku.com/docs/advanced-usage/persistent-storage/

geeksforsocialchange / PlaceCal