user/setup_request apis

[stevenolen]

In order to fully support user/setup flow, we should append a few apis. API endpoints are just a suggestion..

• user/setup_request/create
  • This endpoint will accept/store a new pending request for user/setup & class/create privileges. It will also email admin this info if send_setup_request_notifications = true
  • Suggested/required parameters: username,email,study_start_date,study_duration,study_user_count,study_description,organization.
• user/setup_request/read
  • This endpoint will list all requests known to the server, optionally limiting to only those pending.
  • Suggested parameters for filtering: username, pending
  • This api will be admin only
• user/setup_request/update
  • This endpoint will modify a pending request to successful. It will email the address listed in the pending request with usage policy info on successful state change.
  • Suggested parameters: request_id, silent (which would disable sending the email to user on file, defaults to false).
  • This api will be admin only

Additionally,

• two (maybe 3) new rows in preferences table: admin_email (defaults to root@localhost) and send_setup_request_notifcations (defaults to false) and user_setup_policy?
• user setup policy text should read:

The class setup privilege (required for setup of your own participants) comes with more responsibility in the ohmage system. Your receipt of this message confirms your acceptance of this policy.

  * The user will not share his/her account username and password with anyone under any circumstances. A member of the ohmage project will never ask the user for their password.
  * The user will create classes and add participants only for the purpose of the the study detailed below and will not create classes for other study coordinators.
  * The user will ensure they are logged out of their account before leaving their computer unattended.
  * The user will keep generated accounts and passwords for participants private and share the account information to assigned participants only.
  * ohmage personnel reserve the right to modify or terminate accounts of users at any time for any reason.

This issue is mainly meant to be living documentation of this feature, so please add whatever I'm missing. @hongsudt @jeroenooms

[stevenolen]

maybe user/setup_request/read should be an api for any users to use, and it only returns their pending requests if they have one?

[hongsudt]

@jeroenooms @stevenolen The class setup policy will be displayed by the client within the form.

If we want to control the content through the server, we can extend /app/config/read to let the client get the policy through that api. What do you guys think?

[stevenolen]

config/read should stay with a very small footprint, since it's extremely heavily used and should have only the necessary content about the configuration. with self-reg the policy is found at a seperate endpoint, which I think we can do later on if we'd like to store this state on the server. For now I think it's ok to store the state in the client.

https://github.com/ohmage/server/wiki/Self-Registration#registrationRead

[hongsudt]

To keep small footprint for app/config/read, another idea is to add a parameter e.g. config_name to extract the specific app property.. If config_name = group_creation_policy, then we return the policy text..

[stevenolen]

config/read is one of the few good apis we have :(

it is extremely fast to respond, adding parameters that need to be parsed will slow this down..maybe not much but I call it on many ohmage servers every minute. It should really only contain server-level content (commit hash, feature flags etc)

[hongsudt]

If you don't specify any parameter, I don't think it will affect the
performance..

On Fri, Nov 13, 2015 at 1:13 PM, Steve Nolen notifications@github.com
wrote:

config/read is one of the few good apis we have :(

it is extremely fast to respond, adding parameters that need to be parsed
will slow this down..maybe not much but I call it on many ohmage servers
every minute. It should really only contain server-level content (commit
hash, feature flags etc)

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

[stevenolen]

right now config/read just simply doesn't care about parameters, not even client. My opinion is that extending this api for this purpose is overloading it. Since it's such an important api, I think it's best we handle it another way!