Membership model

[benjaoming]

#48 left behind the task of creating a Membership model.

Here are the properties of a membership that I can remember from our discussions:

• A membership starts and ends.
• A membership is related to a specific department
• A membership is related to permissions: If you (your account) don't have an active membership, you should be redirected etc.
• A membership is an object that's paid for, as with a subscription (that's not an object entity we use AFAIK) -- so a membership actually has a price, and maybe storing it on the Membership object is a necessary start until we have more e-commerce logic.
• A membership is paid for using a specific account, hence you can lookup an account from the membership.
• An account should only have one active membership at a time... but also a history of previous memberships.
• Some of the foodcoops, depending on legal type of organization, may pay VAT on membership fees.
• Membership fee can vary among departments (at least in theory).

@andreaslloyd @valberg @pawciobiel @kraenhansen welcome to the discussion :) It's closely linked to #73

[pawciobiel]

If the description is about an account being a member of a department then I don't have a strong preferences about it, but to me the description looks like we are trying to do too much at once.

[benjaoming]

@pawciobiel very well, but it's a reflection of a long discussion involving many people and whiteboard drawings, and I think you're a little too blunt about a sensitive issue. We would all like this to be nice and simple, but if you see how things actually work out in real life, you know why we need these models, fields, and relations.

[pawciobiel]

@andreaslloyd I wonder how #55 relates to this ticket? Is it the same membership we are talking about?

[benjaoming]

@pawciobiel yes it is the same model that should be used to solve #55! This issue is more about the data model, though, because it has high priority to get this done ASAP. Apart from being a data model, we can also state what a membership is and isn't:

On our site, someone has a user profile and an account. They use that to login and pay for stuff. So this is not what a membership is! A membership grants a certain access to do certain things within a time frame, so it's very much like a subscription... but we call it "membership" because of the democratic structure of the coops, hence people are not just subscribing customers but members with rights :)

[andreaslloyd]

@pawciobiel – we drew out the relationship between user profiles, accounts, memberships, roles and products on the whiteboard at the last Backlog Refinement Meeting. I took a photo of it for reference: https://www.dropbox.com/s/19udp3gcefpwxh9/2015-10-26%2016.59.54.jpg?dl=0

As @benjaoming says, user profile, account and membership are three different things:

• A user profile is an individual user logging in with his email and credentials. A user can have roles and system privileges associated with his profile (but not with the account).
• An account is for a group of users (like a household, company, etc.) that order products together.
• A membership grants an account access to do certain things within a time frame, so it's very much like a subscription. Like you would buy a membership for your account for 2016. And then buy another for 2017.

[andreaslloyd]

Ah, @pawciobiel @benjaoming – I understand the confusion. I forgot to update some of the old issues to reflect the changes we made in the data model (accounts vs. memberships). They should be fixed now!

[pawciobiel]

@benjaoming things like membership and subscriptions don't necessary have to go under "shop" or market app. Especially if we decide to keep a price on them. It could be good to have payment app separate from the market app. It is a pity that you have rushed to change payment.

[pawciobiel]

@andreaslloyd sure, thanks.
So as it is fairly clear what you would want to keep in Membership I was wondering what relations should it have. First of all I would suggest we have a relation between Payment and User/UserProfile just like we previously had as opposed to current Payment-Account.
Because if we need to keep/access: order, basket or subscription data for any account we will easily have that via Order-MembershipOrSubscription-Account and Order-(Basket-)Account anyway right:grey_question: This would also work if we decide that we actually want to have Membership or Subscription in market.
Either way at some point we will need to let user choose which account he/she would like to use:grey_question:

[andreaslloyd]

Sounds good to me to keep the Payment-UserProfile relation, and then have
the user choose which account he/she would like to use. To begin with, in
almost all cases it the user will just be associated with one account, so
the choice should be made automatically. :-)

On Fri, Nov 6, 2015 at 1:43 PM, pawciobiel [email protected] wrote:

@andreaslloyd https://github.com/andreaslloyd sure, thanks.
So as it is fairly clear what you would want to keep in Membership I was
wondering what relations should it have. First of all I would suggest we
have a relation between Payment and User/UserProfile just like we
previously had as opposed to current Payment-Account.
Because if we need to keep/access: order, basket or subscription data for
any account we will easily have that via
Order-MembershipOrSubscription-Account and Order-(Basket-)Account anyway
right(?) This would also work if we decide that we actually want to have
Membership or Subscription in market.
Either way at some point we will need to let user choose which account
he/she would like to use(?)

—
Reply to this email directly or view it on GitHub
#74 (comment).

Andreas Lloyd

web: www.andreaslloyd.dk
mail: [email protected]
phone: +45 3025 3049

[benjaoming]

Yes, as long as there is a direct relation between Payment and Account.
UserProfile makes sense to say "who made the payment".

On 6 November 2015 at 14:52, Andreas Lloyd [email protected] wrote:

Sounds good to me to keep the Payment-UserProfile relation, and then have
the user choose which account he/she would like to use. To begin with, in
almost all cases it the user will just be associated with one account, so
the choice should be made automatically. :-)

On Fri, Nov 6, 2015 at 1:43 PM, pawciobiel [email protected]
wrote:

