Relationship between users and members

Register or login to post to the forum.
10 Feb, 2016 15:39

Hi, I'm trying to determine what the difference is between users (Home -> Authentication And Authorisation -> Users) and Memberships (Home -> Memberships Application -> Memberships).

I have some theories but it would be good to have some official word about how they differ and when to use them.


16 Feb, 2016 14:02

It's actually very straightforward and one of my personal strictest rules in programming.

"A user is a user is a user. No exceptions."

What I mean by that is there is only one users table (well auth_user) and everything else is an attribute of that user. So the profile module has all of the related data for a current user. An administrator is a user marked as a superuser. Users join groups, post jobs, attend events, join, quit and come back to your association. A student attends University, leaves, and comes back in 10 years for a masters degree. Then returns again in another 5 years to join the faculty. This is always and forever the same human being and they have one record.

There are never tables for "user" "student" "teacher" "contractor" etc..... they are all users fulfilling a role.

So let's talk about memberships. Users are one to many with memberships. And a membership and user who is a member are both one to many with membership applications. This let's you see a history of renewals, know when people quit so you can define the pattern and see if you can save them.

  • id = 5000
  • auth_user bob
  • entityid = 1 (he's associated with the BIG entity of the org and nothing else)
  • Profile id = 7688 (or whatever)
  • ||
  • Membership ID (system assigned pk) = 400
  • Membership application id 1995 = 241
  • Membership application id 1996 = 876
  • Membership application id 1997 = 1034
  • Membership application id 2005 = NULL (doesn't exist, he was unemployed and didn't join)
  • ....
  • Membership application id 2015 = 4598
  • Membership application id 2-16 = 5444

The model above shows you patterns in your membership financially, job history, phone numbers, email address changes are updated by the user themselves every year because the membership application updates the profile etc....

And every rule is defined by the exception. The exceptions are 1) custom forms unless mapped to user fields - they don't create users. 2) Event registrants - it tries to match them up by email even if they aren't logged in, but it doesn't create a user for every registrant. The reason for this is table registrations where the admin takes a corporate sponsorship that includes a table for 10 but doesn't have the name so the admin just puts in their own email all 10 times to reserver the table. You don't want that in your users table so it doesn't add any.

The downside to this - many applications are very sloppy and basically use tables as an excuse for security (e.g. if (select employeeid where username = "bob" from employees) > 0 then boo = true).

The solution to this is to keep on top of your similar users report here: and merge the people who are actually the same.

Edited 16 Feb, 2016 14:05
22 Feb, 2016 02:36

Thanks for the detailed response, I think I have a better picture of what happens now - Turns out i definitely need at least one user per member.