Posting restrictions follow up
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:
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
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)
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 ofegroup-notification-master
. On save we would need to check authenticated user has permissions on said account (get /identity/upn, checkownerId
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, andbypass 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.