Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add partial support for XEP-0249 Direct MUC Invitations #535

Merged
merged 1 commit into from
Apr 24, 2023

Conversation

MF1-MS
Copy link
Contributor

@MF1-MS MF1-MS commented Aug 1, 2022

This MR adds in partial support for XEP-0249 Direct MUC Invitations

It exposes a method for a MUC to invite a user to the room, and adds a listener to the MultiUserChat listener to inform users of direct invitations they have received.

A new UT class is added to test this function.

I found I could not build Smack without updating bouncy castle to 1.71 so have done so in this MR. Please advise how I would build without doing this if this is not desired.

Copy link
Member

@Flowdalic Flowdalic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution. I have left some remarks inline.

I think the most important issue that this is currently somehow entangled with some arbitrary MultiUserChat instance, when its business logic should really go into a new class DirectMucInviteManager.

@Flowdalic
Copy link
Member

I found I could not build Smack without updating bouncy castle to 1.71 so have done so in this MR. Please advise how I would build without doing this if this is not desired.

Bumping BC is fine. Since you give not details why you couldn't build without updating, I can't really help you there.

final MUCUser.Invite mucInvite = null;
final EntityJid from = message.getFrom().asEntityJidIfPossible();
if (from == null) {
LOGGER.warning("Group Chat Invitation from non entity JID: '" + message.toXML() + "'");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not super happy about that, as I believe it is likely that components, i.e., domain bare JIDs, could also send directed invites. I think we could change the signature of InvitationsLIstener to use just Jid for inviter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I agree. The end user the invitation is from should be the same regardless of if they're using an XEP-0249 direct invitation or a mediated XEP-0045 invitation. If we are asserting a user must be an entity jid in the XEP-0045 case then I think it's very reasonable to assert the same here.

@MF1-MS MF1-MS requested a review from Flowdalic August 16, 2022 09:17
@MF1-MS
Copy link
Contributor Author

MF1-MS commented Oct 10, 2022

OK sorry about the delay, that's amended now. I can squash the commits and amend the message if you're happy, but leaving as is for now for a cleaner diff.

Are you happy with my other PRs too?:
#537
#538

Copy link
Member

@Flowdalic Flowdalic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if you re-invented org.jivesoftware.util.Protocol with InvokeDirectlyResponder in your tests (or similar already existing classes of Smack's test fixtures). Please check that you don't invent the wheel again, I wouldn't be surprised if Smack wouldn't already provide what you need for the tests. Unfortunately, I had no time to dig into this further.

@MF1-MS
Copy link
Contributor Author

MF1-MS commented Feb 17, 2023

I am not sure if you re-invented org.jivesoftware.util.Protocol with InvokeDirectlyResponder in your tests (or similar already existing classes of Smack's test fixtures). Please check that you don't invent the wheel again, I wouldn't be surprised if Smack wouldn't already provide what you need for the tests. Unfortunately, I had no time to dig into this further.

I think these are suitably disparate. org.jivesoftware.util.Protocol (which seems to have an out of data docstring, but I found good usage examples in the Socks5 tests) seems focussed on enabling dialogues where Smack will be expecting responses to its requests, and verifying the requests Smack sent. The sent stanza we're verifying with InvokeDirectlyResponder is generated by Smack due to it conceptually receiving a message.

InvokeDirectlyResponder simply builds off the DummyConnection test fixture, capturing an outgoing stanza and verifying it.

@MF1-MS
Copy link
Contributor Author

MF1-MS commented Feb 17, 2023

I can squash the commits and amend the message if you're happy, but leaving as is for now for a cleaner diff.

Are you happy with my other PRs too?:
#537
#538

Copy link
Member

@Flowdalic Flowdalic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, only one minor thing, then this is ready to go.

Please

  1. squash the commits into one
  2. Add an table row for xep249 to
    * <tr>
    * <td>Roster Versioning</td>
    * <td><a href="https://xmpp.org/extensions/xep-0237.html">XEP-0237</a></td>
    * <td></td>
    * <td>Efficient roster synchronization.</td>
    * </tr>
    * <tr>
    * <td>Message Carbons</td>
    * <td><a href="https://xmpp.org/extensions/xep-0280.html">XEP-0280</a></td>
    * <td>{@link org.jivesoftware.smackx.carbons}</td>
    * <td>Keep all IM clients for a user engaged in a conversation, by carbon-copy outbound messages to all interested
    * resources.</td>
    * </tr>
    * <tr>
  3. rebase on the current master
  4. mention "Fixes SMACK-932" in the commit message's body. Also

@MF1-MS
Copy link
Contributor Author

MF1-MS commented Apr 21, 2023

Should be good to merge now :)

@Flowdalic
Copy link
Member

The commit message's subject currently reads "Fixes SMACK-932.". That is not really helpful if I look at a commit log only consisting of the commit subject.

Exposes a method for a MUC to invite a user to the room, and adds a listener to the MultiUserChat listener to inform users of direct invitations they have received.

Fixes SMACK-932.
@MF1-MS
Copy link
Contributor Author

MF1-MS commented Apr 24, 2023

Ok, commit message re-arranged.

@Flowdalic Flowdalic changed the title Xep 0249 support Add partial support for XEP-0249 Direct MUC Invitations. Apr 24, 2023
@Flowdalic Flowdalic changed the title Add partial support for XEP-0249 Direct MUC Invitations. Add partial support for XEP-0249 Direct MUC Invitations Apr 24, 2023
@Flowdalic Flowdalic added this pull request to the merge queue Apr 24, 2023
Merged via the queue into igniterealtime:master with commit 50eb948 Apr 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants