Proposal: Membership System 2.1

So with the new membership system now fully integrated into our lives, I’ve been thinking a bit about some of the other ideas that didn’t make it.

Not happening because of objections to automated systems.

# Permissions One is how we manage permissions, and looking at how Build Brighton manages that we could be doing better.

Currently an administrator role exists to allow certain members to manage permissions, however this is a rather binary system, that first doesn’t account for the fact we have different groups of @roles that are responsible for different permissions, so we ideally wouldn’t have the Wood Techs able to grant permissions on the Laser Cutter for example.

However also we have no way of people requesting permissions, so keyholder access is granted through countless discourse posts, and a director taking the physical action.

My proposal is that we automat a lot of this:

Keyholders

Member clicks request next the permission in the system, and then anyone with that permission in the system can click vouch next to their name to grant it, when the quote (2 members) is reached the system enacts this.

Tool permissions

Users could click request to help generate a list of what people are after, and once they’ve had an induction the techs could then just approve it rather than having to find the user, and add the permission, but this would also work.


Events

The other area to explore is logging events in the membership system, this would make it much easier for people to link their tags, as they could just scan it, then click claim tag in the system.

Also this would create a place where activation of tools, and what not could go, a long list of events, filterable by their type, you could see exactly who did what, when and also grab reports from this, like how many people open the door each day, without having to parse text from the log.


Those are some ideas, both are a fair amount of work but theres no rush, thoughts?


Other things:

  • Automatically check if a user has an active mandate / subscription in GoCardless if they haven’t paid for more than a month and remove inactive data.

  • Change the navbar to have dropdown menus – DONE

  • Fix issue when you click a row in the admin area versus the icon on it

  • Table sorting – DONE

  • Member app display filtered permission name – DONE

  • Link to gravatar for avatar icon – DONE

  • Improve transactions app:

  • Group into months

  • Monthly / running totals

  • Remove mandate_cancelled bug – DONE

  • Remove seconds from time – DONE

  • Pro-rata payment on first signup

  • Capture user last access time – DONE

  • Allow deletion of users that have never been active members

  • Display notification is user password reset is requested and delete the code if the user successfully logs in or after x number of days? – DONE

1 Like

I think the key holder idea is really good. But that’s all I can say because I have no idea how to do it and no expertise to help implement it. So really I’m just saying yes we should make it happen if it’s possible.

All sounds good.

Was also thinking a ‘Makerspace Status / Control Panel’ might be a good idea, so building on what your describing I’d suggest adding features to:

Easily see the status of tools (along with my induction of them)
Easily see past and future decisions to be voted on

The tool status can be red / green , online / offline whatever. So you can see what tools are working before you make a potentially long trip

The decisions - #governance related - but decisions get totally lost and bike shead-ed on discourse drives me bananas. So once we have a governance structure in place, and a group consensus is needed, we can quickly access that vote and past and other current votes, with summary info and dates.

P.

5 posts were merged into an existing topic: Discussion: Granting Keyholder Access

Yeah that was in my mind but for a way off as you’ve yet to implement the tool control and I have yet to switch the laser cutter and shutter/door to use MQTT either, but it sounds like a good idea, they have this at Hackspace.

If we end up in a referendum governance process yes, possibly, although implementing more than just FPTP will be complicated and need testing.

1 Like

Incidentally, do we want an identifier for users with keyholder access?

Something like

Overriding the user title “Member” doesn’t seem to work though. Have raised the issue with discourse devs.

1 Like

That might work nicely, the title thing is an issue as there are members who have titles that aren’t members any more.

This thread has been split into two to keep both conversations on track.

To test this, do you mind if I delete your user title? Then if you log out and log back in again, it might behave differently.

Sure

Ok, try now

It’s the same?

No title at all now >_<

I am untitled.

Try again?

If this doesn’t do anything I’ll try and reproduce the issue on a clean install and raiseit as a bug.

Nah, I still have no title… The fix is to revoke my keyholder permission in Discourse and grant it again or wait 15 minutes for the membership system to do that.

Ok I’ve manually edited it back for now.

If I get no objections to this:

https://discourse.southlondonmakerspace.org/uploads/default/original/2X/7/76d9cc12ccb6b1968f251324fb1ed2133f931eb9.jpg

I might turn it on in a few days

Are you making an example of me?

1 Like

I object to that particular avatar overlay and probably avatar overlays in principle. I’d go for plain text appended to ‘member’. And wait until any discourse blocking bug is fixed.

2 Likes

On priorities, my personal itch is for event logging.

What I didn’t see in that list was anything to do with Risk assessments, which to my understanding / overhearing isn’t being properly served by what we have or what we could sanely do with a Discourse plug-in.

Neither of those sound like a point update though!