[MGNLSSO-90] SSO-Users not receiving Messages when "Send to all" option used Created: 08/Jun/21 Updated: 31/Mar/23 Resolved: 05/Oct/22 |
|
| Status: | Closed |
| Project: | Single Sign On |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Carlos Cantalapiedra | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 3 |
| Labels: | maintenance | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Template: |
|
||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||
| Epic Link: | SSO support for custom IdPs | ||||||||||||||||||||
| Team: | |||||||||||||||||||||
| Description |
| Comments |
| Comment by Mikaël Geljić [ 17/Aug/22 ] |
|
In both cases, the SsoConnectorUserManager (incubator) and the SsoUserManager (newer) do not implement #getAllUsers, leaving it to throw an UnsupportedOperationException, via superclass ExternalUserManager. —Mostly for good reason as it would be inefficient at best. The exception is swallowed down the road in MessagesManagerImpl#broadcastMessage, but should yield an error in the logs anyhow: Unable to broadcast message because UserManager does not support enumerating its users Now, the messages backend stores messages on a user basis (and just iterates sequentially for group-sending). This is the part that needs to be revised if we want to address this issue without taking a scale penalty. i.e. storing messages individually with their associated scope, then aggregate these when querying messages for a specific user. Caveats: reads and deletions per user. We may assume that only a fraction of the whole user directory are effectively logging into Magnolia. That's for the technical explanation. That being said, shall we enquire what problem customers are trying to solve in the first place, by sending a message to all? Especially as the Messages app is historically a development sample (hence its group in the app-launcher). Possible workaround, as this will unlikely result in a short-term fix: extend the respective UserManager and implement #getAllUsers according to project specifics and minding the potential inefficiencies highlighted above. Possibly narrow down the set of users to actual magnolia users, e.g. based on a group attribute. Hope this helps, |
| Comment by Christopher Chard [ 18/Aug/22 ] |
|
Hi mgeljic, We do this currently by sending emails, but it would be "nice" to be able to relay an additional message to active users in system. Any other idea how to do this (for SSO-users...)? Cheers |
| Comment by Martin Jakob [ 16/Sep/22 ] |
|
Hey guys, we have another use case - we use SSO, so our users login using Azure AD. There are no internal users in our Magnolia author instance. Using the according 4-eye workflow we'd like to inform the publishers via e-mail when an editor creates a new publish request for his edited content. Would be awesome if you find a solution or a workaround for this. Thank you very much! Cheers Martin |
| Comment by Mikaël Geljić [ 22/Sep/22 ] |
|
Hi martin.jakob, Unlike messages, tasks are not stored by users, so users mapped to publishers group via SSO do see publication requests in the Tasks app. About sending emails, our SUPPORT team can advise better about options. There is an incubator module Task Email Notifications; an email alias for publishers might help as well. Cheers, |
| Comment by Mikaël Geljić [ 05/Oct/22 ] |
|
I filed MGNLUI-7550 to track the global banner use case, therefore closing this one here. |