From 3b1bcbd927f6d320503dcbafb3c6d6be67f4f77f Mon Sep 17 00:00:00 2001 From: Vitalii Koshura Date: Mon, 3 Apr 2023 02:37:09 +0200 Subject: [PATCH] Update UserOptInConsent.md file Signed-off-by: Vitalii Koshura --- UserOptInConsent.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/UserOptInConsent.md b/UserOptInConsent.md index 26605f7..39444a8 100644 --- a/UserOptInConsent.md +++ b/UserOptInConsent.md @@ -37,21 +37,21 @@ A new project option will be included in `config.xml` for projects, `enable_logi Two new tables: `consent` and `consent_type` * `consent` -* `id` - primary key of table - a unique id for each row. Not used for the consent functionality. -* `userid` - the user id -* `consent_type_id` - consent type id, corresponds to the 'id' in the `consent_type` table. -* `consent_time` - `datetime` type attribute : unixtime of when user `id` gave consent to `consent_id`. -* `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). -* `consent_not_required` - a special boolean that indicates whether or not consent is not required. This feature may be used by certain special situation. -* `source` - text field containing the technology actor which the user gave consent. See below. + * `id` - primary key of table - a unique id for each row. Not used for the consent functionality. + * `userid` - the user id + * `consent_type_id` - consent type id, corresponds to the 'id' in the `consent_type` table. + * `consent_time` - `datetime` type attribute : unixtime of when user `id` gave consent to `consent_id`. + * `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). + * `consent_not_required` - a special boolean that indicates whether or not consent is not required. This feature may be used by certain special situation. + * `source` - text field containing the technology actor which the user gave consent. See below. * `consent_type` -* `id` - consent type id, also the primary key. -* `shortname` - consent name, these should be short and in ALLCAPS, e.g., ENROLL, STATSEXPORT, etc. There should be no spaces either. -* `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. -* `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. + * `id` - consent type id, also the primary key. + * `shortname` - consent name, these should be short and in ALLCAPS, e.g., ENROLL, STATSEXPORT, etc. There should be no spaces either. + * `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. + * `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. #### Discussion @@ -64,7 +64,7 @@ Examples * Account Managers should put their name in, e.g. `source` = 'BAM!' or `source` = 'GridRepublic'. * command-line client uses 'boinccmd'. * In the case where `source` is not specified (but consent is being used) then a default `source` of 'URL' can be used. -* 'URL' represents the fact that a user can create an account using the RPC by typing the correct parameters into the URL bar of a browser, or using a command line tool such as curl. + * 'URL' represents the fact that a user can create an account using the RPC by typing the correct parameters into the URL bar of a browser, or using a command line tool such as curl. Re: `consent_type` table @@ -91,7 +91,7 @@ The main RPC that needs to be changed is `create_account.php`, which needs to in Additional parameters for `create_account.php` RPC are * `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. * `source` = 'string' -* example: 'client', see above discussion about `source` for more details. + * example: 'client', see above discussion about `source` for more details. What are the various outcomes of the create_account RPC, especially dealing with `consent_flag`. @@ -107,7 +107,7 @@ Additional parameters are * `consent_flag` - '0|1' - sets the consent_flag to 0 or 1. * `consent_not_required` - '0|1' - sets the consent_not_required flag to 0 or 1. * `consent_source` - 'string' -* example: 'client', see above discussion about `source` for more details. + * example: 'client', see above discussion about `source` for more details. 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.