Hi,
As mentioned in the AGM last week (and a few other times) we could do with some work on our membership system.
Most of this has been on my TODO list for years already and I haven't actually done it.
Anyone else want to pick up any of this? Or replace hub with something else?¹ Or pester me about it until I actually do it?
Source for hub is here: https://github.com/hackerdeen/hackhub
TODO list² for it (in vague priority order):
** User DB
We currently have an SSO system written by a previous member. We don't have anyone still around who really knows how it works, it's using an old version of Node.js and hub is the only thing left that uses it.
I'm inclined to think we don't actually need an SSO system so I'd like have hub managing logins directly itself again. When it previously worked like that there was an LDAP server for the actual accounts - I think that is still overkill for what we need and should just store passwords in the hub DB.
I have done some playing with dump from the LDAP DB backing current SSO and do have some python that can check passwords against the password hashes there so I am inclined to chuck them into hub DB and have it checking against them directly. Would need login flow to do that, some way for users to change password and some way to reset passwords when a member forgets theirs (something better than the ldappasswd command here would be good: https://wiki.57north.org.uk/doku.php?id=projects:57_north_id)
** Old python
Hub is still python 2 - should really move it to a supported version of python. And update all the various libs that it's using that we haven't updated in years. Probably a good idea to move to something like poetry to make managing dependencies easier.
** Containerise it
hub is currently installed manually on a server that is old and we could do with retiring. For setting it up on another (more up to date) server it would be better if it were containerised. I think we already have some stuff on the "new" server in docker so that would probably be first choice for containerising this too. This should also make it easier to spin up dev instances for other work.
** Remote members
We added remote members at 2023 AGM but haven't updated hub to track this yet.
** Automatic dismemberment
We changed the articles that folks are automatically dismembered if they don't pay for 12 months. Could do with that being an automated process in hub. It should send some email reminders before flipping status to dismembered. Probably also needs some safety check to not (threaten to) dismember everyone if there's been no payments recorded for the period (though we don't usually get 12 months behind with recording payments so this shouldn't be much risk).
** Dismemberment + rejoining tracking
There is currently a hard limit on the number of state transitions anyone can make between being a member, being dismembered and rejoining. That sequence up to having joined 2nd time is the end of what hub currently supports. If anyone gets to the end of that and needs to be dismembered again we'd need to add some more columns to `dismembered` table to keep going with the current pattern. It amuses me to keep making that table wider each time someone gets to the end of the supported sequence. But amusing me isn't really a good reason to keep going with an insane structure and probably a better idea to restructure this so people can join + leave as often as they like without needing repeated changes to the database schema.
https://github.com/hackerdeen/hackhub/blob/master/schema.sql#L65
** Register of members
hub should be the source of truth for our register of members - could do with some UI to spit this out in a an appropriate format.
** UI to enable/disable admin permissions
We have admins in hub. This is controlled by flag in member table in the DB. Currently only way to set/remove this flag is messing with the DB manually. Some UI for this would be better.
** Automatic payment recording
Currently need someone to manually go through incoming bank transfers and then mark people as paid in hub. Would be better if this happened automatically. Need to have a chat with directors who have access to the transaction list to see if there is a way to get it into hub and then have some code to reconcile it. Processing a copy/paste from however they're viewing the transaction list (or machine readable export of that) should be doable (and still useful) if we can't get hub to have API access to the info to make it entirely automated.
** Notification for membership applications
Could do with some notification when we get a membership application so they don't sit unnoticed for too long. This is less of an issue now membership application process has prospective members already talking to us before they get to doing anything in hub but could still be useful.
** cleanup
Hub has a few features that connect to other things that don't exist anymore. Could do with cleaning that up (at least removing UI for it or putting it behind a feature flag). Or do something to bring back the other stuff it relies on if anyone cares to have these features again.
Things I think could do with being cleaned up:
- generate an open/close message for space status (the other system that generated these was on one of my servers that I killed (a few years ago)- I probably still have the code and could put it somewhere again if anyone cared about this).
- text message codes to unlock the door. I stopped paying twillio (if I'm remembering the correct company name there) for the number that was receiving these messages. I think I killed the UI for this but there is still the API stuff to receive codes that can probably go: https://github.com/hackerdeen/hackhub/blob/master/api_sms.py
- We have a thing³ that gives list of member emails that used to feed into something to create @57north aliases. I don't think downstream bits of that are still running so would be good to kill the API end point and not have risk of secret for accessing it being guessed/leaked and this being accessible to anyone that it shouldn't be.
** Tests
Could do with some tests so we can catch if we break things in a better way than waiting for members to notice and complain.
¹ I'd take quite a lot of convincing that something else would cover everything hub does with less work than fixing hub, and be maintainable over long term. But I'm not entirely opposed to it if someone else is doing the work. And also I'm not in charge, so convincing me that what you want to do is actually a good idea is not necessarily required.
² These should probably be tickets rather than just dumped into an email...
³ https://github.com/hackerdeen/hackhub/blob/master/api_membership.py#L48
________________________________________________________
Robert McWilliam rmcw@allmail.net argh.technology
I go the extra mile.
Usually because I missed the turning I was supposed to take.
_______________________________________________
57north-discuss mailing list -- 57north-discuss@lists.57north.org.uk
To unsubscribe send an email to 57north-discuss-leave@lists.57north.org.uk