Notification Administration - Upgrade UI

[srenault-meeds]

Rationale

Notifications Administration UI is not consistent with other platform UI. Indeed, the following UI is not accurate with what is expected to see:

In addition to the fact that UX is not the best here:

• Sender informations are "hidden" as it is at the bottom of the app
• To disable / enable a notification channel, it is needed to do it notification per notification

1. Functional Requirements

The UI will be updated to make sure it is consistent with other UI in the platform.

View of future notifications admin page:

With ability for admin to enable/disable any notification by channel type. When disabled, users won't be able to enable it. With ability for admin to set the notification sender settings with a proper drawer:

• to set the sender
• to edit the sender mail without changing the domain name

2. Technical Requirements

Upgradability

The old portlet NotificationsAdminJuzuPortlet has to be replaced in social by a portlet with name NotificationAdministration.

Other Non Functional Requirements

The new portlet has to be made using Vue & REST endpoints.

4. Software Architecture

Migration strategy

The definition of UI & REST endpoint has to be moved to social. Knowing that the old portlet will be replaced, the importMode of administrators portal has to be of type merge or overwrite.

[boubaker]

ready for tech review @rdenarie

[margondicco]

Hello

my feedback : it isn't default notification for user and per type because the end user could not change these settings.

If the administrator define the choice false for the email notification for the type someone request to join a space, the end user could not change it.

BUT

it's a real big requirement.... So if you want to change the mandatory to default, i will be very happy !

[srenault-meeds]

Hello

my feedback : it isn't default notification for user and per type because the end user could not change these settings.

If the administrator define the choice false for the email notification for the type someone request to join a space, the end user could not change it.

BUT

it's a real big requirement.... So if you want to change the mandatory to default, i will be very happy !

Thanks for highlighting it! We have updated this requirement and we will stick to the current behaviour: the admin enables or disables notifications for user. Pre setting notifications will be studied afterwards in another MIP

[margondicco]

Thank you. Go Fonc :-)

[boubaker]

ready for tech review @rdenarie

[rdenarie]

Go tech added

[boubaker]

Ready for PRs review @rdenarie

[boubaker]

Ready for PRs review @rdenarie

BTW, the impact in eXo side is to move the group definition configuration for group.security and group.malwareDetection which aren't part of Meeds addons. (https://github.com/Meeds-io/commons/blob/3ec11784a55326b70d4c537e6ef29154ed85b66a/commons-extension-webapp/src/main/webapp/WEB-INF/conf/commons-extension/notification-configuration.xml#L375-L405)

The notification group group.documents is already defined in documents addon. In addition, as you may see in kudos addon, by example, a special label can be used to display message for administration UI to describe each notification which can be different from User Settings Notification UI. (By default, the messages defined in User Notification UIs will be reused in admin)

[rdenarie]

Social PR commented.

group.malwareDetection is already moved, I take the action for group.security

[rdenarie]

All prs validated

[boubaker]

Thanks. PRs merged to develop.