[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:
Problem/Incident
Relates
causality
supersession
is superseded by ADMINCTR-285 Display a global banner ahead of plan... Open
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: AdminX

 Description   

Steps to reproduce

  1.  Login as superuser and on the Messages Tool, send a message to All users
  2.  Login with an external user that does not exists at Security App (GroupResolver)
  3. Check he has no pending messages

Expected results

When the external user logs in, he has a new pending message to read

Actual results

The message is not sent to the external users

Workaround

N/A

Development notes

If we use the "Send to group" or "Send to user" option, then the message is sent as expected



 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,
thank you for investigating!
Our use case is quite simple: We would like to let all currently active editors know that we will be performing a release (short downtime in authoring). "Please save your work and grab a cup of coffee. Magnolia will be restarted in 5 Minutes and back very soon."

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
Chris

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.

Generated at Mon Feb 12 10:51:01 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.