FriendsOfFlarum Byōbu, well integrated, advanced private discussions

DCar

Good evening, I am working on setting up a private forum (currently hosted on FreeFlarum) for a very specific use case. It is desired that the registered users are able to conduct 'private discussions'. However, the registered users receive "you do not have permission to do that" after selection of recipient(s), entering discussion title, message and 'post discussion'.

It should be noted that the majority of registered users are assigned to two (2) groups. In this particular scenario, both users belong to the same two (2) groups. Tested from user profile with Private Discussions 'tag', also clicking on profile of intended recipient Controls. Send XXXXXXX a message;.

Permissions do not allow me to select all the possible groups to which registered users may be members, however I am able to select the one (1) group to which all registered users are members. For that group, I have set permissions (Global) to allow "Create Private Discussions with users", "Add more than 2 recipients to a private discussion".

Is there another permission setting the Group must possess to 'have permission to do that'? Administrators & moderators are able to create private discussions with users.

I am confident this is 'self inflicted' but am hopeful somehow may be able to help with resolving the issue.

jmillerv

DCar How many users are they trying to add to discussions? I've noticed that you have to enable a specific setting for adding more than 2 users to a private discussion.

DCar

jmillerv

Permissions (Global) for the groups, in which the users are members, are set to allow "Create Private Discussions with users" & "Add more than 2 recipients to a private discussion".

They cannot create any private discussions .... "you do not have permission to do that". Administrators are able to create private discussions. This is the reason I suspect there may be another permission required but have not been able to identify which one.

jmillerv

I'm reading through the code now because I have a need for being able to add tags to private discussions. I'm noticing that tags are explicitly removed from the PrivateDiscussionComposer.js inside the headerItems() function.

https://github.com/FriendsOfFlarum/byobu/blob/ddc795d2a25467ae63455804368b9bafc2b9acdb/js/src/forum/pages/discussions/PrivateDiscussionComposer.js#L85

What is the motivation behind this? I'm not terribly deep into this code, but is there a reason this was designed without being able to add tags? Do private discussions use elements of the tag feature that would be incompatible. Going to keep reading, through the code, but thought that was interesting.

Any help would be appreciated!

clarkwinkelmann

jmillerv tag permissions would likely interfere with private messaging permissions.

Tags were available on private discussions at some point in the past but the feature had to be removed because it was too difficult to maintain. It's unlikely to be added back in at this time.

jmillerv

clarkwinkelmann If tags aren't possible. Do you think it would be possible to integrate FoF Webhooks with private discussion. Right now, the webhooks are based on tags which is why I started with trying to add tags. I have a use case to send private discussions to webhooks.

clarkwinkelmann

DCar can you share your php flarum info output so we can see which other extensions are active on the forum?

DCar

clarkwinkelmann I will request that information (I am a mere Administrator on the FreeFlarum site).

DCar

clarkwinkelmann I've asked the individual who set up the FreeFlarum forum to run the command. However, he is unable to SSH to execute the command. Is there another method to run php flarum info on a FreeFlarum hosted forum?

Deanna

IanM

1.3.1

fix: PD blockers cannot start a new PD with non-blockers
fix: Unable to edit recipients when one or more existing recipients are blockers for new PDs
fix: resolving dependencies in migrations is bad practice by @SychO in #185

Updating

composer require fof/byobu:"*"
php flarum cache:clear

clarkwinkelmann

DCar you can see which extensions are enabled in the admin panel.

If you have a few, you should be able to write the list of make a screenshot.

In any case but especially if you have many extensions, you should try disabling some other extensions to see if the issue goes away. If the problem still exists with only Flarum core extensions + Byobu then there must definitely be a bug in the extension.

DCar

clarkwinkelmann List of enabled extensions:
AuditFree
BBCode
BBCode Button
Canonical URL
Checklists
Diff
Discussion Templates
Discussion Views
Discussion Cards
Edit Posts Button
Emoji
FOFBanIPs
FOFByobu
FOFDefaultGroup
FOFDefaultUserPreferences
FOFFollowTags
FOFFormatting
FOFImpersonate
FOFMasquerade
FOFMergeDiscussions
FOFProfileImageCrop
FOFSocialProfile
FOFSpamblock
FOFSplit
FOFStopForumSpam
FOFTerms
FOFUpload
FOFUserDirectory
FontAwesome6
Forum Widgets
GB Password Strength
Group List
Likes
Lock
Login2SeePlus
Markdown
Mentions
Move Posts
Post Permissions
Profile Cover
Rich Text
Scroll Buttons
Signature
Statistics
Sticky
Suspend
Tags

As a side note, I disabled each extension individually and tested - "you don't have permission...". I am willing to try disabling all non-core extensions. Is it safe to 'assume' the extension pre-fixed with 'FOF' are considered core?

Deanna

clarkwinkelmann

DCar no, other FriendsOfFlarum extensions could also be the cause.

I say that because most extensions, including FoF extensions, are usually tested together with Flarum core extensions during development. But it's a lot more difficult to test all FoF extensions together with realistic production configurations and data so this is rarely done.

Permissions issues are complicated to troubleshoot because the message doesn't say which part of the code or which extension triggered the denial. Even when we know which particular gate ability was designed, there could still be multiple extensions extending the logic for the same ability. Usually the problem is either a different extension denying something unrelated (hypothetical example, an extension requiring the discussion to have a poll, while at the same time private discussions not supporting it) or 2 extensions having priority issues over the same ability (example: tags extension could say something is permitted in a tag, while the extension itself says it's not)

Sometimes the only way to find out for sure is to replicate on a development setup. But for that we need to know which extensions and which settings will allow reproducing the issue, ideally limited to as few extensions as required for the problem to still occur.

DCar

clarkwinkelmann

I understand, the process of elimination. I disabled all non-FOF extensions and the issue continues. The next step would be to disable all extensions to determine if the issue continues.

This is an evaluation forum to determine whether Flarum will meet the requirements of the organization ~ it also has some 'features' which are not available in the alternative forum.

Deanna

DCar

clarkwinkelmann I disabled all extensions, with the exception of Byobu, the condition continues to exist.

Next steps in resolving this issues would be?

Deanna

DCar

clarkwinkelmann I have determined the cause of this issue, the Permission (Global) to "Start Discussions" when turned on for the users will permit the creation of private discussions. However, for this particular organization's 'use case' / requirements, users may only create discussions within specific 'tags' (accomplished via "restrict by tag").

I will 'chat' with the organization to determine whether private discussions / messages between users are an actual requirement or just a 'nice to have'.

Deanna

GreXXL

DCar do users have the permission to search users? Maybe you can share a screenshot of your permission setup. Also you should query FreeFlarum if the extension has been updated to the latest version that also fixed a permission error.

DCar

GreXXL the users have permission to search users. I will query FreeFlarum to determine if the latest version of the extension has been applied.

Thank you

luceos

DCar oh, so if the global "start discussions" permissions is disabled, then you cannot create private discussions either? Seems like a bug if the permission to make private discussions is actually allowing that.

DCar

luceos That is correct. If I enable the Permission (Global) to "Start Discussions" then they are able to create private discussions. If the Permission (Global) to "Start Discussions" is disabled, the users are unable to create private discussions.

I would call it a bug ... it appears the Global Permissions to Start Discussions takes precedence over the permission to create private discussions. On the other hand, that may be 'as designed'.

Deanna

DCar

luceos Just following up to inquire about 'how to' determine if the encountered behaviour is by design or a 'bug'. If a 'bug' how would one go about reporting the 'bug'?

« Previous Page Next Page »