User types

[ross]

Requirements

In the data hub plugin we require the ability to differentiate users between those that have paid for a service, and those that haven't. The distinction isn't boolean as there may be levels of service for paid users, so it may be that we need a 'type' of user where there are various grades of 'paid' which are likely to be strings (specific to the data hub).

Required interface

Once changes have been made to the user schema, for a given user we want to be able to:

• determine if they have a paid or a free account, and
• get a string name of the type of paid account.

Care should be taken to ensure that the 'paid' status of the user cannot be set through the API and only by the datahub plugin.

User Stories

User stories related to the management, setting and changing of a user's payment level, as well as historical information on payments should be done as part of the work that includes actually allowing purchases. For now it is adequate that we can manually control these things through paster commands.

Payments types should be linear as I don't believe for this type of service a pick-and-mix modular model would work well. Organizations will inherit the payment level of their owner, so currently there is no requirement for it to affect organizations at all.

• As a sysadmin I would like to be able to use a paster command to manually set a user's payment level, or remove it entirely.

• As a sysadmin I would like to be able to run a paster command to view a list of users who have a payment plan, grouped by the plan that they have.

• As a sysadmin I would like to be able to use the API to change the payment status of a specific user through user_create and user_update. This shouldn't be available to anybody else.

• As a user, and only if I have one, I'd like to see my current payment level on my user profile page.

Tasks

[x] Tests

[x] Plugin based migration

[x] Code

[x] Model

[x] API

[x] Documentation

Estimates

[ross]

Clarify

[icmurray]

I've done some initial work on this. I think the best way is to define extra tables in the datahub extension. (Rather than: using groups; or modifying the user table; or defining extras for users (in core)).

Initially, I've created a new domain object, PaidService?, which captures the different levels of account a user may have. And then attached users to this through a secondary table. I think the advantages of this approach are:

• the PaidService? table can contain supplementary info about that account type: eg - amount of storage allowed; or cost to sign up etc...
• allows us to use a modular payment system if biz decide that would be favourable. ie - users belong to multiple PaidServices? which are independant of one another, rather than a linear hierarcy (eg - "sign up for storage, but not for privacy" vs. "sign up for enterprise level rather than basic level")

The thing that's held me up today is being able to run tests: I'm having a sqlalchemy issue with defining extra mappings on the User table; which then gets dropped when initializing the test setup. I've gotten to the bottom of the problem, and will ask kindly's advice.

In the meantime, I could do with some user stories please. I think I have a fairly good idea of what's likely to be needed by this ticket; but to what extent should this be exposed to a sysadmin (adding payment schemes; adding users to payment schemes; users seeing which payemtn services they're paying for (public to other users or not?); user's seeing history of payments? sysadmins seeing list of users for each service level?) - should this be: through a dashboard? through paster commands? through the api? all 3?

Do we want modular payments or a linear hierarchy of payment schemes?

How does is this suppossed to fit in with organizations? Do organizations purchase on behalf of users as well as individuals being able to make purchases?

Do we need to be able to deativate a user's paid service if their payment hasn't come through?

[ross]

I think you've nailed the user stories already, but have added them to Description to be explicit.

[rgrp]

Sounds good. BTW all users stories if at all possible go in google docs now for permanence. Here is the template: ​https://docs.google.com/document/d/1U5yahDrvp_PKQMNjzI_8u3xixnALf4eNZWK2BdTXOVw/edit

[icmurray]

Awaiting merge: ​https://github.com/okfn/ckanext-datahub/pull/1