| 43 | | It is likely at first there will be one record in `consent_type`: the main terms-of-use a user consents to when joining the project. The `consent` table uses `id` and `consent_id` as the primary key, so a single user may consent to multiple items. 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_id`, whose description is stored in the `consent_type` table. |
| | 47 | ==== Discussion ==== |
| | 48 | |
| | 49 | Some discussion on `source` string. |
| | 50 | |
| | 51 | Examples |
| | 52 | |
| | 53 | * If a user gives consent by registering for an account using the BOINC GUI client (BOINC manager), `source` would be set to 'client'. |
| | 54 | * If the account is created on a Web site registration page, `source` would be set to 'web'. |
| | 55 | * Account Managers should put their name in, e.g. `source` = 'BAM!' or `source` = 'GridRepublic'. |
| | 56 | * command-line client uses 'boinccmd'. |
| | 57 | * In the case where `source` is not specified (but consent is being used) then a default `source` of 'URL' will be used. |
| | 58 | * '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. |
| | 59 | |
| | 60 | Re: `consent_type` table |
| | 61 | |
| | 62 | At first there will be one record in `consent_type`: the main terms-of-use a user consents to when joining the project. The `consent` table uses `id` and `consent_id` as the primary key, so a single user may consent to multiple items. 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_id`, whose description is stored in the `consent_type` table. |
| | 63 | |
| | 64 | Currently when a project is created, or updated to the latest database schema, the `consent_type` table will be: |
| | 65 | {{{ |
| | 66 | SELECT * FROM testp1.consent_type\G |
| | 67 | *************************** 1. row *************************** |
| | 68 | consent_id: 1 |
| | 69 | description: General terms-of-use for this BOINC project. |
| | 70 | }}} |
| | 71 | |
| | 72 | This consent type #1 should **not** be modified or deleted by projects! |
| 57 | | Additional parameters for RPC are |
| 58 | | * optin=0 | 1 - |
| 59 | | * source='string' |
| 60 | | * examples: 'client', 'AM', 'web', this would fill the `source` field in the `consent` table. |
| | 86 | Additional parameters for `create_account.php` RPC are |
| | 87 | * `consent_id` = 'integer' - optional, defaults to 1 unless specified. If given a `consent_id` that does not exist in the `consent_type` table, then the RPC will return an error. |
| | 88 | * `optin` = 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. |
| | 89 | * `source` = 'string' |
| | 90 | * example: 'client', see above discussion about `source` for more details. |
| | 94 | Additional parameters are |
| | 95 | * `consent_id` = 'integer' - required if any of the below are to be set. If this parameter is not present, the `consent` table will not be modified. |
| | 96 | * `consent_settime` = '0|1' - sets the `consent_time` to the current unixtime. |
| | 97 | * `consent_flag` - '0|1' - sets the consent_flag to 0 or 1. |
| | 98 | * `consent_not_required` - '0|1' - sets the consent_not_required flag to 0 or 1. |
| | 99 | * `consent_source` - 'string' |
| | 100 | * example: 'client', see above discussion about `source` for more details. |
| | 101 | |
| | 102 | am_set_info.php can be used to update the `consent` table or to insert a new record. The user and consent ids are used as the primary keys of the `consent` table. Thus if both are given and found in already, the RPC will update the fields with the other `consent_` parameters. Likewise if this is a new row, then the RPC will insert a new record into the table using the fields. Note: if inserting a new record the RPC will first check to see if the `consent_id` exists in the `consent_type` table. If not an (-1) XML error will be returned. If the `consent_id` does exist, the insertion of a new record requires the following parameters `consent_id`, `consent_flag`, `consent_not_required`, and `consent_source`. If any of the four are not present, an error is returned. The `consent_settime` boolean is ignored. The record is inserted with the current unixtime. |
| | 103 | |
| | 104 | Example: |
| | 105 | {{{ |
| | 106 | am_set_info.php?consent_id=99&consent_flag=1&consent_not_required=0&consent_source=accountmanager |
| | 107 | }}} |
| | 108 | |
| | 109 | The RPC is attempting to set the consent information for a `consent_id` of 99. First the `consent` table is checked with the userid corresponding to the authenticator and the `consent_id`. If a record is found, it is updated with the parameters in the RPC: e.g., flag, not_required, source. |
| | 110 | |
| | 111 | If no record is found in `consent`, the `consent_type` table is checked to see if there a id of 99. If there is not, an error is returned. |
| | 112 | |
| | 113 | If there is such a `consent_id`==99, then the RPC will insert `consent_id`=99 and userid (from authenticator) into the `consent` table setting the additional parameters: e.g., flag, source. |
