Tracking: TODOs `src users prune`
Closed this issue · 7 comments
This is a tracking issue for the forthcoming src users prune command: #826
TODOS
- Add an email functionality to email removed users, open vim editor like in git commit
- Write json file containing users to be deleted, last active usage, site-admin status, and emails. This is so that admins can potentially do their own programmatic analysis around who would be removed before removing users
User feedback:
- provide -dry-run option which outputs the list of users to be deleted (this may be addressed by the json output bullet)
- provide an input method for users to specify a list of users explicitly not to be deleted
User feedback (from account #8247)
- Allow users to pass a value <60 via the
-daysflag (customer in question does clean-up every 2 weeks)
Hey @hopkinscl the 60 days constraint was a condition to release this provided by @ryphil -- originally rhe command allowed any value for days, but the idea was to prevent admins from using this too frequently. Happy to change that if its not a major concern.
Opened an issue to inform on gateway timeout problem, and track improvements planned in this area: #848
- Move away from use of
usageStatisticsgraphQL endpoint to use of the newaggregated_user_statisticstable:
sourcegraph/sourcegraph#40301
Currently users who have never been active or have not been active for 93 days will have a null value for lastActiveTime in the graphQL userStatistics endpoint this causes difficulties and confusion in the cleanup script
event_logs only stores a record for 93 days and lastActiveTime is determined from the last event_logs entry associated to a user -- lastActiveAt is recorded in the aggregated_user_statistics table from event_logs but its then persisted there.
Not its unclear wether or not this will help at all with the timing out network request noted in #848
One of the customer has requested if we can allow less than 60 days in -days flag.