Changes between Version 20 and Version 21 of UserOptInConsent
- Timestamp:
- Sep 5, 2018, 1:56:44 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
UserOptInConsent
v20 v21 49 49 * `description` - text field describing the consent that user gives (or has given). 50 50 * `enabled` - if true, this consent type is enabled. This is toggled in the OPS page for managing consent types. 51 * `protect ed` - 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.51 * `protect` - 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. 52 52 * `privacypref` - if true, (and enabled), this consent type will be shows in the preferences page in the privacy section. This allows projects to add consent types which deal with user privacy; and no additional coding is necessary. 53 53 … … 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) and 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 `protect ed` field indicated a consent type that is introduced by BOINC upstream for all projects.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) and 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 `protect` field indicated a consent type that is introduced by BOINC upstream for all projects. 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. … … 118 118 === OPS pages === 119 119 120 In the ops pages, there is a new 'Manage Consent types' page. Here the admins may add additional consent types, enable/disable them, and set whether or not the consent type should appear in the privacy preferences. Admins may only delete consent types which are not 'protect ed', meaning they are not created from the BOINC upstream source code. Effectively, non-protected consent types are local to this project.120 In the ops pages, there is a new 'Manage Consent types' page. Here the admins may add additional consent types, enable/disable them, and set whether or not the consent type should appear in the privacy preferences. Admins may only delete consent types which are not 'protect'-ed, meaning they are not created from the BOINC upstream source code. Effectively, non-protected consent types are local to this project. 121 121 122 122 === Anonymous Accounts ===