IT4Change/gradido
3
0
Fork 0
mirror of https://github.com/IT4Change/gradido.git synced 2025-12-13 07:45:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

add some details and ticket references

Browse Source
This commit is contained in:
Claus-Peter Hübner 2022-08-25 00:14:35 +02:00
parent cb4d0dc9b2
commit 56ed064c68
1 changed files with 51 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
docu/Concepts/TechnicalRequirements/UC_Introduction_of_Gradido-ID.md
View File

@ -20,54 +20,61 @@ The second step is to decribe all concerning business logic processes, which hav
#### Users-Table #### Users-Table
The entity users has to be changed by adding the following columns. The entity users has to be changed by adding the following columns. The column State gives a hint about the working state including the ticket number.
| Column | Type | Description | | State | Column | Type | Description |
| ------------------------ | ------ | ----------------------------------------------------------------------------------------------------------------- | | -------------- | ---------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| gradidoID | String | technical unique key of the user as UUID (version 4) | | *done #2125* | gradidoID | String | technical unique key of the user as UUID (version 4) |
| alias | String | a business unique key of the user | | *done #2125* | alias | String | a business unique key of the user |
| passphraseEncryptionType | int | defines the type of encrypting the passphrase: 1 = email (default), 2 = gradidoID, ... | | *open* | passwordEncryptionType | int | defines the type of encrypting the passphrase: 1 = email (default), 2 = gradidoID, ... |
| emailID | int | technical foreign key to the entry with type Email and contactChannel=maincontact of the new entity UserContacts | | *open* | emailID | int | technical foreign key to the UserContacts-Table with the entry of type Email, which will be interpreted as the maincontact from the Users table point of view |
##### Email vs emailID ##### Email vs emailID
The existing column `email`, will now be changed to the primary email contact, which will be stored as a contact entry in the new `UserContacts` table. It is necessary to decide if the content of the `email `will be changed to the foreign key `emailID `to the contact entry with the email address or if the email itself will be kept as a denormalized and duplicate value in the `users `table. The existing column `email`, will now be changed to the primary email contact, which will be stored as a contact entry in the new `UserContacts` table.
The preferred and proper solution will be to add a new column `Users.emailId `as foreign key to the `UsersContact `entry and delete the `Users.email` column after the migration of the email address in the `UsersContact `table. ###### ToDo:
It is necessary to decide if the content of the `email `will be changed to the foreign key `emailID `to the contact entry with the email address or if the email itself will be kept as a denormalized and duplicate value in the `users `table.
The **preferred and proper solution** will be to add the new column `Users.emailId `as foreign key to the `UserContacts `entry and delete the `Users.email` column after the migration of the email address in the `UserContacts `table.
#### new UserContacts-Table #### new UserContacts-Table
A new entity `UserContacts `is introduced to store several contacts of different types like email, telephone or other kinds of contact addresses. A new entity `UserContacts `is introduced to store several contacts of different types like email, telephone or other kinds of contact addresses.
| Column | Type | Description | | Column | Type | Description |
| --------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ------ | ------ | ------------------------------------------------------------ |
| id | int | the technical key of a contact entity | | id | int | the technical key of a contact entity |
| type | int | Defines the type of contact entry as enum: Email, Phone, etc | | type | int | Defines the type of contact entry as enum: Email, Phone, etc |
| usersID | int | Defines the foreign key to the `Users` table | | userID | int | Defines the foreign key to the `Users` table |
| email | String | defines the address of a contact entry of type Email | | email | String | defines the address of a contact entry of type Email |
| phone | String | defines the address of a contact entry of type Phone | | phone | String | defines the address of a contact entry of type Phone |
| contactChannels | String | define the contact channel as comma separated list for which this entry is confirmed by the user e.g. main contact (default), infomail, contracting, advertisings, ... |
##### ToDo:
The UserContacts, expecially the email contacts, will for future be categorized to communication channels for example to allow the user to define which information he will get on which email-contact (aspects of administration, contract, advertising, etc.)
### Database-Migration ### Database-Migration
After the adaption of the database schema and to keep valid consistent data, there must be several steps of data migration to initialize the new and changed columns and tables. After the adaption of the database schema and to keep valid consistent data, there must be several steps of data migration to initialize the new and changed columns and tables.
#### Initialize GradidoID #### Initialize GradidoID (done #2125)
In a one-time migration create for each entry of the `Users `tabel an unique UUID (version4). In a one-time migration create for each entry of the `Users `tabel an unique UUID (version4).
#### Primary Email Contact #### Primary Email Contact (ongoing #1798)
In a one-time migration read for each entry of the `Users `table the `Users.id` and `Users.email` and create for it a new entry in the `UsersContact `table, by initializing the contact-values with: In a one-time migration read for each entry of the `Users `table the `Users.id` and `Users.email` and create for it a new entry in the `UserContacts `table, by initializing the contact-values with:
* id = new technical key * id = new technical key
* type = Enum-Email * type = Enum-Email
* userID = `Users.id` * userID =`Users.id`
* email = `Users.email` * email =`Users.email`
* phone = null * phone = null
* usedChannel = Enum-"main contact" * usedChannel = Enum-"main contact"
and update the `Users `entry with `Users.emailId = UsersContact.Id` and `Users.passphraseEncryptionType = 1` and update the `Users `entry with `Users.emailId = UserContacts.Id` and `Users.passwordEncryptionType = 1`
After this one-time migration the column `Users.email` can be deleted. After this one-time migration the column `Users.email` can be deleted.
@ -75,7 +82,13 @@ After this one-time migration the column `Users.email` can be deleted.
The following logic or business processes has to be adapted for introducing the Gradido-ID The following logic or business processes has to be adapted for introducing the Gradido-ID
#### Read-Write Access of Users-Table especially Email #### Capturing of alias
To avoid using the email as primary identifier it is necessary to introduce a capturing of the alias. It is not a good solution to create for existing users an individual alias by a migration. So each user should capture his own alias during registration- and/or login-process.
These requirements are described in the concept document [../BusinessRequirements/UC_Set_UserAlias.md]() **(done #2144)** and the implementation of these requirements will be the prerequisite for changing the login-process from single email-identifier to the future identifiers alias / gradidoID / email.
#### Read-Write Access of Users-Table especially Email (ongoing #1798)
The ORM mapping has to be adapted to the changed and new database schema. The ORM mapping has to be adapted to the changed and new database schema.
@ -83,19 +96,19 @@ The ORM mapping has to be adapted to the changed and new database schema.
The logic of the registration process has to be adapted by The logic of the registration process has to be adapted by
* initializing the `Users.userID` with a unique UUID * creating a new User including with a unique UUID-V4 **(done #2125)**
* creating a new `UsersContact `entry with the given email address and *maincontact* as `usedChannel ` * creating a new `UserContacts `entry with the given email address **(ongoing #2165)**
* set `emailID `in the `Users `table as foreign key to the new `UsersContact `entry * set `emailID `in the `Users `table as foreign key to the new `UserContacts `entry **(ongoing #2165)**
* set `Users.passphraseEncrpytionType = 2` and encrypt the passphrase with the `Users.userID` instead of the `UsersContact.email` * set `Users.passwordEncrpytionType = 2` and encrypt the password with the `Users.gradidoID` instead of the `UserContacts.email`
#### Login Process #### Login Process
The logic of the login process has to be adapted by The logic of the login process has to be adapted by
* search the users data by reading the `Users `and the `UsersContact` table with the email (or alias as soon as the user can maintain his profil with an alias) as input * search the users data by reading the `Users `and the `UsersContact` table with the `email` as input **(ongoing #2165)**
* depending on the `Users.passphraseEncryptionType` decrypt the stored password * depending on the `Users.passwordEncryptionType` decrypt the stored password
* = 1 : with the email * = 1 : with the email and the existing cryptographical logic (asymetric encryption)
* = 2 : with the userID * = 2 : with the gradidoID and the new cryptographical logic (hashing)
#### Password En/Decryption #### Password En/Decryption
@ -105,16 +118,16 @@ The logic of the password en/decryption has to be adapted by encapsulate the log
The logic of change password has to be adapted by The logic of change password has to be adapted by
* if the `Users.passphraseEncryptionType` = 1, then * if the `Users.passwordEncryptionType` = 1, then
* read the users email address from the `UsersContact `table * read the users email address from the `UsersContact `table
* give the email address as input for the password decryption of the existing password * give the email address as input for the password decryption of the existing password
* use the `Users.userID` as input for the password encryption for the new password * use the `Users.gradidoID` as input for the password hashing, which will be stored in `Users.password`
* change the `Users.passphraseEnrycptionType` to the new value =2 * change the `Users.passwordEnrycptionType` to the new value =2
* if the `Users.passphraseEncryptionType` = 2, then * if the `Users.passwordEncryptionType` = 2, then
* give the `Users.userID` as input for the password decryption of the existing password * give the `Users.gradidoID` as input for the password hashing anddecryption of the existing password
* use the `Users.userID` as input for the password encryption fo the new password * use the `Users.gradidoID` as input for the password encryption fo the new password
#### Search- and Access Logic #### Search- and Access Logic