Ruderverein-Donau-Linz/rowt
1
1
Fork 0
Code Issues 30 Pull Requests Actions Packages Projects Wiki Activity

user-role-cluster #760

Merged
philipp merged 10 commits from user-role-cluster into staging 2024-10-11 11:20:59 +02:00
Conversation 0 Commits 10 Files Changed 10 +2
2 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit ca51ba420c - Show all commits

1
doc/db/README.md
View File

@ -9,6 +9,7 @@ Thus, here is the current (October '24) model and the reasoning behind it:
- All user-relevant fields are stored in `User`. - All user-relevant fields are stored in `User`.
- `Role` (and its associative table `UserRole`) map current roles the user has. This is used for e.g. permissions (`Vorstand`, `Admin`, `cox`, ... roles) and fee calculation (`Donau Linz`, `scheckbuch`, `Rennjugend`). - `Role` (and its associative table `UserRole`) map current roles the user has. This is used for e.g. permissions (`Vorstand`, `Admin`, `cox`, ... roles) and fee calculation (`Donau Linz`, `scheckbuch`, `Rennjugend`).
- `Family` specifies, well, a family. Currently only used for fee calculation. - `Family` specifies, well, a family. Currently only used for fee calculation.
- `cluster` in `Role` groups roles together. There is a db check to only allow for at most 1 role of the same cluster (e.g. either `cox` or `bootsfuehrer`, but not both).
## Planned rowing adventures :-) ## Planned rowing adventures :-)
![](./planned.svg) ![](./planned.svg)

1
doc/db/user.mermaid
View File

@ -29,6 +29,7 @@ classDiagram
class Role { class Role {
+int id +int id
+string name +string name
+string cluster
} }
class UserRole { class UserRole {