@andreaslloyd https://github.com/andreaslloyd sure, thanks.
So as it is fairly clear what you would want to keep in Membership I was
wondering what relations should it have. First of all I would suggest we
have a relation between Payment and User/UserProfile just like we
previously had as opposed to current Payment-Account.
Because if we need to keep/access: order, basket or subscription data for
any account we will easily have that via
Order-MembershipOrSubscription-Account and Order-(Basket-)Account anyway
right(?) This would also work if we decide that we actually want to have
Membership or Subscription in market.
Either way at some point we will need to let user choose which account
he/she would like to use(?)

—
Reply to this email directly or view it on GitHub
#74 (comment).

Andreas Lloyd

web: www.andreaslloyd.dk
mail: [email protected]
phone: +45 3025 3049

—
Reply to this email directly or view it on GitHub
#74 (comment).

[pawciobiel]

I think I would call this model Subscription and I would put in inside market app at least for now.

[benjaoming]

@pawciobiel having both Membership and Subscription at the same time would be a highly prioritized refactoring issue from day one, because it would be an ambiguity of a considerable importance. I shared my thoughts about how Membership and Market (payment and accounting logic) would work together at the previous meeting so we could have a special way of dealing with memberships that fits the organization and not traditional ecommerce. That's also why I choose to say that memberships are like a "subscription" but not exactly the same or a reason that we need to model subscriptions anywhere.

Using the Product model with a generic FK relationship to other models (like Membership) would be a fine solution IMO.

[pawciobiel]

@benjaoming
So I have a little thought about this over the weekend and changed my mind. I think I wouldn't call this subscription and in fact I wouldn't add this into market app at all.
I realized that it may be better if we keep subscription for recurring subscriptions on individual products (bags) and keep payed membership separate.
If we could decouple payed membership from market app then it would be easier to deny access to the market if a user/member/account didn't pay membership fee - otherwise we may end up having strange permission logic in market which will allow user to pay for membership but not allow him to pay for any other product.

[benjaoming]

I see what you mean about permissions!

Valid Membership <=> Paid Membership
Payment access => Valid Membership
Paid Membership => Payment access

Paradox! How to solve? Maybe a ManyToManyField on Products called restricted_membership_access = models.ForeignKey('Department') with a relationship to the types of memberships that are allowed to order the product? Or the department you must have a valid membership of to pay for a product?

In this case, products without membership restrictions (such as the Product instance for a membership) would be pay-able without a valid membership.

Scenario 1: As a user, I can't order a product from departments I'm not a member of
Scenario 2: As a user, I can order products from departments I'm a member of
Scenario 3: As a user, I can order products that are not restricted to any department (such as membership of a specific department)

Example 1: Weekly bag, Indre Nørrebro
Example 2: Harvest party dinner tickets, Indre Nørrebro

[pawciobiel]

@benjaoming yes and I know it can be solved this way.
Departments may need to have different products so we will end up having FK to it anyway. But I have questions:

• wouldn't it be simpler in terms of code logic, permission logic and DB schema to move membership out of market completely ❓
• doesn't it feel wrong to have _access type of attributes on Product ❓

On the positive side though, your solution could also allow a user to order membership-fee with a weekly-bag in one order in one go; while my solution would require a user to pay for membership fee first and then he/she would be able to place an order for a bag.

I can see something like "as a user I'd like to pay for next years membership-fee while ordering a bag for next week" as a feature that @andreaslloyd would want...

@benjaoming I hope this won't sound blunt or offensive: let's do a deal, I'll let you do this one the way you want but

• You will let me change Payment back so it has FK to user
• You will let me do Permissions the way I want without inventing our own permissions framework - Rename membership.permissions.Permission to membership.permissions.Role #76
  What do you say ❓

[benjaoming]

wouldn't it be simpler in terms of code logic, permission logic and DB schema to move membership out of market completely

It's not in eggplant.market, and I'm not suggesting to move it. It used to live in eggplant.membership which was fine IMO.. but I see it was part of the refactor that Vidir made before leaving in #77 which we merged because it got too complicated to leave dangling after his departure. So now it's a dangling question both where to put Membership and whether to stick with the current application structure.

More precisely stated here.. but with a TODO regarding the fact that

http://eggplant.readthedocs.org/en/latest/dev/index.html#component-overview

You will let me do Permissions the way I want without inventing our own permissions framework

The motivation is to encapsulate the permission logic, that's why it's great to have a container package for it. The application structure will diminish if permissions-related logic is all over the place. I never wanted to write a permissions framework from scratch, but try understanding the Membership model and you should be able to see that it doesn't fit conventional understandings of permissions.. e.g. "a valid member of department X can sign up for shifts at department x". Maybe you can discuss with @kraenhansen about the outcome of the meeting -- that we were doing eggplant.permissions.settings with PERMISSION_ROLES to replace individual booleans and instead just have the role definitions in settings and assignments to roles in DB.

I'm not asking for a full-blown permission logic, just trying to have the ground paved the right way. This is the code me and @kraenhansen sketched out for a eggplant.permissions.settings :

from django.conf import settings

DEFAULT_ROLES = [
    'cashier',
    'info_dude',
]

DEFAULT_PERMISSIONS = {
    'can_change_account': ['cashier'],
    'can_signup_new_members': ['info_dude'],
}

ROLES = getattr(settings, 'EGGPLANT_ROLES', DEFAULT_ROLES)
PERMISSION = getattr(settings, 'EGGPLANT_ROLES', DEFAULT_PERMISSIONS)