-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
[FEATURE]: implement like lissine suggested in last comment #955
Comments
I need a logfile to debug this |
My initial description was a bit inaccurate.
Explanation: The cause of the bug is clicking on the conversation after its bookmark's deletion (but before closing and reopening the app). Presumably, Monal gets confused since it can't find the relevant bookmark. So it just assumes it's a 1-1 chat. |
is this still happening in the latest beta? |
Still reproducible on 6.0.1 (870) |
Just ran into such a situation with the latest alpha. Re-adding and then removing contact resolved the situation, however certainly would be nice to avoid such a situation in the first place. |
Can you check if this is fixed now using latest alpha or beta builds? |
Yes, this is indeed fixed on the latest beta. Thanks!
It would be nice to have the same treatment in both cases |
great! how does Conversations behave if the muc is removed from bookmarks by another client? I'd like to match those behaviours. |
@tmolitor-stud-tu If I close a MUC in Gajim, which removes the autojoin flag, Conversations also closes the MUC. If I join a MUC in Gajim, Conversations opens the MUC (but sometimes does not join it, if the MUC publishes your XMPP address). If I close a MUC in Conversations, which sets autojoin to "false", Gajim does nothing. |
Okay, I think not joining the muc is moot because the client adding that bookmark is most likely already joined as well. Other than that, I think I'll change Monal to match the behavior of Conversations And I consider Gajim not leaving the muc a bug. |
Currently Monal does the following: keep the entry in the "Chats" view if only the autojoin flag was removed and remove the entry if the whole bookmark was removed. Would that be sensible, too? Are you able to remove the whole bookmark using Conversations? Or is conversations always only removing the autojoin flag? |
According to XEP-0402: PEP Native Bookmarks:
Conversations doesn't follow this "SHOULD". It stays joined to the room. In my opinion, we shouldn't have a state where we're not joined to the channel but it is in the main "Chats" view. This is the case in Conversations as well: having a channel in the main "Chats" view means you're joined to that channel (unless the internet if off) @haansn08 Gajim isn't fully compatible with XEP-402 yet. See |
Conversations removes the entry from the Chats window if the autojoin flag becomes unset. If you want to re-join you need to "Start Conversation" -> "Group Chats" tab -> Click on a bookmarked MUC.
Closing the MUC in the Chats view sets autojoin to false, but does NOT remove the bookmark. It is possible to remove the bookmark entirely by going to "Group chat details" -> "Delete bookmark" or "Start Conversation" -> "Group Chats" -> Long press on any bookmarked MUC -> "Delete bookmark". |
Conversations and Gajim allow you to do both of those things. Steps to reproduce it simply: 1- Go to the "Contacts" view The issue is triggered by step 5, and you shouldn't have been allowed to do step 5- after you did step 3- Back to the protocol discussion, if you agreed with this idea
Then you can add a special UI for this kind of bookmarks in the "Contacts" view. |
Yes, I know. I just wanted to know your opinion on the protocol logic. For the UI rewrite we are planning to add a sticky notification into the chat that tells the user that they are not joined to that channel/group (with a button to quickly join). I'm not sure if that's a better approach than leaving the muc listed (greyed out) in the contact list and removing it from the "active chats" view. What do you think? As for the original issue: yes, you are right, there is just a refresh missing. But I thought I added just such a refresh in some of my recent commits, hence my question if the bug still persists. Sad to hear that this was apparently still not enough. |
I believe my latest alpha commit solves the issue, can you confirm that? |
@lissine0 ping (want to confirm this before releasing the next beta) |
Yes it is indeed fixed. (Sorry I forgot to reply) |
The latter approach is better IMHO. If the user isn't joined to a channel / group they wouldn't get any new messages. |
Thanks for your insights, that are indeed good arguments :) Great that it is fixed now! |
TODO: implement like lissine suggested |
What Monal Release channel are you using?
Alpha
iOS system version
16.7
iOS Monal version
6.0 (commit ef03f7b)
macOS system version
No response
macOS Monal version
No response
Used XMPP server (domain)
personal server
Which XMPP-Server software are you using?
Prosody
XMPP Server Software Version
0.12.4
How many accounts are you using in Monal?
2
What happened?
If Monal isn't displaying the Chat view for a MUC, and another client deletes its bookmark or removes the autojoin flag,
then Monal considers the MUC a one-to-one chat. And It deletes the avatar and the previous history.
You may need to close the app and re-open it to take effect.
Steps to reproduce:
Anything else?
If instead of step 2. you open the channel's chat view, then when the bookmark/autojoin is deleted, Monal will go back to the Chats view, and the channel in question will be nowhere to be seen (neither in the Chats list, nor in the Contacts list).
FAQ
Considerations for XMPP users
Related Issues
XEP-Check
Notifications-Menu
The text was updated successfully, but these errors were encountered: