Open JoeCohen opened 3 weeks ago
@JoeCohen - if you want to tackle this, this could be MO's first cron job in Ruby. Solid Queue as of recently now enables setting up recurring jobs on whatever frequency.
You could use Nathan's existing job as an example, and the SQ github docs for making it cron-like.
Or, i have a PR branch open that has rewrites of process_image
, transform_image
, etc. as jobs -- although those jobs are a little more complicated than this, they basically call a PORO and the job class itself is quite brief.
I imagine this job would be basically like writing a migration: it needs to call a new User class method that finds and deletes these users (maybe with a new AR query scope without_contribution
on the model?). The meat of the job could just be a one-liner calling this method.
Note: jobs cannot return values, but they can log their progress via logger.warn
etc. My job PR has examples.
The one case that occurs to me that might be tricky is a newbie at a mushroom event who creates an account, but cannot get the QR code stuff working and don't pursue it long enough to make any actual contribution. However, a recorder might then use their login as a collector on a field slip. Currently this info is stored as a Textile string and not as a reference that can easily be looked up. Admittedly this is an edge case and I don't know that there are any existing similar cases where it would be desirable to keep non-participatory users. Maybe being listed as a Collector should award a contribution point?
user_stats
, user_group_users
(or is it user_groups
). delete_all
on the query results (should be safe at this point).
A chron job should delete Users with zero contribution [and no API] who haven't accessed the site in a while (3 months). See https://github.com/MushroomObserver/mushroom-observer/pull/2160#issuecomment-2159463377.