Implement server-side login Jitsi Meet Polls

deleolajide commented 2 years ago

Port code from Lua to Java

See https://github.com/jitsi/jitsi-meet/blob/68eb0795eb6a87189e27001d2e95c701536dac3f/resources/prosody-plugins/mod_polls.lua

gjaekel commented 2 years ago

Big problems:

There's no name (owner?) shown for the polls
How to close and get rid of messages in the WebClients user interface?
Polls seems to be persisted at room properties. But the opened polls propagate to every existing room, esp. to the pinned ones.

Up to now, in our production installation, there actually three "nonsense votings" lingering around from some users quick evaluation. How to get rid of them at all, maybe by an SQL statement?

gjaekel commented 2 years ago

~~BTW: I get an exception at the AdminUI at plugins/rawpropertyeditor/groupchat-propertiesplugin.jsp on every empty(?) pinned room, but this is an OpenFire / RawProperty-Plugin issue:~~

java.lang.IncompatibleClassChangeError: Found class org.jivesoftware.openfire.muc.MUCRoom, but interface was expected
    at org.jivesoftware.openfire.plugin.RawPropertyEditorPlugin.getAndCheckGroupChat(RawPropertyEditorPlugin.java:129)
    at org.jivesoftware.openfire.plugin.RawPropertyEditorPlugin.getGroupChatProperties(RawPropertyEditorPlugin.java:140)
    at org.jivesoftware.openfire.plugin.rawpropertyeditor.groupchat_002dpropertiesplugin_jsp._jspService(groupchat_002dpropertiesplugin_jsp.java:156)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:71)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.jivesoftware.openfire.container.PluginServlet.handleJSP(PluginServlet.java:462)
    at org.jivesoftware.openfire.container.PluginServlet.service(PluginServlet.java:122)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1459)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
    at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1626)
    at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:226)
    at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
    at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
    at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:234)

Solved by upgrading to V1.0.2 of the RawPropertyEditor-Plugin

gjaekel commented 2 years ago

Observation: I found the poll data entries also at the special "focus" room. I delete them there and since this it seems that a client starts with an empty poll panel at least on a new room.

deleolajide commented 2 years ago

The implementation of Polls by Jitsi is meant for temporary rooms that get deleted after everyone leaves the room. Using Polls with persistent rooms in Openfire will require additional logic to clean up polls that have expired and adding an owner value to identify who created it. This is additional work and should be a new issue.

gjaekel commented 2 years ago

But for some reason the "three existing" polls appear at every room, even non-sticky new ones. This was reported by one of our users and verified by me.

deleolajide commented 2 years ago

But for some reason the "three existing" polls appear at every room, even non-sticky new one

Unfortunately, I can't reproduce this. MUC Properties are cached by Openfire. You might want to reduce the expiry time otherwise, the next time a non-sticky room is used, the non-expired polls will be sent to each participant when they join.

I have added additional code for making sure focus user is not sent polls data

https://github.com/igniterealtime/openfire-pade-plugin/commit/c0daaf81d81bf6fccddf65c8274cb119e902d6df

gjaekel commented 2 years ago

Thank you in advance. Unfortunately I had have no time yet to investigate how to actually produce the issue. Will report about later ...

gjaekel commented 2 years ago

I extracted lib/pade-1.6.3-SNAPSHOT.jar from Snapshot 20220324.143502-29 and put it the production environment. I double-checked to use the latest code by decompiling the class file OfMeetPlugin.class. But I see no improvement:

The poll stay persistent and appear in every room, even "sure never used before" ones.
The creators name field is empty.

It is listed within the properties of the special room ofmeet. Data is e.g.

jitsi.meet.polls.ha2s137drn
{"senderId":"618974af","senderName":"Jäkel, Guido","question":"Wie ist die Antwort?","answers":[{"voters":{},"name":"36"},{"voters":{"618974af":"Jäkel, Guido"},"name":"42"}],"id":"ha2s137drn"}

The voting disappears overall if deleting this.

gjaekel commented 2 years ago

Observation: Using the properties URL from history, e.g. https://<admin-ui>/plugins/rawpropertyeditor/groupchat-propertiesplugin.jsp?roomJID=_%40conference.xmpp.dnb.de&create=false, the property with the vote data is still accessible, even it the room has been left and closed down, i.e. disappear from the overview. And on re-using this room name, the vote also re-appear. Note that this are non-sticky rooms.

deleolajide commented 2 years ago

It might make sense to delete the poll when the room is destroyed in Openfire

deleolajide commented 2 years ago

This commit will remove all room polls when the room is destroyed. However, the data is cached and the poll will still be available if room is re-used before the cache expires

gjaekel commented 2 years ago

Can't believe: The call of props.remove(key) will not clear it from the cache?!? Then props.put(key,"") should made it unusable at least.

igniterealtime / openfire-pade-plugin

Implement server-side login Jitsi Meet Polls #403