Create PRIVACY.md for Registration - #11825
Conversation
selyesa
added
improvement
documentation
thojou
left a comment
thojou
left a comment
There was a problem hiding this comment.
Hey @selyesa,
thanks for adding the PRIVACY.md for Registration. Overall this looks well covered and largely match the current implementation.
I would like to request the following changes before merging:
- Broken disclaimer link
- Non-personal-Data in "Data being stored"
Regarding point 2: during review I noticed that this section also includes non-personal administrative data — you’re the expert on privacy here, so I’ll leave it to you whether those details should stay; I mainly wanted to call it out.
Once those are addressed, this looks good to merge from my side.
Kind regards,
@thojou
| @@ -0,0 +1,114 @@ | |||
| # Registration Privacy | |||
|
|
|||
| > **Disclaimer: This documentation does not guarantee completeness or accuracy. Please report any missing or incorrect information by submitting a [Pull Request](docs/development/contributing.md#pull-request-to-the-repositories) or, if you prefer, via the [ILIAS bug tracker](https://mantis.ilias.de). When using the bug tracker, please select the corresponding component in the **Category** field.** | |||
There was a problem hiding this comment.
Nit / correctness: this relative path does not work from components/ILIAS/Registration/PRIVACY.md.
Please change it to something like:
- a)
../../../docs/development/contributing.md#pull-request-to-the-repositories - b) `https://github.com/ILIAS-eLearning/ILIAS/blob/trunk/docs/development/contributing.md#pull-request-to-the-repositories)
(or an absolute GitHub URL), as used in other PRIVACY.md files (e.g. AuthShibboleth).
| ## Data being stored | ||
|
|
||
| - **Registration code**: When a person with the "Write" permission generates registration codes, | ||
| each **code string** is stored in the `reg_registration_codes` table together with a | ||
| **generation timestamp**, an assigned **global role ID**, optional **local role IDs**, an | ||
| **access limitation mode** and its parameters, and flags indicating whether the code is valid | ||
| for registration and/or account extension. These codes do not contain personal data themselves, | ||
| but they are linked to roles and access policies. | ||
| - **Registration code usage timestamp**: When a user redeems a registration code during | ||
| self-registration, the **timestamp** of usage is written to the `used` column of the | ||
| `reg_registration_codes` table. The code itself does not record **which** user redeemed it. | ||
| - **Pending registration user ID**: When dual opt-in (email confirmation) registration is active, | ||
| the **user ID** of the newly created (but not yet activated) user account is stored in the | ||
| `reg_dual_opt_in` table to track the pending confirmation. | ||
| - **Confirmation hash**: A unique **hash value** is generated and stored in the | ||
| `reg_dual_opt_in` table alongside the user ID. This hash is sent to the user's email address | ||
| as part of the confirmation link. | ||
| - **Pending registration creation timestamp**: The **creation date** (as Unix timestamp) of | ||
| the pending registration is stored in the `reg_dual_opt_in` table to determine whether the | ||
| confirmation link has expired. | ||
| - **Email-to-role assignments**: The `reg_er_assignments` table stores mappings between | ||
| **email domain patterns** and **role IDs** for automatic role assignment during registration. | ||
| These are administrative configuration data and do not contain personal user data. | ||
| - **Role access limitations**: The `reg_access_limit` table stores **access limitation modes** | ||
| (absolute date, relative duration, or unlimited) per role. These are administrative | ||
| configuration data and do not contain personal user data. | ||
| - **Approval recipient user IDs**: The **user IDs** of persons designated to receive | ||
| notification emails when new users register are stored in the global ILIAS settings | ||
| (key `approve_recipient`). |
There was a problem hiding this comment.
According to docs/development/how-to-write-a-privacy.md, “Data being stored” should list personal data only (INSERT/UPDATE), and explicitly exclude generic/non-identifiable data.
Several bullets here state that the data is not personal (registration codes, reg_er_assignments, reg_access_limit). I’d suggest moving that context to "General Information" (or dropping it) and keeping this section focused on actual personal/person-linked data, especially:
- pending dual opt-in records (
usr_id, confirmation hash, creation timestamp inreg_dual_opt_in) - approval recipient user IDs in settings (
approve_recipient)
That would align better with the PRIVACY.md guidelines and with how other components structure this section.
3 participants
This pull request adds a new
privacy.mddocument for the Registration component.The generated text is intended solely as a starting point. No guarantee is made regarding its correctness or completeness. Please verify and revise the content as necessary before use.