friendsofflarum / byobu Goto Github PK

Users without permission to create normal discussions who create a private discussion will have their discussion held for approval. However the group having this permission will most likely not be able to access that discussion.

In comparison to Post level permission that we might need to whitelist (eg for Flagging), we need to whitelist the approval permission to access the discussion or allow auto approval or override the creation permission.. That last option might be easiest and fastest.

The reply count of private discussions is wrong beyond the original post, it shows 1 post less than there are: Only original post shows (0) replies, after first reply it's still (0), after second reply (1) etc.

This behaviour can be reproduced at the Devflarum sandbox server.

Whether this issue is related to #50, I don't know.

Starting a new discussion fails when no recipients are selected.

Posts within a private discussion might be flagged for being inappropriate, we need to allow groups that are allowed to moderate those flags to be able to see that post only! And allow control to apply moderation.

in case you're not a recipient you should not redirect to the new discussion..

Not sure how to handle this use case.

Confirmed

Using byobu 0.1.0-beta.18 and Flarum v0.1.0-beta.7.

When I open a new discussion window, the user list just spins and I can't continue. I have 410 members so not that many.

Thanks!

Unfortunately Devflarum is down at the moment, so I cannot verify this issue there.

On two different installations I made the following observation: Whenever I create a new private discussion via the user profile and do not alter the recipients (leave it at the two preselected), the created discussion will be public, having the is_private field in the newly created entry in the discussions table set to 0, having the is_private field in the created posts entry set to 0, and missing the expected new entries in the recipients table.

The user posting this supposedly private discussion has no indicator or warning before submitting the post, that this will become public.

Once the preselected recipients are altered (even though I might return to the preselected set), the private discussion will be created as expected.

This could be either optional or even better, an another extension.

First of all id like to say thank you for this great plugin.

a bug i ran into is that im not able to select a participant on my ipad. :-(
It blinks but doesn't select the user.

Kind regards,
Bing

If the user are not logged into the community and click the mention link will see page not found as link not valid. Will be maybe great to have a different situation require a login and maybe display a different error message if the account has no right to access the private message (maybe because wrong account).

The scenario:

• Admin or User A send a private message to User B
• User B receive the email notification and is not logged into the community
• User B follow the link and no page found is showed.

What user should see is a login page or a message that inform must be logged or have permission for see this private discussion.

Hello,

I was trying to transform PMs to public discussions by removing participants.

But I'm not able to. See this gif:

Before the update, I was getting the same error. I ended up reinstalling the extension and it worked fine. After updating, I continue to obtain this error through inspect element on google chrome:

Uncaught TypeError: Cannot read property 'toArray' forum-1f2c3c53.js:1090 of undefined

Some info about my environment:
Ubuntu 16.10
Apache 2.4.18
PHP 7.0.18
Flarum 0.1.0-beta.7

For now I've disabled the extension, hopefully we can get this fixed!
If you need more info let me know!

Wondering how hard it would be to turn a normal thread into a private discussion after it was already started?

We've got some posts that turn into debates (usually political). I was thinking it would be great to switch them to private after a certain point to keep it off the main forum but still allow the discussion to continue in private.

In this case, it would also be useful to people to be able to leave the discussion if they wanted as mentioned in #5 .

As reported here by Apoculos, only admins are able to add/remove users/groups to private discussions regardless how the permissions are setup. This issue is still present after updating to beta 7.

if I enable this plugin, the text field to enter a new discussion or reply to a discussion is somewhat broken with Firefox Android. You can still type somewhat, but when the onscreen keyboard is up you cant see what you are typing and the overall layout of the text editor is just broken.

As reported here and here, private discussions in a tag view are missing / loosing the byobu badge and the recipients indicators after every reload. Reloading the All Discussions view however shows these discussions properly. After opening one of these discussions and returning to the tag view, this specific private discussion shows as intended... until the tag view page is reloaded again.

In the second post to which I linked above, I indicated that the situation might have improved somewhat with beta 7, but I'm not sure anymore. I think, prior to beta 7 I had the private discussions excluded from the All Discussions view via the hide setting of the tag used in my case. That's why I didn't notice the different behaviour in the All Discussions view compared to the tag view.

https://discuss.flarum.org/d/4762-flagrow-by-bu-well-integrated-advanced-private-discussions/52

Added on discuss.flarum today, and tried to start a discussion with just myself and the members of the Admin/Mod/Staff groups. An admin could see the discussion, but when he clicked on it, he could only see a blank discussion.

There's no need for private discussions to be affected by Askimet* (see #2 for flagging spam), Sticky, Lock, Split or other such altering options.

*This is highly impractical considering mods/admins shouldn't have normal access to Private Discussions in order to monitor spam and remove false positives.

When sending user a message directly from user profile, I want a default tag to be added automatically.

We need to allow for webmasters to hide all private discussions once the extension is disabled. You might be doing this accidentally or as a requirement for an upgrade of the core.

There are several ways of doing this, one might be to create a temporary tag and assign all private discussions to that. But this relies heavily on the tags extension. Another way might be to set the deleted_at property of the discussion and remember on disk which discussion id's were hidden.

The user needs the ability to flag a private discussion where something is going wrong.
Admins/mods/groups with the appropriate permissions need to be able to see the private discussion when flagged.
The above groups need a way to exit the private discussion when the flagged incident has been resolved so the privacy can be restored if possible (controllable by the flagging user as well so admins cannot snoop).

As far as I've understood, the purpose of the introduction of the is-private field into the posts and discussions tables was to avoid that private discussions become visible while Byōbu is deactivated e.g. during an upgrade process.

Right now however, Byōbu sets neither the discussions.is-private field nor the posts.is-private field beyond the original post to 1. The consequence is, that only private discussions without replies stay invisible after deactivating Byōbu, every private discussion with at least one reply becomes visible (bar the original post) to everyone (if not restricted otherwise).

This behaviour can be reproduced at the Devflarum sandbox server.

https://discuss.flarum.org/d/4762-flagrow-by-bu-well-integrated-advanced-private-discussions/48

The new feature Permission can now be configured per tag doesn't seem to be working as intended.

I tried to set my permissions in a way, that private discussions are restricted to a specific tag (lets call it private). I tried those two options:

a) Restrict privat discussions globally and allow it individually for the private tag.

