Open richardreeve opened 4 years ago
Heads up @alysbrett @richardreeve - the "Admin & management" label was applied to this issue.
Hi @richardreeve , sorry I didn't get a chance to respond to this before. Yeah, a flag that says whether the person is active works. What I'd do is remove people from the MySQL database that have that flag. That way, you still have the records you need in the .toml files, but they won't be picked up by the mailing lists.
For the projects, it would probably be neater to remove people from the project files themselves, as long as they are still in people.toml you'll still have their details. Adding another flag could lead to inconsistencies but if you would prefer this route, let me know as it will be important to add tests to the CI.
I'll need to check with Mark to make sure that the mailing lists are removing names if they aren't in the db anymore (it may already work this way, but I'll check).
Thanks @nathan-cummings-ukaea. You're right that my solution in projects is more error prone unfortunately. I wanted to be able to keep people's names associated with projects for if/when we published stuff on them to make sure we were as inclusive as possible in authorship, and I was worried otherwise we'd forget people. However, we'll mostly just be marking people inactive in the people.toml
file, so let's just leave it at that.
Can I just check that setting active=false
takes people off the database but by default they will stay on in the people.toml
btw?
Can I just check that setting active=false takes people off the database but by default they will stay on in the people.toml btw?
Yep, the scripts on the database server only read the .toml files and modify the mySQL db accordingly. If you check the commits to the personnel repo you'll see its only yourself and Alyss that have modified the files. Once you have added the flag to people give me a nudge and I'll set to work modifying the db. Due to the service interruption next week (the one that also affects Zulip), it won't be until after that I'll be able to access the server.
Hi @richardreeve this is done on my end. It isn't the cleanest - the script will re-add them and THEN remove them again immediately afterward, but it works and a proper refactor possibly just isn't worth it. I had to fiddle with the way the mySQL database is created to make it work but I've included the changes in the schema file in case it ever needs to be rebuilt.
The only assumption I am making is that if the person is not in the database, the mailing list will remove them. Hopefully this is the case. If you notice people still getting emails that shouldn't, we'll need to ask Mark.
Great, thanks. I'll look later tonight / tomorrow to see if it has been picked up by the mail server.
We need a mechanism for keeping people on our personnel lists, but removing them from our mailing lists, either because they have stopped working for SCRC completely, or have reduced their work and aren't working on one particular project:
In the
people.toml
file, could we add anactive=false
flag to an entry and not (upload anyone to the database?) add them to any mailing list if they have that flag set.In the
projects/xx.toml
files, could we add anactive=false
flag to an entry to not add them to that specific mailing list.@nathan-cummings-ukaea - is this something you could do?