backdrop-ops
Cleanup/purge users and contractors that no longer work on Backdrop or are spam
We should create a new contrib module named annual_review that allows both content (nodes) and user accounts to be reviewed annually.
Description of feature:
On cron, this module will determine if there are any user accounts or nodes that need to be marked "for review" by administrators.
- User accounts: Any user account that hasn't been accessed in the last year will automatically be added to a queue. On cron, this module will select all users where
accessis more than a year old, and add them to the user review queue. - Content: Content (optional: meeting a specific criteria) that hasn't been reviewed in a year will automatically be added to a queue. On cron, this module will select all nodes where the
annual_review_dateis older than 1 year, and add them to the content review queue.
Configuration:
- A form where User account roles to EXclude can be defined (so accounts without a role can be included)
- Instructions to add the
annual_review_datefield to all node types that should be included.
Module Requirements are follows:
- Module depends on nodequeue
Config included:
- default values for roles + node types (see "Configuration" above)
-
annual_review_datefield configuration - ~default "review content" queue (see if this can be done in config?)~ blocked on https://github.com/backdrop-contrib/nodequeue/issues/24
- ~default "review user accounts" queue (see if this can be done in config?)~ blocked on https://github.com/backdrop-contrib/nodequeue/issues/24
Hooks implemented:
- `hook_cron': "add to queue" action (see details above)
-
hook_node_update: update the date field value to now + remove from queue -
hook_user_update: remove from queue -
hook_nodequeue_remove: update the date field value to now
This module should also provide a hook that allows us to specify additional criteria for content. For example: We will only want to add organizations to the review queue if they provide development services. This could be as simple as altering the query for a MVP.
Original Issue:
Follow-up to this Zulip conversation:
we really neeed to do a purge of the services and contractors that no longer work on Backdrop or are spam.
The question, then, is what process do we implement to ensure that data for contractors and services remains current and up to date? Opening this issue to start the discussion.
Currently there are 76 contractors listed on Contractors for Hire. It's a View of user accounts that have selected "Available for hire" in their profile.
On Backdrop services, under Professional Services there are currently 58 organizations listed. These are nodes of type "Organization profile".
I will mention one approach, which we use on our site that lists local origami groups; the group listings are nodes that can be created by users. Since such groups come and go, we have the same problem: we need to keep them up to date. So after a year has passed since the node was last updated, we start sending periodic automated emails to the creator account, asking them to log in, check their data, and then re-save their listing (which then resets the "last-updated" clock). If they don't do that, they keep getting nagging emails, and then in the admin listing of all groups, we can see who's ignored us and decide if the listing should be deleted or they should receive a personal follow-up. Notably, there is no automatic deletion; it's always a human making that decision. The number of contractors and services above is not too big as to make something like that infeasible.
I'm sure there's other ways of addressing the issue, so let's hear them here!
Note also #977 We have a number who claim they do things for the backdrop community that they do not. Again this requires a human review (I am happy to do). Perhaps if we could also have one or more admin views where we get to see all the contractor nodes in one place (all the org nodes in another) with all the key content fields; it's unwieldy, but still more effective than having to click through each.
I like the idea of a periodic review to ensure still accurate. I think in this case, though the stakes are higher, in that we are directing possible customers towards them and diverting attention from genuine Backdrop contractors and service providers, so we should possibly consider unpublish if they don't update within a certain time frame.
You could automate more without major repercussions, something like:
- Send 3 nag emails in some periodic time frame (like 1 week)
- On the 4th check, if no change has been made, take some action like unpublish the node or block the user or uncheck the checkbox
- After the above action(s) is(are) taken, send a notice (maybe only weekly?) to an admin or admin group about the latest actions taken
Then things can happen without requiring a lot of human intervention until it's necessary, and then there could still be some measure of undoing things without any problem.
On the 4th check, if no change has been made, take some action like unpublish the node or block the user or uncheck the checkbox
I think "uncheck the checkbox" fulfils the objective of removing from the contractor list without causing other issues. The contractor for hire pages are actually user profiles so to unpublish we'd have to block. Organisation (service provider) nodes could be unpublished.
I think "uncheck the checkbox" fulfils the objective of removing from the contractor list without causing other issues. The contractor for hire pages are actually user profiles so to unpublish we'd have to block.
I believe that it is possible to add simple checkbox on a user profile that will
- ask to confirm that they are active for one year
- use in a view for showing/hiding in service listing
@yorkshire-pudding , what needs to happen to begin work on this issue? Do we need to document proposed solution/steps?
So after a year has passed since the node was last updated, we start sending periodic automated emails to the creator account, asking them to log in, check their data, and then re-save their listing (which then resets the "last-updated" clock). If they don't do that, they keep getting nagging emails, and then in the admin listing of all groups, we can see who's ignored us and decide if the listing should be deleted or they should receive a personal follow-up. Notably, there is no automatic deletion; it's always a human making that decision. The number of contractors and services above is not too big as to make something like that infeasible.
I think this approach sounds great.
Send 3 nag emails in some periodic time frame (like 1 week) On the 4th check, if no change has been made, take some action like unpublish the node or block the user or uncheck the checkbox After the above action(s) is(are) taken, send a notice (maybe only weekly?) to an admin or admin group about the latest actions taken
I love this -- as long as nobody installs the rules module on b.org :D
I believe that it is possible to add simple checkbox on a user profile
I don't think a field is the right solution. I have another idea. What if rather than modifying the user profile or the organization node directly, they got added to a queue of items to review?
We can use the "Last access" date to determine if someone is active, we don't need to ask them to do anything other than review the setting (and maybe put a link in the email that takes them right to it via ?destination to make things easy).
Organization profiles do a lot of different things though, and a group that provides hosting in addition to Backdrop development might still want to appear on the hosting page even if they are not taking on development projects. Unpublishing those nodes because one of the options is wrong seems like overkill. And if all the options are correct, then we can't use the "last modified" date, as someone might review their org page but not make any changes... What if we added them to a queue of orgs to review manually? Oooh! I like this. We could do that for both. (updating above...)
@jenlampton , this sounds like a great plan! What would be timeframe to implement it? Who can work on this or help with this? If there is a marketing effort for Backdrop and people begin looking at service providers it critical that listings are accurate. Also, can we add an option to add contact info for service providers? As a service provide I would prefer that potential customers go directly to my contact page not to listing on Backdrop or to main URL of my site.
@jenlampton - this idea sounds good. How about a field on the org node that is "Last reviewed" and perhaps we automatically populate it somehow as part of this workflow? This is quite common for websites to show and confirm that the information has been reviewed and confirmed to be correct.
this idea sounds good. How about a field on the org node that is "Last reviewed" and perhaps we automatically populate it somehow as part of this workflow? This is quite common for websites to show and confirm that the information has been reviewed and confirmed to be correct.
We could set the date for all orgs that offer development services, on node_save() (and via update hook for all the current ones). Then we could build it into the "removed from queue" to update it.
In the original post I have added a rough outline for a contrib module that could handle the queueing and un-queueing. I think we should handle the notifications separately, perhaps via the borg_mailers module. @albanycomputers do you want to take a stab at such a module?
If it's going to be a contrib module, then I feel it should be more useful than just for B.org... and if possible be more useful to the wider community.
Plus... I must be missing something... whats borg_mailers module? :)
Plus... I must be missing something... whats borg_mailers module? :)
https://github.com/backdrop-ops/backdropcms.org/tree/main/www/modules/custom/borg_mailers
@albanycomputers , this task is very specific to b.org , it might be more efficient to consider it a custom module rather than a full contrib module.
@yorkshire-pudding Thanks... I did search for it... but obviously not good enough :)
I think that something like this would be pretty helpful.
I agree, that the needs might be too specific to make a custom module, unless someone is really motivated. Would be quicker to do something custom.
Do we have any volunteers?
Is there a b.org version I can play with to become familiar with the fields available etc...
@albanycomputers , is this the same module that you are asking https://github.com/backdrop-ops/backdropcms.org/tree/main/www/modules/custom/borg_mailers or you are looking for something else?
@irinaz Yes, It's the module that Jen was speaking about above... I'd not investigated that far into Borg territory before and I couldn't find it on the repos...
Found it now thanks.
Hi @albanycomputers, if you're going to be working on a module that is intended for backdropcms.org, I'd recommend that you set up a local installation of a copy of the site for your development, which you can do using sanitized versions of the backdrop and civicrm databases and files. The codebase (which I see you've found) contains borg_mailers module as well as several other b.org-specific custom modules. I can help you with getting it set up; if you want to go this route, contact me via DM on Zulip.
What is best way to organized the team to work on this? @bugfolder , @yorkshire-pudding @albanycomputers ? Should we set time during office hours to work on this together?
@bugfolder Many thanks... I'll have a look tomorrow, where can I get a sanitized version?
@albanycomputers, link sent via Zulip DM. There's probably going to be some back-and-forth to get things configured, so let's continue the nuts-and-bolts discussion there.
@bugfolder Sounds like a plan... I'll certainly need some pointers :-)
I'll get the test site up and running this morning.
Tried to setup on a subdomain but failed due to permissions on importing the civi db... so will setup a local server over the weekend and give it another try.
Tried with a local copy and had it working to a degree... the theme was not working and when I tried to access a link I received a database connection error...
I don't have the time available to try and get a local copy working. I've spent just over 10 hours on this already and haven't gotten anywhere :(
Not sure where to go from here... I don't have the knowledge or spare time to troubleshoot... just getting more frustrated with Linux.
If there is a quick fix I'm willing to spend a bit more time on it... but other than that, I'm going to have to bow out on this one :(
@albanycomputers I suspect the problem is civi, which is a lot more particular than Backdrop to install. Depending on what you are working on, you can UPDATE system SET status = 0 WHERE name = 'civicrm'; and get backdrop running without civi. (This works best for developing modules that don't touch user accounts.)
@jenlampton yeah, I suspect the same... and I could run it from a subdomain... would make it a lot easier for me to play with :)