b) Allow privat discussions globally and restrict it individually for all but the private tag.

Option a) seems to me the most intuitive way to do it, but neither a) nor b) achieves what I want. In both cases, the global setting overrides the tag setting leaving privat messages generally disallowed in a) and allowed in b), the tag doesn't make a difference.

An issue with the core seems related to this observation: flarum/framework#1146

What I would like to see in a perfect world (in my case scenario) is the following:

When a user starts a new Discussion and selects a tag differently from private, the recipients selector should be greyed out. If he selects recipients first (also in the case of the link from the usercard), the tag input should only allow private (or the tag should be selected automatically).

One thing, I didn't make up my mind about yet: If a user selects two tags, one with the permission to open a private discussion, one that doesn't allow it, which setting should precede?

The flagrow split extension re-adds original tags, we should listen to the event and re-add recipients as well.

I just noticed that there was an already filed issue for realtime integration into flagrow byobu by @luceos. Is this still planned at all? I think it is a must have feature!

I know it's kind of stupid, but the functionality is almost there. Instead of adding a recipient, you also give a button to make the discussion as a draft. In this the discussion is neither shared with any recipient or to the whole community instead, it just saves in a draft section. It's kind of a message to your own self.

I hope this feature request makes sense for this extension.

hi, i got an issue when i'm installing flarum via web interface with flagrow/byobu installed.

SQLSTATE[23000]: Integrity constraint violation: 1022 Can't write; duplicate key in table '#sql-3292_16' (SQL: alter table `fxxrecipients` add constraint recipients_discussion_id_foreign foreign key (`discussion_id`) references `fxxdiscussions` (`id`) on delete cascade)

ENV

• Docker 17.06.1-ce
• CentOS 7
• PHP 7.1.8
• Mysql 5.7.19-community
• Nginx 1.12.1
• flarum/core version: v0.1.0-beta.7
• flagrow/byobu version: 0.1.0-beta.21

How to reproduce

1. install the latest flarum/core with the latest flagrow/byobu
2. use MariaDB-10.1.26 or Mysql-5.7.19 as database, ans use PHP-7.1.6/7/8
3. install flarum via web interface.

implement pusher integration, make it optional from settings

A closed discussion group is important, but private messages can also have, especially when i just told him a message for a person. Will you add the functionality of the private message?

It would be great to have a way to filter for private discussions.
This could be a separate page at the user menu, header (links extension) or maybe somehow at the sidebar, like other tags.

Functionality should be like the other tags, you click on it and will be shown all private discussions you are part of.

I just found out that if I click Tags on my main discussion Flarum page, I see Private Discussions previews without being signed-in.

In my screenshot:

• Under Announcement "Testing PM function"
• Under Approved Vendors "Hi Tyler Your account...."

When I click them I get the "You don't have permission...." error message.

They should not show up unless I am a party to the Private Discussions under the current extension developer's intent.

https://discuss.flarum.org/d/4762-flagrow-by-bu-well-integrated-advanced-private-discussions/83

Installed beta 8 from scratch (with composer create-project), then required the extension which also installed 2 flarum extensions extra somehow.

