Changes between Version 22 and Version 23 of UserOptInConsent
- Timestamp:
- Sep 17, 2018, 2:28:03 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
UserOptInConsent
v22 v23 41 41 * `consent_time` - `datetime` type attribute : unixtime of when user `id` gave consent to `consent_id`. 42 42 * `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). 43 * `consent_not_required` - a special boolean that indicates whether or not consent is not required. This feature may be used by certain special ...44 * `source` - text field containing the technology actor which the user gave consent. See below 43 * `consent_not_required` - a special boolean that indicates whether or not consent is not required. This feature may be used by certain special situation. 44 * `source` - text field containing the technology actor which the user gave consent. See below. 45 45 46 46 * `consent_type` … … 67 67 Re: `consent_type` table 68 68 69 At first there will be two records in `consent_type`: the main terms-of-use a user consents to when joining the project (ENROLL) anda stats-exports consent type (STATSEXPORT). In effect, these are distributed by BOINC upstream. 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_type_id`, which corresponds to the row in the `consent_type` table, which contains the name and description. The `project_specific` field indicated a consent type that is introduced by BOINC upstream for all projects (false) or a specific consent for a project (true).69 At first there will be two records in `consent_type`: 1) the main terms-of-use a user consents to when joining the project (ENROLL) and 2) a stats-exports consent type (STATSEXPORT). In effect, these are distributed by BOINC upstream. 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_type_id`, which corresponds to the row in the `consent_type` table, which contains the name and description. The `project_specific` field indicated a consent type that is introduced by BOINC upstream for all projects (false) or a specific consent for a project (true). 70 70 71 71 The `enabled` flag is fairly important. By default no consent types are enabled. The project admins may toggle this in the Manage Consent Types OPS page. If the 'ENROLL' type is enabled, users will have to agree to a terms of use when creating an account. (The terms of use file must also exist). Independently, if 'ENROLL' is enabled, and parameter 'enable_login_mustagree_termsofuse' is equal to 1 (TRUE), existing users must agree to the site's terms of use. … … 88 88 89 89 Additional parameters for `create_account.php` RPC are 90 * `consent_flag` = 0|1 - If true, sets the `consent_flag` to 1. If false the `consent_flag` is set to 0 and `consent_not_required` is set to 1. See discussion of anonymous accounts above.90 * `consent_flag` = 0|1 - If true, sets the `consent_flag` to 1. If false the `consent_flag` is set to 0 and `consent_not_required` is set to 1. 91 91 * `source` = 'string' 92 92 * example: 'client', see above discussion about `source` for more details. 93 94 What are the various outcomes of the create_account RPC, especially dealing with `consent_flag`. 95 96 * If consent_flag is not set (NULL), then this is a legacy connection: a old BOINC client or Account Manager. The account is created, but no entry in the `consent` table is made. Terms-of-use acceptance is delayed until a user accesses the Web site. 97 * `consent_flag`=1, terms-of-use was shown to the user, and accept by a remote source: BOINC client or AM. 98 * `consent_flag`=0, terms-of-use not shown but an account is being created is anonymous. See discussion of Anonymous Account below. 99 * N.B. Consent to statistics exports, STATSEXPORT, is not granted via create_account RPC. 93 100 94 101 `am_set_info.php` needs to be modified in order to contain a consent parameter, which also modifies the `consent` table in the database. … … 102 109 103 110 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. 111 112 The design of am_set_info is to fully manage the consent on behalf of a user at a remote source, i.e., an AM. The AM must understand what these fields are and how to set them. 104 113 105 114 Example: