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

Overview: Fancy user-management -> use. diff structs #911

New Issue
Closed
opened 2025-04-17 08:44:03 +02:00 by philipp · 1 comment
philipp commented 2025-04-17 08:44:03 +02:00
Owner
Copy Link

It should be impossible to make me sad when I see people enter stuff wrongly. The system should detect that and tell the user instead. Goal: make me unnecessary, because the system handles itself.

Have different structs for different User. E.g. scheckbuch-User, which has functions to move to DonauLinz user, or send an mail. Not a single hundreds of lines user/mod.rs but split by user type. The default user has e.g. a edit_details() function, to edit address, phone number etc. In the admin-user-edit-view, the admin sees first the default user functionality, and then the special user functionality.

To ponder: Use traits for functionality/permissions? E.g. AllowedToManageEvents, and only special users who implement this trait are allowed to perform this. Downside: How would you iterate over functionality in admin-user-edit-view? You would have to check "has this user that trait implemented?" which is not idiomatic because you want to abstract the differences away.

  • created scheckbuch user struct
It should be impossible to make me sad when I see people enter stuff wrongly. The system should detect that and tell the user instead. Goal: make me unnecessary, because the system handles itself. Have different structs for different User. E.g. `scheckbuch`-User, which has functions to move to `DonauLinz` user, or send an mail. Not a single hundreds of lines `user/mod.rs` but split by user type. The default user has e.g. a `edit_details()` function, to edit address, phone number etc. In the admin-user-edit-view, the admin sees first the default user functionality, and then the special user functionality. To ponder: Use traits for functionality/permissions? E.g. `AllowedToManageEvents`, and only special users who implement this trait are allowed to perform this. Downside: How would you iterate over functionality in admin-user-edit-view? You would have to check "has this user that trait implemented?" which is not idiomatic because you want to abstract the differences away. - [x] The default user list should only contain club members (+ scheckbuch). Basically all users except `schnupper-interessierte` and `schnupperaten`. - [x] The admin-edit-view should contain different boxes. The first one basic user details (Name, email, ...). And then boxes depending on special_user functionality (e.g. move `scheckbuch` user to `DonauLinz` - [Remove hard-coded costs. Roles should have assigned `costs`.](#942) - [Remove linkage of "regular member" and "donau linz". `Ehrenmitglied` should be part of `membership_type`](#943) - [ ] add history (either field or table) to note stuff that happened to a user (e.g. moved to different class, something got updated etc. To have a nice overview of a user. - Instead of allowing to directly edit all data of users and save that into the DB (`user::update`), create functions for specific things (the goal in the end is to remove "general" user editing) - [make it easy to transition between user states (scheckbuch, mitglied, austritt) -> buttons? ](#909) - [ announce (via notification?) if a person got promoted to cox/bootsführer](#910) --- - [x] created scheckbuch user struct
philipp changed title from Fancy user-management to Overview: Fancy user-management 2025-04-17 08:44:12 +02:00
philipp added the
OVERVIEW
 label 2025-04-17 15:04:16 +02:00
philipp changed title from Overview: Fancy user-management to Overview: Fancy user-management -> use. diff structs 2025-04-24 07:29:35 +02:00
philipp commented 2025-04-29 22:49:01 +02:00
Author
Owner
Copy Link

Moved specific next steps to milestone: https://git.hofer.link/Ruderverein-Donau-Linz/rowt/milestone/47

After this milestone is completed, check what's left from the requirements in this issue :-)

Moved specific next steps to milestone: https://git.hofer.link/Ruderverein-Donau-Linz/rowt/milestone/47 After this milestone is completed, check what's left from the requirements in this issue :-)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
OVERVIEW
These tasks act as overview tasks to see general progress in that area
Someday
UI
easy
Tasks that require minimal cognitive effort.
feature
Large feature
next
priority
low
requests
Requests from people. Thus should probably prioritised.
No Label
OVERVIEW
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
marie philipp
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Ruderverein-Donau-Linz/rowt#911
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?