support for Message Of The Day (MOTD)
Ability to set/modify/remove message of the day as described in XEP-0133: Service Administration
#9 Updated by Andrzej Wójcik over 2 years ago
%kobit We have our custom
message broadcast feature which delivers messages in specified time frame to every logged in user only once. I wonder if we could use it here and just add adhoc command which will use this
message broadcast feature. If so, then it should be easy to implement.
#10 Updated by Artur Hefczyc over 2 years ago
I thought for a while about this approach too. However, this is completely different use-case. MOTD is not sent to all online users like a broadcast. It is a message which is sent to each user right away after he logins into the system and it is sent only no more than once a day. So the ad-hoc command would be only used to set the current MOTD on the server (ideally on all cluster nodes from a single command).
Therefore, I think it should/could/might be implemented in a completely different way. Maybe like kind of a processor which is executed somehow just after a user logins/binds resource/sends initial presence. However, I am not sure if processor would be the most efficient solution in this case. I think SM has some hooks for events like resource bind, initial presence, etc... which are used by the clustering strategy. Maybe MOTD could be executed from such a method or maybe from the presence plugin.
#15 Updated by Andrzej Wójcik over 2 years ago
Ok, so for now I think that use of
custom message broadcast is not a good idea and may be an overkill in this case.
But we could use
UserRepository to store date of last time motd was delivered for each user and add separate processor handling initial presence to send message to user. (We should use new presence processor as we need to send message to user after it sets priority as XMPP server should not send messages to clients with priority lower than 0).
And then separate adhoc script which would set MOTD in UserRepository to store for server between restarts. Additionally processor would keep this value in memory for faster access and in 7.2.0 we should have access from adhoc commands of SM to SM processors and could use this MOTD processor method to update this value. This should be good and "simple" solution from MOTD.
A similar approach we can do for JabberIqRegister processor. It can always send message to offline user which got created and this will be delivered to user after first connection and will work as a welcome message.
%kobit What do you think about this approach?
#17 Updated by Andrzej Wójcik over 2 years ago
- Status changed from Feedback to In QA
- Assignee changed from Andrzej Wójcik to Wojciech Kapcia
- % Done changed from 0 to 100
Feature is implemented and working properly. Propagation of changes in cluster is ensured using
However I would like a second opinion on how I store data directly to
JabberIqRegister@. I wonder if this should be left as it is (direct access to instance of @UserRepository@) or if we should create some wrapper which will allow to access data only for @SessionManager (user_jid == "sess-man")
#19 Updated by Andrzej Wójcik over 2 years ago
%kobit Use of
XMPPResourceConnection is not possible in this case.
I need to store data for a component in a
UserRepositoryimplementation - not for a user (to store data for user I use @XMPPResourceConnection@)
I need to read data in initialization time of a processor - no
I need to set data using method from processor called from AdHoc command script - no way to get instance if
So to sum up, my goal is to store data in
UserRepository and in theory I could use
ComponentRepository storing data in UA. However
ComponentRepository is too complex for this task and too big and due to that I would like to have something different - ie. allow SM to inject instance of a new class which would allow us to store data in
UserRepository but for a component (not for user). It would be same thing for a component as
XMPPResourceConnection for a user data.
Currently I used
UserRepository because it was already in place and available (thanks to Kernel framework and dependency injection).
#20 Updated by Wojciech Kapcia over 2 years ago
- Assignee changed from Wojciech Kapcia to Artur Hefczyc
Artur Hefczyc wrote:
If it is not possible, let me know.
Assigning to Artur as per above quote.
As for the issue - I concur Andrzej idea that we could/should extend
plugin API to allow storing some generic/general/shared non-user data available to all users to avoid direct access to UserRepo instance.
#21 Updated by Artur Hefczyc over 2 years ago
- Assignee changed from Artur Hefczyc to Andrzej Wójcik
Yes, of course, general MOTD management cannot be done through XMPPResourceConnection and I am fine with how it is done right now.
My remarks about XMPPResourceConnection were related to the piece of logic which ensures that MOTD is sent to a user no more than once a day. I thought we need to record in DB information when the MOTD was sent to a user last time, so every time it logins during the day he does not get the MOTD.
#22 Updated by Andrzej Wójcik over 2 years ago
- Due date changed from 2016-12-16 to 2016-12-23
- Assignee changed from Andrzej Wójcik to Artur Hefczyc
Yes, and for recording time of last MOTD delivery I'm using XMPPResourceConnection.
In this case we can close this issue or create new repository class for SM to make it possible to store informations related to component using this class rather that directly using @UserRepository@.
%kobit Let me know what you decide.