d:\Websites\flarum>composer require flagrow/byobu
Using version ^0.1.2 for flagrow/byobu
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 3 installs, 0 updates, 0 removals
  - Installing flarum/flarum-ext-pusher (v0.1.0-beta.6): Loading from cache
  - Installing flarum/flarum-ext-markdown (v0.1.0-beta.5): Loading from cache
  - Installing flagrow/byobu (0.1.2): Downloading (100%)
Writing lock file
Generating autoload files

When enabling the extension from the admin panel i got 2 exceptions

Seems like the user results are being calculated but not being shown...? Not sure why else it would get smaller when you put text it

Can you leave a space from the right of the textbox?

If I load the forum from a discussion page and then navigate to the index, the private discussion icons and member lists are not shown. If I load the forum on a PD discussion and navigate to the index, only this discussion has icon and member list
The other PDs are displayed as normal discussions

As a site owner/ operator, I don't need to sit and comb over all discussion but I need the tools to investigate an issue/ member, when reported by other or not, if the need arises.

We can disclose this in the Privacy Policies and User Agreement languages on the site or right when when a member creates a New Private Discussion ("Note: contents may be visible to Admin").

Thank you.
I am new to GitHub. I see a Blue Enhancement tag but I don't know how to add it to this request.

Being added to a private discussion should be similar to being mentioned. There should either be notification setting akin to “Someone mentions me in a post”, or, maybe even better, there should be a switch “Automatically follow private discussions that I am added to” (modelled after “Automatically follow discussions that I reply to”.)

@pflstr from #5

In my opinion, there are several questions to be answered.

a) Who can add or remove recipients of a private conversation? If it's only the admin it's quite easy, we just need to add a special case for a recipient wanting to leave a private discussion. This right will be given in addition to the right of the admin.

b) If the right to add and remove recipients of a private conversation is given to non-staff usergroups as well, one should be aware, that a breach of confidence might result, if posts older than the time of the change of recipients become accessible to new recipients. This needs to be avoided to protect a forum owner from legal implications. The right to leave such a discussion voluntarily would apply in this case as well.

c) If users are allowed to leave and reenter a private discussion, we may need more than one entry date and / or more than one leave date. The database query to filter out the posts that should be shown to such a user may become quite complex. What should be done with quotes from posts, that are not supposed to be shown to a certain user?

My suggestion: Don't let the list of recipients be altered after the start of a private discussion: The only exception should the case of a user leaving such a discussion voluntarily. Even in this case one should favor a solution, where the given recipient is not removed from the list but instead the discussion can be ignored by any recipient (and the ignoring can be revoked without legal consequences, because the user never really left).

If participants of a private discussion want to expell a certain user, they can simply start a new discussion without the given user.

One last question remains:

d) Who should have the right to close a private discussion? The original poster? Any participant? And who should have the right to reopen a closed discussion?

We're filtering the private discussions from the index right now, but we could also allow these to show up on the index page too. We just need a setting in the admin to do so.

When viewing flags on normal posts everything's fine. But normal flagged posts also appear inside PDs when viewing flagged content
So the issue is: every flagged post on the forum is displayed when an admin views a flagged PD

I've updated to the latest and clear cache files. Regular posts work now but private discussions give "requested resource was not found". Debug:

`POST http://www.golfbuzz.com/api/discussions

{
"errors": [
{
"status": "404",
"code": "resource_not_found"
}
]
}`

After starting a private discussion via the send userXYZ a message link on his UserPage, every attempt to start a new new discussion will preselect the previously selected users until the page is reloaded.

The bug can be easily reproduced at DevFlarum:

• Go to a users userpage
• Start a private discussion with him (opening the composer window suffices)
• Start another discussion anywhere
• Reload the page
• Start another discussion again

At stage 3, two recipients are preselected, at stage 5 they disappeared.

Allow an admin to configure one or more tags to be made private between the author and any recipients. This allows for tags to hold support issues or game master discussions you rather not want to be shared with others.

So the admin area will have the option to select a tag from the dropdown, with behind it the Recipient Select input field. From then on any new discussion with that tag will automatically hold the recipients specified ánd the author ; perhaps we can make the author optional as setting.

One member flagged a post in a PM. But as Admin nor moderators are involved in the discussion they cannot take action therefor inappropriate comment is still there!

Especially a discussion with multiple recipients, how would a participant leave?

Could they retain a copy of the messages thus far?

And could they be added back in?

Is it better to make this simple (move your feet, lose your seat; aka when you leave it's all gone) or complex to preserve ownership of messages?

When I have a discussion which is restricted to only moderator and would like to add a member, I should only see members who are allowed to read this post. I was able to add any other members who were not moderator. However this invited member was not able to see any private discussion because the member had no rights for this category.

Maybe it would be good if members, who have no rights, could be greyed out in the list as information that those members cannot participate in the discussion until they get the right permissions for this discussion/category.