Memberships Process Tidy-up & streamlining

For the memberships page on nzLARPS can we look at setting up form fields (like here: http://www.taupojoust.com/registrationMain.aspx

It should contain the following:

Please make the membership fee bank deposit as outlined above. Once you have done that please fill out the below form.

Name (free format)
Postal Address: (free format)
Phone number: (free format)
Mobile Number: (free format)
E-mail: (free format)
Current Occupation (required by law): (free format)
Are you aged over 18? (Yes/No)
Bank you made the membership fee deposit from: (free format)
Is this a renewal of a current membership? (No / Yes - Membership Number:)
Any larps you have recently attended: (free format)
Any other comments: (free format)

Why should we do this?
Well, when they click on the submit button a copy of the information is auto-emailed to secretary@nzlarps.org

That way the treasurer knows to check the bank account for the membership fee and then forward the email to the secretary sayiing ‘payment confirmed’ once it is. The secretaty can then process the membership pack.

I think its a tidier system and less open to errors or omissions of information by people joining. Additionally I’d like to avoid a repeat of the previous problem with new members joining and nobody knowing about them.

I’d also like to suggest setting up another forum entitled “Memberships”

All committee members have moderator access so we can edit all posts in that forum.

at the top is a sticky post: Current Members.
Followed by a post: Expired Members.

All of us can then update contact details for members, and if we receive any memberships at games ourselves then we can also add the new ones.

Currently there seems to be all sorts of membership details spread across multiple posts in the committe forum and most of it is out of date.
Once this new forum is created I’d like to see all that old posted information in that forum deleted.

Wow, yeah!

And we could ask current members to re-enter their info into this system, to update all records.

Genius!

Adam has been agitating for an email form for some time.

While I could put something like that together in relatively short time (a few hours work to get it working and looking nice), the thing that’s always put me off is the thought that in an ideal world the solution is to have a database on the NZLARPS website that allows users to add and edit themselves, and committee members to see all their details and update things like when they’ve paid. That would be a substantial amount of work, say 8-24 hours depending on the complexity.

Mustering up the enthusiasm and time to do the email form when I think something else would be better hasn’t happened yet. Also, I left off the database solution because Craig reckoned he’d be installing something that we might harness to speed up development of an online membership system.

The database solution would also do away with the need for the forum-based membership list. It could contain things like people who have expressed an interest but not joined yet & old/unpaid members. It could be expanded later to an event booking system.

If I get a few hours free, should I spend it doing the email form or starting the database solution?

The database solution is the best one, I think this is where you could generate the most long-term benefit.

Last time I tried to implement the membership database I hit a hurdle: I couldn’t connect to a database Craig made for it. However, I could connect to the Diatribe forum database. At that point I stopped development, meaning to come back to it.

Are we happy to compromise by adding tables to the Diatribe database for this membership database if I hit this hurdle again? I could add the tables in a way that wouldn’t affect the forum (they wouldn’t cross over at all, I’d have a separate user table). But I’m not sure what future implications there might be. If Diatribe ever went its own way presumably we could extract the NZLARPS membership database from it.

My new favourite flavour of CMS is a system called Joomla. I have built a site in Joomla and it was a great process. I have three more sites to build (one of which is the nzLARPS conversion) which I intend to do in a single marathon day, probably a Tuesday. I’ve pencilled in next Tuesday for a full day of production.

The chances of getting Community Builder (or our own plugin for it) to do this for us are not bad.

I started work on the online membership database yesterday. Should I leave off or carry on?

I’ve carried on working on it. So far I’ve got the database tables in place, a structure for the pages, and the look for the login page. Will move onto the registration and profile pages next.

The online database is a good idea.
If we’re still a-ways off from implementation should we still look at the double email to secretary@nzlarps.org and treasurer@nzlarps?
Maybe on the membership page replace secretary with memberships@nzlarps.org?

I’m working through the database, probably a week or two away.

If someone else wants to play with the email recipients for the links that’s cool with me.

Oh, you’re that close? Sorry. I thought we were talking months rather than weeks.
Carry on Sir. :wink:

As luck would have it I’ve woken up at 6am every morning since I got back from Rarotonga (2 hrs time difference, I normally wake at 8am) and can’t get back to sleep, so I’m making some use of that time. Was working on the Grand Battle website, but I’ve switched to this for a while.

It’s ticking along. I’ve got a basic registration page that inputs data into the database. Nearly done on a list of users page, then will do the user details & editing page, login & session management, and that’ll be it for now.

It’s probably going to be deficient on security and data validation, at least on first release.

Would be going a lot faster if I could get error messages back from mySQL, but the data functions I’m using won’t return the stupid message so I have to fix my SQL errors blind.

Status update.

Done: list of users page, view user page, edit users page.

To do: allow admins to edit of NZLARPS membership status (I’ve separated this out from general editing of user data), sessions, permissions.

Will aim to finish this week.

Ryan, you are legend.

Heck yes! I thought this would be weeks, if not months away. You must have been slaving at the keyboard.

Many thanks.

Done: sessions, permissions. This aspect will need lots of testing once the whole thing is complete. Have used cookies, they’ll be required.

To do: create/remove admins. Allow admins to edit other users’ NZLARPS membership status. Should committee members also be able to edit member’s details (e.g. contact details) or should it be up to the member to do it?

I think that both should be allowed, even if it’s just to remove now obsolete info about a lapsed member.

Lapsed members will be marked as lapsed but kept in the database… I’m not sure that there would be any point in updating their details.

I see the purpose of the database expanding in the future so that users can add/edit events, add/edit organisations, register for events, etc. In which case non-members will have plenty of use for the database too and therefore many of the users in the database will not be members. I’m dubious whether the committee members should be able to update those people’s details, apart from their NZLARPS membership status. Seems like a rare requirement.

I think it might be better if a couple of “developer” users (myself and Craig, for now) can log in as if we were any user to make emergency changes if necessary. We’ll need that ability anyway so that we can test the system. Likewise the developer users might be able to delete users, for example if there were duplicates or prank users.

This was given as an example of a highly insecure and information-leaky piece of software in a recent security seminar I attended. They showed a nifty way to access it with admin privs without a password, that works on all but the absolute latest patched version (and still other security holes were open)

Pretty and full of function, but security-wise our security team wont allow it on our servers.