Changes between Version 21 and Version 22 of UserOptInConsent

Timestamp:

Sep 17, 2018, 1:52:53 PM (6 years ago)

Author:

skwang

Comment:

changed protected to project_specific

UserOptInConsent

@@ -49 +49 @@
   * `description` - text field describing the consent that user gives (or has given).
   * `enabled` - if true, this consent type is enabled. This is toggled in the OPS page for managing consent types.
-  * `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.
+  * `project_specific` - if false, this consent type is introduced by BOINC upstream. If true this consent type project-specific, and was added by the project via the ops pages.
   * `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.
 
@@ -67 +67 @@
 Re: `consent_type` table
 
-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.
+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 `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).
 
 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 ===
 
-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.
+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 project-specific, meaning they are not created from the BOINC upstream source code.
 
 === Anonymous Accounts ===