Build: #2221 was successful Scheduled with changes by daryl herzmann

Build result summary

Details

Completed
Queue duration
27 minutes
Duration
38 minutes
Labels
None
Agent
ip-172-31-27-151.eu-central-1.compute.internal
Revision
446a66a76b5f546116ce1b961c191a7d1e01ccc3
Total tests
1407
Successful since
#2204 ()

Tests

Code commits

Author Commit Message Commit date
daryl herzmann daryl herzmann 446a66a76b5f546116ce1b961c191a7d1e01ccc3 Merge pull request #2490 from guusdk/OF-2843_OF-2844_MUC-ban
OF-2843 & OF-2844: MUC ban improvements
Guus der Kinderen Guus der Kinderen 97a3212049efe1c50ef42abc03e34f31f11e8ed2 m OF-2843 & OF-2844: MUC ban improvements
An admin cannot ban an owner from a MUC room. XEP-0045 section 9.1 specifies:

> [A] user cannot be banned by an admin with a lower affiliation. Therefore, if an admin attempts to ban an owner, the service MUST deny the request and return a `<not-allowed/>` error to the sender

Openfire currently does send an error, but uses the `<conflict/>` condition. Instead, it must use the `<not-allowed/>` condition as specified by the XEP.

XEP-0045 Section 9.1 defines:

> If an admin or owner attempts to ban himself, the service MUST deny the request and return a `<conflict/>` error to the sender. (Note: This is different from the recommended service behavior on kicking oneself.)

Openfire currently allows admins to ban themselves. That should not be possible, as defined by the XEP.

Jira issues

IssueDescriptionStatus
Unknown Issue TypeOF-2843Could not obtain issue details from Jira
Unknown Issue TypeOF-2844Could not obtain issue details from Jira
Unknown Issue TypeXEP-0045Could not obtain issue details from Jira

Shared artifacts

Artifact File size
.rpm files 48 MB