Wojciech Kapcia (Tigase) opened 6 years ago
-
@wojtek According to the crash log the issue happened only because you already have 1-1 chat opened with
int@muc.tigase.org. This is something not expected and it's a difficult thing to handle automatically. In theory, I could assume that 1-1 chat was opened by mistake and replace it with group chat, but is it the desired solution?What do you think about this solution?
I suppose that this happened as you could receive some plain message from this group chat while you were not joined to the room which could open 1-1 chat. Could you check if you have 1-1 chat opened with this JID?
-
Symbolicated crash:
BeagleIM.app/Contents/MacOS/BeagleIM -arch x86_64 -l 0x1092a0000 0x00000001093895da DBRoomsManager.getRoomOrCreate(for:nickname:password:onCreate:) (in BeagleIM) (DBRoomsManager.swift:49)Points to the following line:
let dbRoom: DBChatStore.DBRoom = store.open(for: account, chat: room)!;so most likely method
open()ofstorereturnednil. -
I suppose that this happened as you could receive some plain message from this group chat while you were not joined to the room which could open 1-1 chat. Could you check if you have 1-1 chat opened with this JID? @andrzej.wojcik Indeed I do have it opened, and with messages from the room itself: https://www.dropbox.com/s/0rlxokkgd90e54c/Captura%20de%20pantalla%202019-06-17%20a%20las%2018.22.25.png?dl=0 No idea though how it was created.
However, even if I received them when I wasn't in the room (I assume app keeps track of what I joined and left) the messages arrive with
type='groupchat'so they should not create 1-to-1 conversation?I think this is a bug and 1-to-1 shouldn't have been created for groupchat in the first place, so we should convert it to proper chatroot item. (IMHO)
-
@wojtek MUC invitations are sent without
type=groupchatand errors are sent withouttype=groupchatas well (they havetype=error). So if for unknown yet reason you would receive an error when you are not joined to the room from that room then it would create 1-1 chat. The question is, do you have this 1-1 chat? Could you check? It should be visible in the chats list. -
I removed it from chat list (hoping it will solve the issue) but re-joining it via
[+]in groupchat section brings the history up: https://www.dropbox.com/s/b6mhq31zpqxs4cv/Captura%20de%20pantalla%202019-06-18%20a%20las%2013.18.48.png?dl=0 (the earliest messages I have for it)(and I think I'm still not joined)
-
That is weird. If you would be joined then status icon would be green. If it would be joining then status would be orange. Grey is almost always when the account is disconnected but will try to reconnect (not disabled), as when the account is disabled then its chats are removed from the chats list.
-
I didn't enter any nickname (beagle didn't protest that it's required so I assumed something [e.g. localpart of the JID] would be used) and it returned error. With nickname provided it works well.
Therefore I think it would be nice to:
- either enforce required fields or use some sane defaults
- use bookmarks to join the room
-
@wojtek Bookmarks are already used but those PEP based only. As for marking required fields, I'll look into that. Thank you for finding the root cause.
-
Shouldn't those be handled by
XEP-0411: Bookmarks Conversion(https://compliance.conversations.im/server/tigase.org/) ? -
@wojtek Anything else should be done? Or disabling a
Joinbutton is enough?As for bookmarks, yes it should work with XEP-0411, but you need to enable this in
Preferences. -
I would add some indication that nickname is required, maybe
(required)added to the placeholder text? To avoid confusion.I enabled that option and - nothing happened (?!). Where those bookmarks should be visible? In MUC join window there isn't anything extra, and top-right corner dropdown / toggle doesn't change anything
-
@wojtek Bookmarks should not be visible. There is no UI for them, it just works as I suppose most people expect it to work. Let me explain how.
When you are opening a group chat in Siskin/Beagle then with this option enabled it automatically modifies bookmarks by adding this new room. Thanks to that when you open your second client it will automatically be joined to that room. When you close a chat, then it is removed from the bookmarks. But other clients will not leave this group chat - this needs to be done manually to make sure that this is expected. When you add a bookmark in another client (ie. Psi) then Siskin/Beagle should automatically receive notification and join this room.
Thanks to that you have your group chats kept in sync between mobile devices and BeagleIM.
-
@andrzej.wojcik Well, I'm one of those that don't follow your assumption ;-)
I agree that this is how it works with most typical IMs now (whatsapp, telegram) but this is more related how you pertain to the MUC/group (you join and you are joined from all devices and receive messages from all devices or you leave the room). The XEP-0048 explicitly states it's intention to have links to rooms with optional autojoin at startup. What's more, assuming that me closing muc room indicates that I want to remove the bookmark is just iffy…
Background: I have about dozen groupchats in bookmarks but I auto-join only a couple of them.
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| Spent time |
0
|
Steps to reproduce:
intin room name and WITHOUT selecting any room click[join]Error log: