16 | | None |
| 16 | |
| 17 | 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. |
| 18 | |
| 19 | 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. |
| 20 | |
| 21 | * As a sysadmin I would like to be able to use a paster command to |
| 22 | manually set a user's payment level, or remove it entirely. |
| 23 | |
| 24 | * As a sysadmin I would like to be able to run a paster command to |
| 25 | view a list of users who have a payment plan, grouped by the plan |
| 26 | that they have. |
| 27 | |
| 28 | * As a sysadmin I would like to be able to use the API to change the |
| 29 | payment status of a specific user through user_create and user_update. |
| 30 | This shouldn't be available to anybody else. |
| 31 | |
| 32 | * As a user, and only if I have one, I'd like to see my current payment |
| 33 | level on my user profile page. |
| 34 | |