Project

General

Profile

Feature #611

support for Message Of The Day (MOTD)

Added by Wojciech Kapcia over 5 years ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
2012-05-14
Due date:
2016-12-23
% Done:

100%

Database:
n/a
Source Code Disclaimer:
Additional charges approved:
No
Releases:

Description

Ability to set/modify/remove message of the day as described in XEP-0133: Service Administration

Associated revisions

Revision 4a28c1b7 (diff)
Added by Andrzej Wójcik 9 months ago

Issue #611 - added support for MOTD and welcome message

Revision 023f45b9 (diff)
Added by W Administrator 5 months ago

#611: fix reading welcome message from repository if it’s note set

History

#1 Updated by Artur Hefczyc over 5 years ago

  • Target version set to tigase-server-5.2.0

#2 Updated by Artur Hefczyc about 5 years ago

This is quite a bit of work as it requires not just ad-hoc, admin script, but also some changes in the Tigase core code, in SM.

#3 Updated by Artur Hefczyc about 5 years ago

  • Assignee set to Artur Hefczyc

#4 Updated by Artur Hefczyc over 4 years ago

  • Target version changed from tigase-server-5.2.0 to tigase-server-5.2.1

#5 Updated by Artur Hefczyc over 3 years ago

  • Target version changed from tigase-server-5.2.1 to tigase-server-7.0.0

#6 Updated by Artur Hefczyc over 2 years ago

  • Target version changed from tigase-server-7.0.0 to tigase-server-7.1.0
  • Source Code Disclaimer set to No

Pushed to the next version.

#7 Updated by Artur Hefczyc about 2 years ago

  • Target version changed from tigase-server-7.1.0 to tigase-server-7.2.0

#8 Updated by Artur Hefczyc 10 months ago

  • Due date set to 2016-12-16
  • Assignee changed from Artur Hefczyc to Andrzej Wójcik

Andrzej, please estimate work effort for such functionality. Based on this we will decide for which version we want to implement it.

#9 Updated by Andrzej Wójcik 10 months 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 10 months 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.

#11 Updated by Andrzej Wójcik 10 months ago

  • Assignee changed from Andrzej Wójcik to Artur Hefczyc

#13 Updated by Artur Hefczyc 10 months ago

  • Status changed from New to Feedback
  • Assignee changed from Artur Hefczyc to Andrzej Wójcik

#15 Updated by Andrzej Wójcik 10 months 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?

#16 Updated by Artur Hefczyc 10 months ago

Yes, I like both suggestions, the one for MOTD and the one for Welcome message.

#17 Updated by Andrzej Wójcik 9 months 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 EventBus

However I would like a second opinion on how I store data directly to UserRepository in MotdProcessor and 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")

#18 Updated by Artur Hefczyc 9 months ago

I really prefer if all the access to the repository/DB is done through XMPPResourceConnection object. There are methods for "setData" and similar which allow to access repository. If it is not possible, let me know.

#19 Updated by Andrzej Wójcik 9 months ago

%kobit Use of XMPPResourceConnection is not possible in this case.
  • I need to store data for a component in a UserRepository implementation - not for a user (to store data for user I use XMPPResourceConnection)
  • I need to read data in initialization time of a processor - no XMPPResourceConnection is avaialble
  • I need to set data using method from processor called from AdHoc command script - no way to get instance if XMPPResourceConnection

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 9 months 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 9 months 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 9 months 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.

#23 Updated by Artur Hefczyc 9 months ago

  • Status changed from In QA to Closed

Also available in: Atom PDF