Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Add REST API to manage notification preferences of other users #255

Open
nemesifier opened this issue Feb 7, 2023 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@nemesifier
Copy link
Member

nemesifier commented Feb 7, 2023

We need a REST API endpoint which will allow administrators to change the notification settings of other users.

The API endpoint path could be: /api/v1/users/user/{id}/notification-setting/ or if that proves to be hard to implement due to the modular structure of OpenWISP, we could use /api/v1/notifications/user/{id}/setting/.

Only the following users can access this endpoint:

  • superusers
  • org manager (load only notification settings of the orgs managed which match the orgs the user is member of, if the user being viewed is not member of any organization managed by the org manager, return 403)
  • authenticated users who match the user id (any user wishing to change their own preferences).

The logic of this API endpoint must be shared with the logic of the existing /api/v1/notification/user-settings/ and avoid duplication.

We need to return the organization name in the API output (let's make sure we use select_related() to avoid generating too many queries when loading this data from the DB).

@battleboy-cxx
Copy link

battleboy-cxx commented Mar 25, 2024

We need a REST API endpoint which will allow administrators to change the notification settings of other users.

The API endpoint path could be: /api/v1/users/user/{id}/notification-setting/ or if that proves to be hard to implement due to the modular structure of OpenWISP, we could use /api/v1/notification/user/{id}/setting/ (althought the former is preferred).

Only superusers shall be able to use this API endpoint.

The logic of this API endpoint must be shared with the logic of the existing /api/v1/notification/user-settings/ and avoid duplication.

Just to make it more explicit. I am writing the GSOC proposal and trying to catch up the instruction, in the instruction text, the below two apis path should be corrected.

/api/v1/notification/user/{id}/setting/ => /api/v1/notifications/notification/user/{id}/setting/
/api/v1/notification/user-settings/ => /api/v1/notifications/notification/user-setting/ no 's' in the end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants