backend issueshttps://gitlab.cern.ch/push-notifications/backend/-/issues2024-03-12T10:57:50+01:00https://gitlab.cern.ch/push-notifications/backend/-/issues/249Posting restrictions follow up2024-03-12T10:57:50+01:00Carina AntunesPosting restrictions follow upPosting restrictions are implemented on addition of e-group to channel members and on send notification to direct targets (which adds e-group to members)
Adding to members is only possible via UI. Current implementation checks against a...Posting restrictions are implemented on addition of e-group to channel members and on send notification to direct targets (which adds e-group to members)
Adding to members is only possible via UI. Current implementation checks against authenticated user.
Should be split in 3 tasks:
1.
However for the send-notification action there are a couple of different flows possible:
- no authorization bag: notification is received in backend-internal; email gateway flow; no direct notifications, therefore no concern there
- auth bag only contains API KEY; API access - posting restrictions should check against owner and/or admin e-group of channel, **more work needed**
- user is authenticated/ UI flow - posting restrictions can be checked against authenticated user
---
2.
**Current flow is faulty:**
- Changing/setting new posting restrictions on an e-group which was already set as members is not respected. We should re-calculate posting-restrictions on every send. (backend call would be to time consuming, routing does not show failed status to users - how to show failed status to users?)
- Idea: implement webhook on backend to set status of processed on notification (called when routing completes), or show audit data regarding failed targets (account no longer exists, failed posting restrictions, etc). Final submit should display a new message `refresh in a moment for a summary of status of delivery`, show loading spinner on notification until routing is complete)
---
3.
Besides the mentioned above, currently it seems users can bypass posting restrictions by adding the sender as member to `egroup-notification-master` - managed by Natalie Kane.
We do not want to re-implement this functionality, so ideally we'd like to respect membership to this e-group to allow bypassing posting restrictions.
**More information on this is needed**. A couple of question unanswered so far:
- What's the process to be a member of this e-group? Can we reuse membership? E.g., for OKD Alerts, is it a secondary account?
- Is it sufficient to check if the owner/admin-egroup of a channel is a member of the e-group `egroup-notification-master`? Do we support secondary/service accounts as channel owners?
- Another alternative would be to set a new specific field, ie under advanced configurations, field `bypass posting restrictions identity` + valid flag. This could be any CERN identity (Secondary, Service, or Primary), which is a member of `egroup-notification-master`. On save we would need to check authenticated user has permissions on said account (get /identity/upn, check `ownerId` field)
- How do we respect loss of privileges, i.e, removal from `egroup-notification-master`. On send time (routing/expansion), or we would need a cron job to check if owner/admins still have privileges over all channel groups (members, and `bypass posting restrictions identity`)
Currently OKD Alerts is owned by Jack Henschel, with admin-egroup `openshift-admins`. But it is the service account `wwwprot` owned by Andreas Wagner which is a member of `egroup-notification-master`. A bit of a difficult scenario, either Jack's account or the `openshift-admins` would need to be added to `egroup-notification-master`. Alternatively for Jack to set the account `wwwprot` as the posting bypass identity, we would need to check if any member of the admin-egroup is the owner of `wwwprot`, or Jack would need to ask Andreas to login and set the field.https://gitlab.cern.ch/push-notifications/backend/-/issues/248Add egroup-notification-master bypass2024-02-15T15:25:03+01:00Jose SemedoAdd egroup-notification-master bypassAs mentioned in https://okd-internal.docs.cern.ch/computing-resources/global-resources/#for-email-notifications
`wwwprot was requested to be added to https://e-groups.cern.ch/e-groups/Egroup.do?egroupName=egroup-notification-master in A...As mentioned in https://okd-internal.docs.cern.ch/computing-resources/global-resources/#for-email-notifications
`wwwprot was requested to be added to https://e-groups.cern.ch/e-groups/Egroup.do?egroupName=egroup-notification-master in August 2023 to bypass posting restrictions on CERN e-groups used as admin groups of OKD4 projects.`
So we should consider adding an extra check for membership on this egroup.
https://e-groups.cern.ch/e-groups/Egroup.do?egroupName=egroup-notification-masterhttps://gitlab.cern.ch/push-notifications/backend/-/issues/247Autocomplete for e-groups2024-03-25T00:05:04+01:00Emmanuel OrmanceyAutocomplete for e-groupslinked to https://gitlab.cern.ch/push-notifications/web-portal/-/issues/15linked to https://gitlab.cern.ch/push-notifications/web-portal/-/issues/15Emmanuel OrmanceyEmmanuel Ormanceyhttps://gitlab.cern.ch/push-notifications/backend/-/issues/246Channel type: add "Test" option2024-03-25T00:05:04+01:00Carina AntunesChannel type: add "Test" optionhttps://gitlab.cern.ch/push-notifications/backend/-/issues/243Fix admin channel view : edit flags2024-03-25T00:05:04+01:00Carina AntunesFix admin channel view : edit flagshttps://gitlab.cern.ch/push-notifications/backend/-/issues/242Allow editing channel owner2024-03-25T00:05:04+01:00Carina AntunesAllow editing channel ownerhttps://gitlab.cern.ch/push-notifications/backend/-/issues/240Adding more statistics2024-03-25T00:05:04+01:00Emmanuel OrmanceyAdding more statisticsFrom https://indico.cern.ch/event/1354671/
Statistics that could reflect real usage growth (probably a mix of legoservices and ES audit data):
- Channels per department
- Active users per department
- top channels with most organic user...From https://indico.cern.ch/event/1354671/
Statistics that could reflect real usage growth (probably a mix of legoservices and ES audit data):
- Channels per department
- Active users per department
- top channels with most organic users (self-subscription) and total of self subscriptions per channel
- average amount of preferences per user
- average amount of muted channels per user
- average amount of notifications per channel
- average amount of end users reached per notification (need to use audit info)
- average amount of device reached per notification (need to use audit info)
- 5 latest channels created (just a fun fact)Emmanuel OrmanceyEmmanuel Ormanceyhttps://gitlab.cern.ch/push-notifications/backend/-/issues/228Opensource preparation - Modularize2024-03-25T00:05:04+01:00Jose SemedoOpensource preparation - ModularizeAccording to: https://gitlab.cern.ch/push-notifications/notifications-design/-/issues/55
### Backend:
- [ ] Authentication and authorization (`authorizationChecker.ts`)
- [ ] Extracts login and id from `decodedtoken.cern_upn`
- [ ]...According to: https://gitlab.cern.ch/push-notifications/notifications-design/-/issues/55
### Backend:
- [ ] Authentication and authorization (`authorizationChecker.ts`)
- [ ] Extracts login and id from `decodedtoken.cern_upn`
- [ ] Roles are coming from OAuth token `decodedToken.resource_access...roles`: `INTERNAL_ROLE=internal, VIEWER_ROLE=viewer, SUPPORTER_ROLE=supporter`.
- [ ] Mattermost integration assumes Mattermost id = email
- [ ] `update-user-email.ts`, `upsert-mattermost-device.ts`
- [ ] CernPhone and mail2sms integration
- [ ] interfaces or enable via config
- [ ] `cern-activedirectory.ts`: to be made generic with config
- [x] `group.ts` and `cern-authorization-service.ts`: replace and make a generic group interface configurable to use AD/LDAP module to extract groups and groups membership, or the authorization service to query Grappa.
- [ ] `device.ts`: `DeviceSubType` to move to config ? some require specific code. implement Interfaces ?
- [ ] `push-browser` folder:
- [ ] `push-safari-sender.ts`: update `testSafariPush` and `note.urlArgs` to use config
- [ ] `push-mattermost-sender.ts`: update `testMattermost` to use config
- [ ] `push-browser-sender.ts`: update `testBrowserPush` to use config
- [ ] `username-from-email.ts`: CERN specific
- [ ] `app.ts`: `routingControllersToSpec` strings to use configEmmanuel OrmanceyJose SemedoEmmanuel Ormanceyhttps://gitlab.cern.ch/push-notifications/backend/-/issues/224Add CONTRIBUTING.md2024-03-25T00:05:04+01:00Jose SemedoAdd CONTRIBUTING.mdAs mentioned in https://gitlab.cern.ch/push-notifications/backend/-/merge_requests/223#note_6547432
We should document some guidelines for contributing so that we can easily look up why and how something is done, i.e. performance quirks...As mentioned in https://gitlab.cern.ch/push-notifications/backend/-/merge_requests/223#note_6547432
We should document some guidelines for contributing so that we can easily look up why and how something is done, i.e. performance quirks of DB and typeorm.Jose SemedoJose Semedohttps://gitlab.cern.ch/push-notifications/backend/-/issues/220Investigate PayloadTooLargeError - request entity too large2024-03-25T00:05:04+01:00Jose SemedoInvestigate PayloadTooLargeError - request entity too largeSentry record - https://push-notifications-sentry.web.cern.ch/sentry/backend/issues/2148/
This can easily happen when a user is writing a notification that is very large, and it is sent to be saved as a draft.
It is also probably easy ...Sentry record - https://push-notifications-sentry.web.cern.ch/sentry/backend/issues/2148/
This can easily happen when a user is writing a notification that is very large, and it is sent to be saved as a draft.
It is also probably easy to reproduce by simply pasting an image in the body, which can easily hit the request size limit.
How to handle this?https://gitlab.cern.ch/push-notifications/backend/-/issues/219Etcd: move security logs to opensearch2024-03-25T00:05:04+01:00Carina AntunesEtcd: move security logs to opensearchhttps://notifications-internal.docs.cern.ch/operations/es-auditing/https://notifications-internal.docs.cern.ch/operations/es-auditing/Emmanuel OrmanceyEmmanuel Ormanceyhttps://gitlab.cern.ch/push-notifications/backend/-/issues/216Deprecate Auto add members on sending targeted notifications2024-03-25T00:05:04+01:00Emmanuel OrmanceyDeprecate Auto add members on sending targeted notificationsDeprecate feature as discussed in https://gitlab.cern.ch/push-notifications/notifications-design/-/issues/44Deprecate feature as discussed in https://gitlab.cern.ch/push-notifications/notifications-design/-/issues/44Next sprintEmmanuel OrmanceyEmmanuel Ormanceyhttps://gitlab.cern.ch/push-notifications/backend/-/issues/215Add users in batch2024-03-25T00:05:04+01:00Emmanuel OrmanceyAdd users in batchImplement batch user/group add in API
as discussed in https://gitlab.cern.ch/push-notifications/notifications-design/-/issues/44Implement batch user/group add in API
as discussed in https://gitlab.cern.ch/push-notifications/notifications-design/-/issues/44Next sprintEmmanuel OrmanceyEmmanuel Ormanceyhttps://gitlab.cern.ch/push-notifications/backend/-/issues/214Get preferences with only the device that is being tried to remove2024-03-25T00:05:04+01:00Caetan Tojeiro CarpenteGet preferences with only the device that is being tried to removehttps://gitlab.cern.ch/push-notifications/web-portal/-/issues/217https://gitlab.cern.ch/push-notifications/web-portal/-/issues/217Emmanuel OrmanceyJose SemedoEmmanuel Ormanceyhttps://gitlab.cern.ch/push-notifications/backend/-/issues/204Remove user's notification draft when notification is sent2024-03-25T00:05:04+01:00Caetan Tojeiro CarpenteRemove user's notification draft when notification is sentCurrently, sending a notifications keeps also the content in the draft, so going back to the send form, it will load the same content of the sent notificationCurrently, sending a notifications keeps also the content in the draft, so going back to the send form, it will load the same content of the sent notificationhttps://gitlab.cern.ch/push-notifications/backend/-/issues/191Improve edit-channel-by-id2024-03-25T00:05:04+01:00Jose SemedoImprove edit-channel-by-idhttps://gitlab.cern.ch/push-notifications/backend/-/issues/190Improve find-public-channels2024-03-25T00:05:04+01:00Jose SemedoImprove find-public-channelsJose SemedoJose Semedohttps://gitlab.cern.ch/push-notifications/backend/-/issues/181Improve activemq connection handling2024-03-25T00:05:04+01:00Carina AntunesImprove activemq connection handlingFollow up from: https://gitlab.cern.ch/push-notifications/backend/-/merge_requests/189
Seems like creating a connection per request is a big overhead. \
Look into using [Dependency injection](https://github.com/typestack/routing-control...Follow up from: https://gitlab.cern.ch/push-notifications/backend/-/merge_requests/189
Seems like creating a connection per request is a big overhead. \
Look into using [Dependency injection](https://github.com/typestack/routing-controllers#using-di-container) or an [ApplicationContext](https://github.com/typescript-tutorial/activemq-sample) to inject just one activeMQ connection which supports reconnect.
Perhaps https://github.com/core-ts/activemq (wrapper around `stompit` which we currently use) as inspirationCurrent sprint: Week 34 + 35https://gitlab.cern.ch/push-notifications/backend/-/issues/180Investigate 504 timeout - Jack usecase2022-06-30T14:41:44+02:00Jose SemedoInvestigate 504 timeout - Jack usecaseWhen attempting to send a notification, the POST resolves after 30secs in a `504 Gateway Time-out`.
No logging of any sort or other errors can be found.
POST was for sending a notification with an egroup as direct notification.When attempting to send a notification, the POST resolves after 30secs in a `504 Gateway Time-out`.
No logging of any sort or other errors can be found.
POST was for sending a notification with an egroup as direct notification.https://gitlab.cern.ch/push-notifications/backend/-/issues/179Follow-up from "[#140]Follow up [#127] : stats page improvements"2022-06-30T13:50:55+02:00Caetan Tojeiro CarpenteFollow-up from "[#140]Follow up [#127] : stats page improvements"The following discussion from !187 should be addressed:
- [ ] @jlopesda started a [discussion](https://gitlab.cern.ch/push-notifications/backend/-/merge_requests/187#note_5720819): (+2 comments)
> Do you need an array with all of ...The following discussion from !187 should be addressed:
- [ ] @jlopesda started a [discussion](https://gitlab.cern.ch/push-notifications/backend/-/merge_requests/187#note_5720819): (+2 comments)
> Do you need an array with all of the Notifications of the channel for the stats object?
>
> What stats are you getting from this?
>
> Do you maybe only need the number of notifications of the channel?
>
> If you do need Notification information, consider using one of the notification DTOs if they fit, making a new one if it makes sense.