readthedocs.org icon indicating copy to clipboard operation
readthedocs.org copied to clipboard

Audit: extend log to cover project actions

Open webknjaz opened this issue 1 year ago • 1 comments
trafficstars

What's the problem this feature will solve?

Yesterday, our RTD project cherrypy disappeared without any trace/notice/notifications. I only learned about that from an external monitoring notification that alerted me that the site is down. I had to go through the whole troubleshooting process, starting from DNS and GH repo setting before I realized that the RTD project is missing from everywhere.

I'd like to be able to trace what happened. Also I submitted a support request but that form doesn't seem to send an acknowledgement so I have no idea if it was received. The https://status.readthedocs.com page shows no outage.

I thought, that maybe I was removed from the project at first, before I realized that its dashboard page returns 404 and it's not listed among the projects of the other maintainer either (who doesn't know what happened as well).

UPD: It turned out one of the former maintainers who's not really involved anymore removed the project as a reaction to many notifications from RTD, without realizing the consequences. So the solution in our case was to tag a bunch of random GitHub handles in hopes to hit somebody who did the deletion and we were lucky enough to find the one.

Describe the solution you'd like

I think that the user-level audit/security log page @ https://readthedocs.org/accounts/security-log/ should also list any events related to individual projects (even after losing access to them), like adding/removing maintainers, setting up integrations, removal. Projects shouldn't just vanish without a trace.

Additionally, e-mail notifications for removals wouldn't hurt.

Alternative solutions

N/A

Additional context

https://github.com/cherrypy/cherrypy/issues/2013

webknjaz avatar Jan 05 '24 16:01 webknjaz

Thanks @webknjaz, these are all good suggestions, down to the root cause which was notifications that didn't seem usable.

I was also thinking that in the case of a project with multiple maintainers, or maybe just all projects, we should handle project removal differently. Projects could be soft-deleted or put in a disabled state for a week before they are actually removed. At least then it would be easy to recover from an destructive change like this.

agjohnson avatar Jan 10 '24 01:01 agjohnson