Changes between Version 12 and Version 13 of UserOptInConsent
- Timestamp:
- May 24, 2018, 12:21:21 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
UserOptInConsent
v12 v13 34 34 35 35 * `consent` 36 * `id` - primary key of table - a unique id for each row. Not used for the consent functionality. 36 37 * `userid` - the user id 37 * `consent_ id` - consent id38 * `consent_time` - `datetime` type attribute : unixtime of when user `id` gave consent to `consent_id`. If zero, user has not consented (yet).38 * `consent_name` - consent name, corresponds to the 'shortname' in `consent_type` below. 39 * `consent_time` - `datetime` type attribute : unixtime of when user `id` gave consent to `consent_id`. 39 40 * `consent_flag` - the boolean which explicitly stats that this user id has given consent to this consent id. If this is 0 (FALSE), the following boolean should be 1 (TRUE). 40 41 * `consent_not_required` - a special boolean that indicates whether or not consent is not required. This feature may be used by certain special ... 41 42 * `source` - text field containing the technology actor which the user gave consent. See below 42 43 43 `userid` and `consent_id` together make up the primary key of this table.44 45 44 * `consent_type` 46 45 * `consent_id` - consent id, also the primary key. 46 * `shortname` - consent name, these should be short and in ALLCAPS, e.g., ENROLL, STATSEXPORTS, etc. 47 47 * `description` - text field describing the consent that user gives (or has given). 48 * `protected` - if true, this consent type is introduced by BOINC upstream. If false this consent type project-specific, and was added by the project via the ops pages. 48 49 49 50 ==== Discussion ==== … … 62 63 Re: `consent_type` table 63 64 64 At first there will be one record in `consent_type`: the main terms-of-use a user consents to when joining the project. The `consent` table uses `id` and `consent_id` as the primary key, so a single user may consent to multiple items. This allows for flexibility - a project may decide to present a user with multiple items to consent to. Each can be recorded in the `consent` table with a different `consent_id`, whose description is stored in the `consent_type` table.65 At first there will be two record in `consent_type`: the main terms-of-use a user consents to when joining the project and a stats-exports consent type. This allows for flexibility - a project may decide to present a user with multiple items to consent to. Each can be recorded in the `consent` table with a different `consent_name`, whose description is stored in the `consent_type` table. The `protected` field indicated a consent type that is introduced by BOINC upstream for all projects. 65 66 66 Currently when a project is created, or updated to the latest database schema, the `consent_type` table will be: 67 {{{ 68 SELECT * FROM testp1.consent_type\G 69 *************************** 1. row *************************** 70 consent_id: 1 71 description: General terms-of-use for this BOINC project. 72 }}} 67 Re: `consent` table 73 68 74 This consent type #1 should **not** be modified or deleted by projects! 69 Entries to this table are to be inserted for a `userid` and `consent_name`. This way a single user may consent to multiple policies. If a user withdraws consent, a new entry should be added. Effectively, no rows should be deleted from this table, only added. There may be a situation where a user has dozens of rows since s/he has given and withdrawn consent multiple times. This acts as a record of the user's consent to policies. The latest row, that is the row with last datetime, represents the current consent status. 70 71 The exception is when a user deletes his/her account. Then all `consent` table entries for that user's id are deleted. 75 72 76 73 === RPC === … … 91 88 92 89 Additional parameters are 93 * `consent_id` = 'integer' - required if any of the below are to be set. If this parameter is not present, the `consent` table will not be modified. 94 * `consent_settime` = '0|1' - sets the `consent_time` to the current unixtime. 90 * `consent_name` = 'string' - This is the shortname of the consent_type to insert a new entry for. 95 91 * `consent_flag` - '0|1' - sets the consent_flag to 0 or 1. 96 92 * `consent_not_required` - '0|1' - sets the consent_not_required flag to 0 or 1. … … 98 94 * example: 'client', see above discussion about `source` for more details. 99 95 100 am_set_info.php can be used to update the `consent` table or to insert a new record. The user and consent ids are used as the primary keys of the `consent` table. Thus if both are given and found in already, the RPC will update the fields with the other `consent_` parameters. Likewise if this is a new row, then the RPC will insert a new record into the table using the fields. Note: if inserting a new record the RPC will first check to see if the `consent_id` exists in the `consent_type` table. If not an (-1) XML error will be returned. If the `consent_id` does exist, the insertion of a new record requires the following parameters `consent_id`, `consent_flag`, `consent_not_required`, and `consent_source`. If any of the four are not present, an error is returned. The `consent_settime` boolean is ignored. The record is inserted with the current unixtime.96 am_set_info.php is used to insert a new record into the `consent` table, but only if all four of these additional parameters are present. If one is not present, the `consent` table will not be modified. However, the RPC will not return a failure. This is to ensure backwards compatibility. If all four parameters above are set, as below, then the RPC will insert a new entry into the `consent` table. 101 97 102 98 Example: 103 99 {{{ 104 am_set_info.php?consent_ id=99&consent_flag=1&consent_not_required=0&consent_source=accountmanager100 am_set_info.php?consent_name=ENROLL&consent_flag=1&consent_not_required=0&consent_source=accountmanager 105 101 }}} 106 102 107 The RPC is attempting to set the consent information for a `consent_id` of 99. First the `consent` table is checked with the userid corresponding to the authenticator and the `consent_id`. If a record is found, it is updated with the parameters in the RPC: e.g., flag, not_required, source. 108 109 If no record is found in `consent`, the `consent_type` table is checked to see if there a id of 99. If there is not, an error is returned. 110 111 If there is such a `consent_id`==99, then the RPC will insert `consent_id`=99 and userid (from authenticator) into the `consent` table setting the additional parameters: e.g., flag, source. 103 The RPC is attempting to set the consent information for a `consent_name` of ENROLL. It will check of consent_name ENROLL exists. If it does not an error message will be returned. 112 104 113 105 === Web site === … … 115 107 The Web site account registration page will have a new panel that includes the terms of use text. This will be the same text file as [wiki:TermsOfUse]. The text file is processed with PHP's `nl2br()` function in order to format the plain text into text that is readable in HTML. Admins should **not** put HTML tags into the plain text [wiki:TermsOfUse] file. 116 108 117 The registration page will have an additional checkbox that requires a user opt-in to the terms of use. If this is not checked, the account will not be created, and an error hsown to the user. Only when the checkbox is checked, will an account be created. A new record will be inserted into the `consent` table, in the same manner as the create_account RPC.109 The registration page will have an additional checkbox that requires a user opt-in to the terms of use. If this is not checked, the account will not be created, and an error shown to the user. Only when the checkbox is checked, will an account be created. A new record will be inserted into the `consent` table, in the same manner as the create_account RPC. 118 110 119 111 === Anonymous Accounts ===
