new users approval and accounts management #17

New issue

Open

opened 2025-04-15 05:15:23 +00:00 by douzeb · 1 comment

douzeb commented

2025-04-15 05:15:23 +00:00

Owner

Add feature to manage user accounts and review new users by members of the admin team :

Except for the first user account created, that is made the owner of the administration team, until they are approved, new users must not be able to use any application feature except log in, log out, viewing the home page, viewing their profile and modifying their profile information.
For users that are not yet approved by an admin, the home page should display that their account is not yet approved and needs to be reviewed by an admin
Admins (members of the administration team) should have a notification indicating that there are new accounts to review.
A rejected account is not deleted. It is kept with a rejection status.
A rejected account, cannot log in to application any longer. Login attempt should fail with an explicit error. If a rejected account is logged in and calls an html route, it should be logged out by deleting its auth token cookie.
Users not yet approved or rejected/banned must not be displayed by the team invitation auto-complete feature.
Admin must be able to see the list of all users and to :
- filter the list by approved, new or rejected/banned status
- modify the email address of a user
- trigger a password reset email for a user.
- ban an approved user (same status as a rejected new user, and remove the account from all the teams it is a member of)
- approve a new account
- un-ban a rejected/banned account
The user list must be implemented using HTMX. example of a table with editable rows in HTMX : https://htmx.org/examples/edit-row/
The user list must be paginated if there are more than 25 users.

Add feature to manage user accounts and review new users by members of the admin team : - Except for the first user account created, that is made the owner of the administration team, until they are approved, new users must not be able to use any application feature except log in, log out, viewing the home page, viewing their profile and modifying their profile information. - For users that are not yet approved by an admin, the home page should display that their account is not yet approved and needs to be reviewed by an admin - Admins (members of the administration team) should have a notification indicating that there are new accounts to review. - A rejected account is not deleted. It is kept with a rejection status. - A rejected account, cannot log in to application any longer. Login attempt should fail with an explicit error. If a rejected account is logged in and calls an html route, it should be logged out by deleting its auth token cookie. - Users not yet approved or rejected/banned must not be displayed by the team invitation auto-complete feature. - Admin must be able to see the list of all users and to : - filter the list by approved, new or rejected/banned status - modify the email address of a user - trigger a password reset email for a user. - ban an approved user (same status as a rejected new user, and remove the account from all the teams it is a member of) - approve a new account - un-ban a rejected/banned account - The user list must be implemented using HTMX. example of a table with editable rows in HTMX : https://htmx.org/examples/edit-row/ - The user list must be paginated if there are more than 25 users.

douzeb changed title from ~~new users approval~~ to new users approval and accounts management

2025-04-20 07:49:44 +00:00

douzeb commented

2025-04-21 04:15:24 +00:00

Author

Owner

Trying to implement this in one shot using ra.aid resulted in a complete mess and hit the gemini API request limit
Trying in cursor, witha smaller scope :

New feature request: Add a new html page allowing to manage user accounts.
- The page must be accessible only to members of the admin team
- The page must contain a list of all user accounts 
- Each row of the list must be editable, for the user name and user email field. When user name or email are changed, the same logic must be applied as in `update_profile` handler of `src/controllers/users_pages.rs`. But do not create duplicated code. Refactor as necessary to put shared code in the users model.
- each row of the list must also have a button to trigger a password reset email for the user. To send the reset password email, use the same code that is used in the `handle_forgot_password` handler of `src/controllers/auth_pages.rs`. But do not create duplicated code. Refactor as necessary to put shared code in the users model.
- the user account list must be paginated if there are more than 25 users
- The user account list must be implemented using HTMX. An example HTMX list implementation is given in `doc/dev/roadmap/phase-1/example-htmx-editable-list.md`
- Create a new controller for this feature, in new file `src/controllers/admin_pages.rs`
- The logic to determine if a user is an admin is already implemented but it is duplicated code that needs to be refactored and put in the users model. The current implementation consist of the function get_admin_team_name and some code that is calling it in controller handlers, that is duplicated in src/controllers/auth_pages.rs and  src/controllers/teams_pages
- The code that is refactored to be moved into models, to be shared between several controllers, must not return anything related to html views. It must be assumed that this code will also be shared with API controllers or other code that is not generating view, like background processing.

Trying to implement this in one shot using ra.aid resulted in a complete mess and hit the gemini API request limit Trying in cursor, witha smaller scope : ``` New feature request: Add a new html page allowing to manage user accounts. - The page must be accessible only to members of the admin team - The page must contain a list of all user accounts - Each row of the list must be editable, for the user name and user email field. When user name or email are changed, the same logic must be applied as in `update_profile` handler of `src/controllers/users_pages.rs`. But do not create duplicated code. Refactor as necessary to put shared code in the users model. - each row of the list must also have a button to trigger a password reset email for the user. To send the reset password email, use the same code that is used in the `handle_forgot_password` handler of `src/controllers/auth_pages.rs`. But do not create duplicated code. Refactor as necessary to put shared code in the users model. - the user account list must be paginated if there are more than 25 users - The user account list must be implemented using HTMX. An example HTMX list implementation is given in `doc/dev/roadmap/phase-1/example-htmx-editable-list.md` - Create a new controller for this feature, in new file `src/controllers/admin_pages.rs` - The logic to determine if a user is an admin is already implemented but it is duplicated code that needs to be refactored and put in the users model. The current implementation consist of the function get_admin_team_name and some code that is calling it in controller handlers, that is duplicated in src/controllers/auth_pages.rs and src/controllers/teams_pages - The code that is refactored to be moved into models, to be shared between several controllers, must not return anything related to html views. It must be assumed that this code will also be shared with API controllers or other code that is not generating view, like background processing. ```

example-htmx-editable-list.md

3.6 KiB

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

NixiN/hosting-farm#17

No description provided.

Rows
Columns