Changes between Version 27 and Version 28 of UserOptInConsent

Timestamp:

Oct 26, 2018, 8:50:32 AM (5 years ago)

Author:

skwang

Comment:

Added more changes now that code has been merged.

UserOptInConsent

@@ -5 +5 @@
 == User Experience ==
 
-When using the main BOINC manager to join a project (Add Project), the user is shown a Terms of Use / Project policy text. S/he must accept the terms of use before the account is created. As part of the account creation process, the agreement to the terms of use is recorded in the project's database.
+When using the a BOINC manager to join a project (Add Project), the user is shown a Terms of Use / Project policy text. S/he must accept the terms of use before the account is created. As part of the account creation process, the agreement to the terms of use is recorded in the project's database.
+
+Note: As of 2018-10-26, no BOINC managers use the Web RPCs described here to actually tell the BOINC project to record the consent to the terms of use in the database. Thus, whenever a user logs in for the first time s/he will will be presented with the terms of use Web page, asking them to agree. As more BOINC managers are changed to handle the consent features described here, this will change.
 
 For account managers (AM), AMs can download a site's terms of use from `get_project_config.php`. Then present this text to a user. It will be the responsibility of an AM to present the text along with a checkbox for the user to agree to. (It must not be passive.) The `create_account.php` RPC will be modified slightly for AM to set a consent flag. Additionally, the `am_set_info.php` RPC will be modified to allow AM to update the a user's consent information.
@@ -127 +129 @@
 === 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 **not** delete consent types. This is preserve any audit trail that may be legally necessary.
+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 **not** delete consent types. Howveer, admins may disable consent types that are no longer used. Technically, this is because the consent_type_id is a foreign key in the consent table, and deleting the consent type involves removing rows from the consent table. Since we do not want to delete rows in the consent table to preserve any audit trail that may be legally necessary, deleting consent types is not supported in the OPS pages.
 
 === Anonymous Accounts ===
@@ -150 +152 @@
 How `STATSEXPORT` affects `db_dump`. If the `STATSEXPORT` consent_type is **enabled** in the OPS pages, users will be able to select whether they consent to having their statistics exported. This option is **false** by default. This option is found in the project preferences page, example: `https://projectURL/prefs.php?subset=project`. This option is also **false** by default.
 
-Only if a user has consented to this `STATSEXPORT`, then `db_dump` will include their user account and their hosts in the anonymous statistics created.
+Only if a user has consented to this `STATSEXPORT`, then `db_dump` will include their user account and their hosts in the anonymous statistics created: specifically the `host` and `user` XML output. However, the total aggregate number of number of users, hosts, and the total credit will include all (non-deleted) users and hosts, ignoring the STATSEXPORT consetnt type.
 
 == Project-specific consent types ==