2010-05-07 04:47:10 -05:00
|
|
|
/*
|
2011-12-03 16:38:03 -06:00
|
|
|
* Copyright 2009-2011, Andrea Anzani. All rights reserved.
|
|
|
|
* Copyright 2009-2011, Pier Luigi Fiorini. All rights reserved.
|
2010-05-07 04:47:10 -05:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Andrea Anzani, andrea.anzani@gmail.com
|
|
|
|
* Pier Luigi Fiorini, pierluigi.fiorini@gmail.com
|
2011-12-14 17:36:27 -06:00
|
|
|
*
|
|
|
|
* Contributors:
|
|
|
|
* Dario Casalinuovo
|
2010-05-07 04:47:10 -05:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <Application.h>
|
2010-05-16 16:02:50 -05:00
|
|
|
#include <Debug.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <Entry.h>
|
2010-05-30 07:17:32 -05:00
|
|
|
#include <Notification.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <Path.h>
|
2021-06-02 16:53:03 -05:00
|
|
|
#include <StringList.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <TranslationUtils.h>
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
#include "Account.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
#include "AccountManager.h"
|
2010-05-16 16:02:50 -05:00
|
|
|
#include "CayaMessages.h"
|
|
|
|
#include "CayaProtocol.h"
|
2012-03-08 16:55:13 -06:00
|
|
|
#include "CayaPreferences.h"
|
2010-05-19 15:37:26 -05:00
|
|
|
#include "CayaProtocolMessages.h"
|
2021-06-12 21:42:10 -05:00
|
|
|
#include "CayaUtils.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
#include "ImageCache.h"
|
2021-06-08 15:32:04 -05:00
|
|
|
#include "InviteDialogue.h"
|
|
|
|
#include "ProtocolLooper.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
#include "ProtocolManager.h"
|
2021-06-13 02:34:11 -05:00
|
|
|
#include "RoomFlags.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
#include "RosterItem.h"
|
2010-05-16 16:02:50 -05:00
|
|
|
#include "Server.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
|
|
|
|
Server::Server()
|
2010-05-19 17:28:26 -05:00
|
|
|
:
|
2012-02-27 18:46:15 -06:00
|
|
|
BMessageFilter(B_ANY_DELIVERY, B_ANY_SOURCE)
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-06-15 00:19:52 -05:00
|
|
|
_InitDefaultCommands();
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-05-19 17:28:26 -05:00
|
|
|
void
|
2010-05-07 04:47:10 -05:00
|
|
|
Server::Quit()
|
|
|
|
{
|
2021-06-12 21:42:10 -05:00
|
|
|
for (int i = 0; i < fLoopers.CountItems(); i++)
|
|
|
|
RemoveProtocolLooper(fLoopers.KeyAt(i));
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
void
|
|
|
|
Server::LoginAll()
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2010-05-16 16:02:50 -05:00
|
|
|
for (uint32 i = 0; i < fLoopers.CountItems(); i++) {
|
|
|
|
ProtocolLooper* looper = fLoopers.ValueAt(i);
|
|
|
|
|
|
|
|
BMessage* msg = new BMessage(IM_MESSAGE);
|
2010-05-19 15:37:26 -05:00
|
|
|
msg->AddInt32("im_what", IM_SET_OWN_STATUS);
|
2010-05-16 16:02:50 -05:00
|
|
|
msg->AddInt32("status", CAYA_ONLINE);
|
|
|
|
looper->PostMessage(msg);
|
|
|
|
}
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
filter_result
|
|
|
|
Server::Filter(BMessage* message, BHandler **target)
|
|
|
|
{
|
|
|
|
filter_result result = B_DISPATCH_MESSAGE;
|
|
|
|
|
2010-05-19 17:28:26 -05:00
|
|
|
switch (message->what) {
|
2011-12-14 17:36:27 -06:00
|
|
|
case CAYA_CLOSE_CHAT_WINDOW:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
BString id = message->FindString("chat_id");
|
2010-05-16 16:02:50 -05:00
|
|
|
if (id.Length() > 0) {
|
2010-05-07 04:47:10 -05:00
|
|
|
bool found = false;
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
// Conversation* item = fChatMap.ValueFor(id, &found);
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case IM_MESSAGE:
|
|
|
|
result = ImMessage(message);
|
|
|
|
break;
|
2011-12-14 17:36:27 -06:00
|
|
|
|
|
|
|
case CAYA_REPLICANT_MESSENGER:
|
|
|
|
{
|
2012-02-27 18:46:15 -06:00
|
|
|
BMessenger* messenger = new BMessenger();
|
2011-12-14 17:36:27 -06:00
|
|
|
|
|
|
|
status_t ret = message->FindMessenger(
|
2012-02-27 18:46:15 -06:00
|
|
|
"messenger", messenger);
|
2011-12-14 17:36:27 -06:00
|
|
|
|
2012-02-27 18:46:15 -06:00
|
|
|
if (ret != B_OK || !messenger->IsValid()) {
|
2011-12-14 17:36:27 -06:00
|
|
|
printf("err %s\n", strerror(ret));
|
2012-02-27 18:46:15 -06:00
|
|
|
break;
|
2011-12-14 17:36:27 -06:00
|
|
|
}
|
2012-02-27 18:46:15 -06:00
|
|
|
AccountManager* accountManager = AccountManager::Get();
|
|
|
|
accountManager->SetReplicantMessenger(messenger);
|
2012-03-03 20:27:16 -06:00
|
|
|
accountManager->ReplicantStatusNotify(accountManager->Status());
|
2011-12-14 17:36:27 -06:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-06-11 20:33:28 -05:00
|
|
|
case CAYA_DISABLE_ACCOUNT:
|
|
|
|
{
|
|
|
|
int64 instance = 0;
|
|
|
|
if (message->FindInt64("instance", &instance) != B_OK) {
|
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
RemoveProtocolLooper(instance);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-06-15 00:45:51 -05:00
|
|
|
case CAYA_REQUEST_HELP:
|
|
|
|
{
|
|
|
|
BString body;
|
|
|
|
BString cmd_name = message->FindString("misc_str");
|
2021-06-15 00:59:00 -05:00
|
|
|
int64 instance = message->FindInt64("instance");
|
2021-06-15 00:45:51 -05:00
|
|
|
Conversation* chat = _EnsureConversation(message);
|
|
|
|
|
|
|
|
if (chat == NULL)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (cmd_name.IsEmpty() == false) {
|
2021-06-15 00:59:00 -05:00
|
|
|
ChatCommand* cmd = CommandById(cmd_name, instance);
|
2021-06-15 00:45:51 -05:00
|
|
|
if (cmd == NULL)
|
|
|
|
body = "-- That command doesn't exist. Try '/help' for a "
|
|
|
|
"list.\n";
|
|
|
|
else {
|
|
|
|
body = "** ";
|
|
|
|
body << cmd->GetName() << " ― " << cmd->GetDesc() << "\n";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
2021-06-15 14:40:28 -05:00
|
|
|
CommandMap combinedCmds;
|
|
|
|
combinedCmds.AddList(fCommands);
|
|
|
|
combinedCmds.AddList(chat->GetProtocolLooper()->Commands());
|
|
|
|
|
2021-06-15 00:45:51 -05:00
|
|
|
body << "** Commands: ";
|
2021-06-15 14:40:28 -05:00
|
|
|
for (int i = 0; i < combinedCmds.CountItems(); i++) {
|
|
|
|
ChatCommand* cmd = combinedCmds.ValueAt(i);
|
2021-06-15 00:45:51 -05:00
|
|
|
if (i > 0) body << ", ";
|
|
|
|
body << cmd->GetName();
|
|
|
|
}
|
|
|
|
body << "\n";
|
|
|
|
}
|
|
|
|
BMessage* help = new BMessage(IM_MESSAGE);
|
|
|
|
help->AddInt32("im_what", IM_MESSAGE_RECEIVED);
|
|
|
|
help->AddString("body", body);
|
|
|
|
help->AddInt64("when", 0);
|
|
|
|
chat->ImMessage(help);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
default:
|
|
|
|
// Dispatch not handled messages to main window
|
|
|
|
break;
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
2010-05-28 17:38:16 -05:00
|
|
|
return result;
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
filter_result
|
|
|
|
Server::ImMessage(BMessage* msg)
|
2010-05-28 17:38:16 -05:00
|
|
|
{
|
2010-05-07 04:47:10 -05:00
|
|
|
filter_result result = B_DISPATCH_MESSAGE;
|
|
|
|
int32 im_what = msg->FindInt32("im_what");
|
|
|
|
|
|
|
|
switch (im_what) {
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_CONTACT_LIST:
|
|
|
|
{
|
|
|
|
int i = 0;
|
|
|
|
BString id;
|
2021-05-31 13:04:58 -05:00
|
|
|
while (msg->FindString("user_id", i++, &id) == B_OK)
|
|
|
|
_EnsureContact(msg);
|
2010-05-19 15:37:26 -05:00
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case IM_OWN_STATUS_SET:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
|
|
|
int32 status;
|
|
|
|
const char* protocol;
|
|
|
|
if (msg->FindInt32("status", &status) != B_OK)
|
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
if (msg->FindString("protocol", &protocol) != B_OK)
|
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
|
|
|
|
AccountManager* accountManager = AccountManager::Get();
|
|
|
|
accountManager->SetStatus((CayaStatus)status);
|
2011-12-14 17:36:27 -06:00
|
|
|
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
}
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_STATUS_SET:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
|
|
|
int32 status;
|
|
|
|
|
|
|
|
if (msg->FindInt32("status", &status) != B_OK)
|
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
|
2021-06-02 16:53:03 -05:00
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
if (!user)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
|
|
|
|
2021-06-02 16:53:03 -05:00
|
|
|
user->SetNotifyStatus((CayaStatus)status);
|
2012-03-07 18:47:00 -06:00
|
|
|
BString statusMsg;
|
|
|
|
if (msg->FindString("message", &statusMsg) == B_OK) {
|
2021-06-02 16:53:03 -05:00
|
|
|
user->SetNotifyPersonalStatus(statusMsg);
|
2012-03-07 18:47:00 -06:00
|
|
|
}
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
}
|
2021-05-31 13:04:58 -05:00
|
|
|
case IM_OWN_CONTACT_INFO:
|
|
|
|
{
|
|
|
|
Contact* contact = _EnsureContact(msg);
|
|
|
|
if (contact != NULL) {
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
contact->GetProtocolLooper()->SetOwnId(contact->GetId());
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_CONTACT_INFO:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
Contact* contact = _EnsureContact(msg);
|
|
|
|
if (!contact)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
2010-05-16 16:02:50 -05:00
|
|
|
|
2010-05-19 12:11:22 -05:00
|
|
|
const char* name = NULL;
|
|
|
|
|
2021-06-07 11:45:30 -05:00
|
|
|
if ((msg->FindString("user_name", &name) == B_OK)
|
2010-05-28 16:31:53 -05:00
|
|
|
&& (strcmp(name, "") != 0))
|
2021-05-24 01:47:21 -05:00
|
|
|
contact->SetNotifyName(name);
|
2012-03-07 13:22:09 -06:00
|
|
|
|
|
|
|
BString status;
|
2021-06-07 00:03:15 -05:00
|
|
|
if (msg->FindString("message", &status) == B_OK)
|
2021-05-24 01:47:21 -05:00
|
|
|
contact->SetNotifyPersonalStatus(status);
|
2010-05-28 16:31:53 -05:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case IM_EXTENDED_CONTACT_INFO:
|
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
Contact* contact = _EnsureContact(msg);
|
|
|
|
if (!contact)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
2010-05-28 16:31:53 -05:00
|
|
|
|
2021-05-24 01:47:21 -05:00
|
|
|
if (contact->GetName().Length() > 0)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
2010-05-28 16:31:53 -05:00
|
|
|
|
|
|
|
const char* name = NULL;
|
|
|
|
|
2021-06-07 11:45:30 -05:00
|
|
|
if ((msg->FindString("full_name", &name) == B_OK)
|
2010-05-28 16:31:53 -05:00
|
|
|
&& (strcmp(name, "") != 0))
|
2021-05-24 01:47:21 -05:00
|
|
|
contact->SetNotifyName(name);
|
2021-06-07 11:45:30 -05:00
|
|
|
else if ((msg->FindString("user_name", &name) == B_OK)
|
|
|
|
&& (strcmp(name, "") != 0))
|
|
|
|
contact->SetNotifyName(name);
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
}
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_AVATAR_SET:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-05-31 11:56:45 -05:00
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
if (!user)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
|
|
|
|
2010-05-07 04:47:10 -05:00
|
|
|
entry_ref ref;
|
2010-05-29 23:28:04 -05:00
|
|
|
|
|
|
|
if (msg->FindRef("ref", &ref) == B_OK) {
|
|
|
|
BBitmap* bitmap = BTranslationUtils::GetBitmap(&ref);
|
2021-05-31 11:56:45 -05:00
|
|
|
user->SetNotifyAvatarBitmap(bitmap);
|
2010-05-29 23:28:04 -05:00
|
|
|
} else
|
2021-05-31 11:56:45 -05:00
|
|
|
user->SetNotifyAvatarBitmap(NULL);
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
}
|
2021-05-26 07:48:25 -05:00
|
|
|
case IM_CREATE_CHAT:
|
|
|
|
{
|
|
|
|
BString user_id = msg->FindString("user_id");
|
|
|
|
if (user_id.IsEmpty() == false) {
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
User* user = ContactById(user_id, msg->FindInt64("instance"));
|
2021-05-26 07:48:25 -05:00
|
|
|
user->GetProtocolLooper()->PostMessage(msg);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case IM_CHAT_CREATED:
|
|
|
|
{
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
2021-05-31 11:56:45 -05:00
|
|
|
User* user = _EnsureUser(msg);
|
2021-05-26 07:48:25 -05:00
|
|
|
|
|
|
|
if (chat != NULL && user != NULL) {
|
|
|
|
chat->AddUser(user);
|
2021-05-28 22:26:32 -05:00
|
|
|
chat->ShowView(false, true);
|
2021-05-26 07:48:25 -05:00
|
|
|
}
|
2021-05-27 11:15:30 -05:00
|
|
|
|
2021-05-26 07:48:25 -05:00
|
|
|
break;
|
|
|
|
}
|
2021-06-01 21:43:19 -05:00
|
|
|
case IM_JOIN_ROOM:
|
|
|
|
{
|
|
|
|
SendProtocolMessage(msg);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case IM_ROOM_JOINED:
|
|
|
|
{
|
2021-06-04 16:32:18 -05:00
|
|
|
_EnsureConversation(msg);
|
2021-06-01 21:43:19 -05:00
|
|
|
break;
|
|
|
|
}
|
2021-06-02 16:53:03 -05:00
|
|
|
case IM_ROOM_PARTICIPANTS:
|
|
|
|
{
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
BStringList ids;
|
|
|
|
BStringList name;
|
|
|
|
|
|
|
|
msg->FindStrings("user_name", &name);
|
|
|
|
if (msg->FindStrings("user_id", &ids) != B_OK)
|
|
|
|
break;
|
|
|
|
|
|
|
|
ProtocolLooper* protoLooper = _LooperFromMessage(msg);
|
|
|
|
|
|
|
|
for (int i = 0; i < ids.CountStrings(); i++) {
|
|
|
|
User* user = _EnsureUser(ids.StringAt(i), protoLooper);
|
|
|
|
|
|
|
|
if (name.CountStrings() >= i) {
|
|
|
|
user->SetNotifyName(name.StringAt(i));
|
|
|
|
}
|
|
|
|
chat->AddUser(user);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2021-06-07 00:03:15 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_JOINED:
|
2021-06-02 16:53:03 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_LEFT:
|
2021-06-07 00:03:15 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_BANNED:
|
|
|
|
case IM_ROOM_PARTICIPANT_KICKED:
|
2021-06-02 16:53:03 -05:00
|
|
|
{
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
2021-06-07 00:03:15 -05:00
|
|
|
if (chat == NULL)
|
2021-06-02 16:53:03 -05:00
|
|
|
break;
|
2021-06-07 00:03:15 -05:00
|
|
|
chat->ImMessage(msg);
|
2021-06-02 16:53:03 -05:00
|
|
|
break;
|
2021-06-04 13:57:04 -05:00
|
|
|
}
|
2021-06-13 01:16:30 -05:00
|
|
|
case IM_ROOM_METADATA:
|
|
|
|
{
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
if (chat != NULL)
|
|
|
|
chat->ImMessage(msg);
|
|
|
|
break;
|
|
|
|
}
|
2021-06-07 11:45:30 -05:00
|
|
|
case IM_ROOM_ROLECHANGED:
|
Support for "Roles" (user, moderator, admin, etc.)
Add scaffodling support for arbitrary roles and permission-based (and
varying!) UI.
A new class, Role, represents a user's role in a given room, with three
values:
* The role's title
* The role's permission-set
* The role's priority
The permission set is a bitmask value for various permissions (e.g.,
PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy.
A user with higher priority (and PERM_BAN) can ban a user with lower
priority, but not vice-versa. Two users with the same priority can't
ban/kick/mute each other, etc.
These permissions should be used to determine what UI elements are
displayed― if the user doesn't have permission to ban users, then a
"Ban" button shouldn't exist. If the user is muted, they shouldn't be
able to type. So on and so forth.
For now, permissions are sent with a IM_ROLECHANGE message and stored
by the Conversation, but aren't really in use yet.
This system should be flexible groundwork to account for the varying
administrative hierarchies and norms of different protocols.
2021-06-06 00:41:45 -05:00
|
|
|
{
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
BString user_id;
|
|
|
|
Role* role = _GetRole(msg);
|
|
|
|
|
|
|
|
if (chat == NULL || msg->FindString("user_id", &user_id) != B_OK
|
|
|
|
|| role == NULL)
|
|
|
|
break;
|
|
|
|
|
|
|
|
chat->SetRole(user_id, role);
|
|
|
|
break;
|
|
|
|
}
|
2021-06-07 11:45:30 -05:00
|
|
|
case IM_ROOM_NAME_SET:
|
2021-06-06 18:06:46 -05:00
|
|
|
{
|
|
|
|
BString name;
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
if (msg->FindString("chat_name", &name) != B_OK || chat == NULL)
|
|
|
|
break;
|
|
|
|
|
|
|
|
chat->SetNotifyName(name.String());
|
|
|
|
break;
|
|
|
|
}
|
2021-06-07 11:45:30 -05:00
|
|
|
case IM_ROOM_SUBJECT_SET:
|
2021-06-04 13:57:04 -05:00
|
|
|
{
|
|
|
|
BString subject;
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
if (msg->FindString("subject", &subject) != B_OK || chat == NULL)
|
|
|
|
break;
|
|
|
|
|
|
|
|
chat->SetNotifySubject(subject.String());
|
|
|
|
break;
|
2021-06-02 16:53:03 -05:00
|
|
|
}
|
2012-03-11 10:11:29 -05:00
|
|
|
case IM_SEND_MESSAGE:
|
|
|
|
{
|
2010-05-16 16:02:50 -05:00
|
|
|
// Route this message through the appropriate ProtocolLooper
|
2021-05-24 01:47:21 -05:00
|
|
|
Conversation* conversation = _EnsureConversation(msg);
|
|
|
|
if (conversation->GetProtocolLooper())
|
|
|
|
conversation->GetProtocolLooper()->PostMessage(msg);
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
2010-05-16 16:02:50 -05:00
|
|
|
}
|
2021-05-30 19:07:50 -05:00
|
|
|
case IM_MESSAGE_SENT:
|
2010-05-07 04:47:10 -05:00
|
|
|
case IM_MESSAGE_RECEIVED:
|
2012-03-08 18:35:02 -06:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
Conversation* item = _EnsureConversation(msg);
|
|
|
|
item->ImMessage(msg);
|
2021-05-27 11:15:30 -05:00
|
|
|
|
2012-03-08 18:35:02 -06:00
|
|
|
break;
|
|
|
|
}
|
2021-06-08 15:32:04 -05:00
|
|
|
case IM_ROOM_INVITE_RECEIVED:
|
|
|
|
{
|
|
|
|
BString chat_id;
|
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
BString user_id = msg->FindString("user_id");
|
|
|
|
BString user_name = user_id;
|
|
|
|
BString chat_name = msg->FindString("chat_name");
|
|
|
|
BString body = msg->FindString("body");
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
|
|
|
if (msg->FindString("chat_id", &chat_id) != B_OK || looper == NULL)
|
2021-06-08 19:59:22 -05:00
|
|
|
{
|
2021-06-08 15:32:04 -05:00
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (chat_name.IsEmpty() == true)
|
|
|
|
chat_name = chat_id;
|
|
|
|
|
|
|
|
if (user != NULL)
|
|
|
|
user_name = user->GetName();
|
|
|
|
|
|
|
|
BString alertBody("You've been invited to %room%.");
|
|
|
|
if (user_id.IsEmpty() == false)
|
|
|
|
alertBody = "%user% has invited you to %room%.";
|
|
|
|
if (body.IsEmpty() == false)
|
|
|
|
alertBody << "\n\n\"%body%\"";
|
|
|
|
|
|
|
|
alertBody.ReplaceAll("%user%", user_name);
|
|
|
|
alertBody.ReplaceAll("%room%", chat_name);
|
|
|
|
alertBody.ReplaceAll("%body%", body);
|
|
|
|
|
2021-06-08 19:59:22 -05:00
|
|
|
BMessage* accept = new BMessage(IM_MESSAGE);
|
|
|
|
accept->AddInt32("im_what", IM_ROOM_INVITE_ACCEPT);
|
2021-06-08 15:32:04 -05:00
|
|
|
accept->AddString("chat_id", chat_id);
|
2021-06-08 19:59:22 -05:00
|
|
|
BMessage* reject = new BMessage(IM_MESSAGE);
|
|
|
|
accept->AddInt32("im_what", IM_ROOM_INVITE_REFUSE);
|
2021-06-08 15:32:04 -05:00
|
|
|
reject->AddString("chat_id", chat_id);
|
|
|
|
|
|
|
|
InviteDialogue* invite = new InviteDialogue(BMessenger(looper),
|
|
|
|
"Invitation received",
|
|
|
|
alertBody.String(), accept, reject);
|
|
|
|
invite->Go();
|
|
|
|
break;
|
|
|
|
}
|
2021-06-07 13:19:58 -05:00
|
|
|
case IM_USER_STARTED_TYPING:
|
|
|
|
case IM_USER_STOPPED_TYPING:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-06-08 15:32:04 -05:00
|
|
|
// User* user = _EnsureUser();
|
|
|
|
// Conversation* chat = _EnsureConversation();
|
2010-05-07 04:47:10 -05:00
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
break;
|
|
|
|
}
|
2010-05-30 07:17:32 -05:00
|
|
|
case IM_PROGRESS:
|
|
|
|
{
|
|
|
|
const char* protocol = NULL;
|
|
|
|
const char* title = NULL;
|
|
|
|
const char* message = NULL;
|
|
|
|
float progress = 0.0f;
|
|
|
|
|
|
|
|
if (msg->FindString("protocol", &protocol) != B_OK)
|
|
|
|
return result;
|
|
|
|
if (msg->FindString("title", &title) != B_OK)
|
|
|
|
return result;
|
|
|
|
if (msg->FindString("message", &message) != B_OK)
|
|
|
|
return result;
|
|
|
|
if (msg->FindFloat("progress", &progress) != B_OK)
|
|
|
|
return result;
|
2012-03-08 16:55:13 -06:00
|
|
|
|
|
|
|
if (!CayaPreferences::Item()->NotifyProtocolStatus)
|
|
|
|
break;
|
2010-05-30 07:17:32 -05:00
|
|
|
|
|
|
|
CayaProtocolAddOn* addOn
|
|
|
|
= ProtocolManager::Get()->ProtocolAddOn(protocol);
|
|
|
|
|
|
|
|
BNotification notification(B_PROGRESS_NOTIFICATION);
|
2010-07-03 02:55:23 -05:00
|
|
|
notification.SetGroup(BString("Caya"));
|
2010-05-30 07:17:32 -05:00
|
|
|
notification.SetTitle(title);
|
2021-05-22 12:05:44 -05:00
|
|
|
notification.SetIcon(addOn->ProtoIcon());
|
2010-05-30 07:17:32 -05:00
|
|
|
notification.SetContent(message);
|
|
|
|
notification.SetProgress(progress);
|
2010-07-03 02:55:23 -05:00
|
|
|
notification.Send();
|
2012-03-08 16:55:13 -06:00
|
|
|
|
2010-05-30 07:17:32 -05:00
|
|
|
break;
|
|
|
|
}
|
2010-05-30 13:56:24 -05:00
|
|
|
case IM_NOTIFICATION:
|
|
|
|
{
|
|
|
|
int32 type = (int32)B_INFORMATION_NOTIFICATION;
|
|
|
|
const char* protocol = NULL;
|
|
|
|
const char* title = NULL;
|
|
|
|
const char* message = NULL;
|
|
|
|
|
|
|
|
if (msg->FindString("protocol", &protocol) != B_OK)
|
|
|
|
return result;
|
|
|
|
if (msg->FindInt32("type", &type) != B_OK)
|
|
|
|
return result;
|
|
|
|
if (msg->FindString("title", &title) != B_OK)
|
|
|
|
return result;
|
|
|
|
if (msg->FindString("message", &message) != B_OK)
|
|
|
|
return result;
|
|
|
|
|
2012-03-08 16:55:13 -06:00
|
|
|
if (!CayaPreferences::Item()->NotifyProtocolStatus)
|
|
|
|
break;
|
|
|
|
|
2010-05-30 13:56:24 -05:00
|
|
|
CayaProtocolAddOn* addOn
|
|
|
|
= ProtocolManager::Get()->ProtocolAddOn(protocol);
|
|
|
|
|
|
|
|
BNotification notification((notification_type)type);
|
2010-07-03 02:55:23 -05:00
|
|
|
notification.SetGroup(BString("Caya"));
|
2010-05-30 13:56:24 -05:00
|
|
|
notification.SetTitle(title);
|
2021-05-22 12:05:44 -05:00
|
|
|
notification.SetIcon(addOn->ProtoIcon());
|
2010-05-30 13:56:24 -05:00
|
|
|
notification.SetContent(message);
|
2010-07-03 02:55:23 -05:00
|
|
|
notification.Send();
|
2012-03-08 16:55:13 -06:00
|
|
|
|
2010-05-30 13:56:24 -05:00
|
|
|
break;
|
|
|
|
}
|
2021-06-12 16:13:52 -05:00
|
|
|
case IM_PROTOCOL_READY:
|
|
|
|
{
|
2021-06-12 21:42:10 -05:00
|
|
|
// Ready notification
|
2021-06-12 16:13:52 -05:00
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
if (looper == NULL)
|
|
|
|
break;
|
2021-06-12 21:42:10 -05:00
|
|
|
CayaProtocol* proto = looper->Protocol();
|
2021-06-12 16:13:52 -05:00
|
|
|
|
|
|
|
BString content("%user% has connected!");
|
|
|
|
content.ReplaceAll("%user%", looper->Protocol()->GetName());
|
|
|
|
|
|
|
|
BNotification notification(B_INFORMATION_NOTIFICATION);
|
|
|
|
notification.SetGroup(BString("Caya"));
|
|
|
|
notification.SetTitle("Connected");
|
|
|
|
notification.SetContent(content);
|
2021-06-12 21:42:10 -05:00
|
|
|
notification.SetIcon(proto->Icon());
|
2021-06-12 16:13:52 -05:00
|
|
|
notification.Send();
|
2021-06-12 21:42:10 -05:00
|
|
|
|
|
|
|
// Join cached rooms
|
|
|
|
BEntry entry;
|
|
|
|
char fileName[B_FILE_NAME_LENGTH] = {'\0'};
|
|
|
|
BDirectory dir(CayaRoomsCachePath(proto->GetName()));
|
|
|
|
|
|
|
|
while (dir.GetNextEntry(&entry, true) == B_OK)
|
|
|
|
if (entry.GetName(fileName) == B_OK) {
|
2021-06-13 02:34:11 -05:00
|
|
|
int32 flags;
|
|
|
|
BFile file(&entry, B_READ_ONLY);
|
|
|
|
if (file.InitCheck() != B_OK)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (file.ReadAttr("Caya:flags", B_INT32_TYPE, 0, &flags,
|
|
|
|
sizeof(int32)) < 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!(flags & ROOM_AUTOJOIN) && !(flags & ROOM_AUTOCREATE))
|
|
|
|
continue;
|
|
|
|
|
2021-06-12 21:42:10 -05:00
|
|
|
BMessage join(IM_MESSAGE);
|
2021-06-13 02:34:11 -05:00
|
|
|
int32 im_what = IM_JOIN_ROOM;
|
|
|
|
if (flags & ROOM_AUTOCREATE) {
|
|
|
|
im_what = IM_CREATE_CHAT;
|
|
|
|
join.AddString("user_id", fileName);
|
|
|
|
}
|
|
|
|
join.AddInt32("im_what", im_what);
|
2021-06-12 21:42:10 -05:00
|
|
|
join.AddString("chat_id", fileName);
|
|
|
|
looper->PostMessage(&join);
|
|
|
|
}
|
2021-06-12 16:13:52 -05:00
|
|
|
break;
|
|
|
|
}
|
2011-12-14 17:36:27 -06:00
|
|
|
|
2010-05-07 04:47:10 -05:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-05-31 13:04:58 -05:00
|
|
|
void
|
|
|
|
Server::AddProtocolLooper(bigtime_t instanceId, CayaProtocol* cayap)
|
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ProtocolLooper* looper = new ProtocolLooper(cayap, instanceId);
|
2021-05-31 13:04:58 -05:00
|
|
|
fLoopers.AddItem(instanceId, looper);
|
2021-06-01 21:43:19 -05:00
|
|
|
fAccounts.AddItem(cayap->GetName(), instanceId);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
Server::RemoveProtocolLooper(bigtime_t instanceId)
|
|
|
|
{
|
2021-06-11 20:33:28 -05:00
|
|
|
ProtocolLooper* looper = GetProtocolLooper(instanceId);
|
|
|
|
if (looper == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ChatMap chats = looper->Conversations();
|
|
|
|
for (int i = 0; i < chats.CountItems(); i++)
|
|
|
|
delete chats.ValueAt(i);
|
|
|
|
|
|
|
|
UserMap users = looper->Users();
|
|
|
|
for (int i = 0; i < users.CountItems(); i++)
|
|
|
|
delete users.ValueAt(i);
|
|
|
|
|
|
|
|
fLoopers.RemoveItemFor(instanceId);
|
|
|
|
fAccounts.RemoveItemFor(looper->Protocol()->GetName());
|
|
|
|
looper->Lock();
|
|
|
|
looper->Quit();
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-01 21:43:19 -05:00
|
|
|
ProtocolLooper*
|
|
|
|
Server::GetProtocolLooper(bigtime_t instanceId)
|
|
|
|
{
|
|
|
|
bool found = false;
|
|
|
|
return fLoopers.ValueFor(instanceId, &found);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
AccountInstances
|
|
|
|
Server::GetAccounts()
|
|
|
|
{
|
|
|
|
return fAccounts;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-05-31 13:04:58 -05:00
|
|
|
void
|
|
|
|
Server::SendProtocolMessage(BMessage* msg)
|
|
|
|
{
|
|
|
|
// Skip null messages
|
|
|
|
if (!msg)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Check if message contains the instance field
|
|
|
|
bigtime_t id;
|
|
|
|
if (msg->FindInt64("instance", &id) == B_OK) {
|
|
|
|
bool found = false;
|
|
|
|
ProtocolLooper* looper
|
|
|
|
= fLoopers.ValueFor(id, &found);
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
looper->PostMessage(msg);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
Server::SendAllProtocolMessage(BMessage* msg)
|
|
|
|
{
|
|
|
|
// Skip null messages
|
|
|
|
if (!msg)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Send message to all protocols
|
|
|
|
for (uint32 i = 0; i < fLoopers.CountItems(); i++) {
|
|
|
|
ProtocolLooper* looper = fLoopers.ValueAt(i);
|
|
|
|
looper->PostMessage(msg);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
RosterMap
|
|
|
|
Server::Contacts() const
|
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
RosterMap contacts;
|
|
|
|
|
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
contacts.AddList(fruitLoop->Contacts());
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
return contacts;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-05-23 14:39:07 -05:00
|
|
|
Contact*
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
Server::ContactById(BString id, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
Contact* result = NULL;
|
|
|
|
if (looper != NULL)
|
|
|
|
result = looper->ContactById(id);
|
|
|
|
return result;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
Server::AddContact(Contact* contact, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
if (looper != NULL)
|
|
|
|
looper->AddContact(contact);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
UserMap
|
|
|
|
Server::Users() const
|
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
UserMap users;
|
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
users.AddList(fruitLoop->Users());
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
return users;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
User*
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
Server::UserById(BString id, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
User* result = NULL;
|
|
|
|
if (looper != NULL)
|
|
|
|
result = looper->UserById(id);
|
|
|
|
return result;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
Server::AddUser(User* user, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
if (looper != NULL)
|
|
|
|
looper->AddUser(user);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
ChatMap
|
|
|
|
Server::Conversations() const
|
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ChatMap chats;
|
2021-05-31 13:04:58 -05:00
|
|
|
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
chats.AddList(fruitLoop->Conversations());
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
return chats;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
Conversation*
|
|
|
|
Server::ConversationById(BString id, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
Conversation* result = NULL;
|
|
|
|
if (looper != NULL)
|
|
|
|
result = looper->ConversationById(id);
|
|
|
|
return result;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-04 16:32:18 -05:00
|
|
|
void
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
Server::AddConversation(Conversation* chat, int64 instance)
|
2021-06-04 16:32:18 -05:00
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
if (looper != NULL)
|
|
|
|
looper->AddConversation(chat);
|
2021-06-04 16:32:18 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-15 00:19:52 -05:00
|
|
|
CommandMap
|
|
|
|
Server::Commands()
|
|
|
|
{
|
2021-06-15 00:59:00 -05:00
|
|
|
CommandMap commands = fCommands;
|
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
commands.AddList(fruitLoop->Commands());
|
2021-06-15 00:59:00 -05:00
|
|
|
}
|
2021-06-15 00:19:52 -05:00
|
|
|
return fCommands;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
ChatCommand*
|
2021-06-15 00:59:00 -05:00
|
|
|
Server::CommandById(BString id, int64 instance)
|
2021-06-15 00:19:52 -05:00
|
|
|
{
|
2021-06-15 00:59:00 -05:00
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
ChatCommand* result = NULL;
|
|
|
|
if (looper != NULL)
|
|
|
|
result = looper->CommandById(id);
|
|
|
|
if (result == NULL)
|
|
|
|
result = fCommands.ValueFor(id);
|
|
|
|
return result;
|
2021-06-15 00:19:52 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
ProtocolLooper*
|
|
|
|
Server::_LooperFromMessage(BMessage* message)
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2010-05-16 16:02:50 -05:00
|
|
|
if (!message)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
bigtime_t identifier;
|
|
|
|
|
|
|
|
if (message->FindInt64("instance", &identifier) == B_OK) {
|
|
|
|
bool found = false;
|
|
|
|
|
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(identifier, &found);
|
|
|
|
if (found)
|
|
|
|
return looper;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-05-23 14:39:07 -05:00
|
|
|
Contact*
|
2021-05-31 11:56:45 -05:00
|
|
|
Server::_EnsureContact(BMessage* message)
|
2010-05-16 16:02:50 -05:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
BString id = message->FindString("user_id");
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ProtocolLooper* looper = _LooperFromMessage(message);
|
|
|
|
if (looper == NULL) return NULL;
|
2010-05-16 16:02:50 -05:00
|
|
|
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
Contact* contact = looper->ContactById(id);
|
|
|
|
|
|
|
|
if (contact == NULL && id.IsEmpty() == false && looper != NULL) {
|
2021-05-31 11:56:45 -05:00
|
|
|
contact = new Contact(id, Looper());
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
contact->SetProtocolLooper(looper);
|
|
|
|
looper->AddContact(contact);
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
return contact;
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
User*
|
|
|
|
Server::_EnsureUser(BMessage* message)
|
2021-05-24 01:47:21 -05:00
|
|
|
{
|
|
|
|
BString id = message->FindString("user_id");
|
2021-06-02 16:53:03 -05:00
|
|
|
return _EnsureUser(id, _LooperFromMessage(message));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
User*
|
|
|
|
Server::_EnsureUser(BString id, ProtocolLooper* protoLooper)
|
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
User* user = protoLooper->UserById(id);
|
2021-05-24 01:47:21 -05:00
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
if (user == NULL && id.IsEmpty() == false) {
|
|
|
|
user = new User(id, Looper());
|
2021-06-02 16:53:03 -05:00
|
|
|
user->SetProtocolLooper(protoLooper);
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
protoLooper->AddUser(user);
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
return user;
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
Conversation*
|
|
|
|
Server::_EnsureConversation(BMessage* message)
|
|
|
|
{
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
ProtocolLooper* looper;
|
|
|
|
if (!message || (looper = _LooperFromMessage(message)) == NULL)
|
2021-05-24 01:47:21 -05:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
BString chat_id = message->FindString("chat_id");
|
|
|
|
Conversation* item = NULL;
|
|
|
|
|
|
|
|
if (chat_id.IsEmpty() == false) {
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
item = looper->ConversationById(chat_id);
|
2010-05-07 04:47:10 -05:00
|
|
|
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
if (item == NULL) {
|
2021-05-24 01:47:21 -05:00
|
|
|
item = new Conversation(chat_id, Looper());
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
item->SetProtocolLooper(looper);
|
|
|
|
item->AddUser(looper->ContactById(looper->GetOwnId()));
|
|
|
|
looper->AddConversation(item);
|
2021-06-13 01:16:30 -05:00
|
|
|
|
|
|
|
BMessage meta(IM_MESSAGE);
|
|
|
|
meta.AddInt32("im_what", IM_GET_ROOM_METADATA);
|
|
|
|
meta.AddString("chat_id", chat_id);
|
|
|
|
|
|
|
|
BMessage users(IM_MESSAGE);
|
|
|
|
users.AddInt32("im_what", IM_GET_ROOM_PARTICIPANTS);
|
|
|
|
users.AddString("chat_id", chat_id);
|
|
|
|
|
|
|
|
looper->MessageReceived(&meta);
|
|
|
|
looper->MessageReceived(&users);
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return item;
|
|
|
|
}
|
2021-05-23 14:39:07 -05:00
|
|
|
|
|
|
|
|
Support for "Roles" (user, moderator, admin, etc.)
Add scaffodling support for arbitrary roles and permission-based (and
varying!) UI.
A new class, Role, represents a user's role in a given room, with three
values:
* The role's title
* The role's permission-set
* The role's priority
The permission set is a bitmask value for various permissions (e.g.,
PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy.
A user with higher priority (and PERM_BAN) can ban a user with lower
priority, but not vice-versa. Two users with the same priority can't
ban/kick/mute each other, etc.
These permissions should be used to determine what UI elements are
displayed― if the user doesn't have permission to ban users, then a
"Ban" button shouldn't exist. If the user is muted, they shouldn't be
able to type. So on and so forth.
For now, permissions are sent with a IM_ROLECHANGE message and stored
by the Conversation, but aren't really in use yet.
This system should be flexible groundwork to account for the varying
administrative hierarchies and norms of different protocols.
2021-06-06 00:41:45 -05:00
|
|
|
Role*
|
|
|
|
Server::_GetRole(BMessage* msg)
|
|
|
|
{
|
|
|
|
if (!msg)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
BString title;
|
2021-06-06 01:49:11 -05:00
|
|
|
int32 perms;
|
|
|
|
int32 priority;
|
Support for "Roles" (user, moderator, admin, etc.)
Add scaffodling support for arbitrary roles and permission-based (and
varying!) UI.
A new class, Role, represents a user's role in a given room, with three
values:
* The role's title
* The role's permission-set
* The role's priority
The permission set is a bitmask value for various permissions (e.g.,
PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy.
A user with higher priority (and PERM_BAN) can ban a user with lower
priority, but not vice-versa. Two users with the same priority can't
ban/kick/mute each other, etc.
These permissions should be used to determine what UI elements are
displayed― if the user doesn't have permission to ban users, then a
"Ban" button shouldn't exist. If the user is muted, they shouldn't be
able to type. So on and so forth.
For now, permissions are sent with a IM_ROLECHANGE message and stored
by the Conversation, but aren't really in use yet.
This system should be flexible groundwork to account for the varying
administrative hierarchies and norms of different protocols.
2021-06-06 00:41:45 -05:00
|
|
|
|
|
|
|
if (msg->FindString("role_title", &title) != B_OK
|
2021-06-06 01:49:11 -05:00
|
|
|
|| msg->FindInt32("role_perms", &perms) != B_OK
|
|
|
|
|| msg->FindInt32("role_priority", &priority) != B_OK)
|
Support for "Roles" (user, moderator, admin, etc.)
Add scaffodling support for arbitrary roles and permission-based (and
varying!) UI.
A new class, Role, represents a user's role in a given room, with three
values:
* The role's title
* The role's permission-set
* The role's priority
The permission set is a bitmask value for various permissions (e.g.,
PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy.
A user with higher priority (and PERM_BAN) can ban a user with lower
priority, but not vice-versa. Two users with the same priority can't
ban/kick/mute each other, etc.
These permissions should be used to determine what UI elements are
displayed― if the user doesn't have permission to ban users, then a
"Ban" button shouldn't exist. If the user is muted, they shouldn't be
able to type. So on and so forth.
For now, permissions are sent with a IM_ROLECHANGE message and stored
by the Conversation, but aren't really in use yet.
This system should be flexible groundwork to account for the varying
administrative hierarchies and norms of different protocols.
2021-06-06 00:41:45 -05:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return new Role(title, perms, priority);
|
|
|
|
}
|
|
|
|
|
2021-06-15 00:19:52 -05:00
|
|
|
void
|
|
|
|
Server::_InitDefaultCommands()
|
|
|
|
{
|
|
|
|
List<int32> roomUser;
|
|
|
|
roomUser.AddItem(CMD_ROOM_PARTICIPANT);
|
|
|
|
List<int32> kickBody;
|
|
|
|
kickBody.AddItem(CMD_ROOM_PARTICIPANT);
|
|
|
|
kickBody.AddItem(CMD_BODY_STRING);
|
|
|
|
List<int32> knownUser;
|
|
|
|
knownUser.AddItem(CMD_KNOWN_USER);
|
|
|
|
List<int32> anyUser;
|
|
|
|
anyUser.AddItem(CMD_ANY_USER);
|
|
|
|
|
|
|
|
BMessage kickMsg(IM_MESSAGE);
|
|
|
|
kickMsg.AddInt32("im_what", IM_ROOM_KICK_PARTICIPANT);
|
|
|
|
ChatCommand* kick = new ChatCommand("kick", kickMsg, true, kickBody);
|
|
|
|
kick->SetDesc("Force a user to temporarily leave the room, assuming your "
|
|
|
|
"power level's high enough.");
|
|
|
|
fCommands.AddItem("kick", kick);
|
|
|
|
|
|
|
|
BMessage banMsg(IM_MESSAGE);
|
|
|
|
banMsg.AddInt32("im_what", IM_ROOM_BAN_PARTICIPANT);
|
|
|
|
ChatCommand* ban = new ChatCommand("ban", banMsg, true, kickBody);
|
|
|
|
ban->SetDesc("Kick a user out of the room and slam the door behind them― "
|
|
|
|
"locking it while you're at it.");
|
|
|
|
fCommands.AddItem("ban", ban);
|
|
|
|
|
|
|
|
BMessage unbanMsg(IM_MESSAGE);
|
|
|
|
unbanMsg.AddInt32("im_what", IM_ROOM_UNBAN_PARTICIPANT);
|
|
|
|
ChatCommand* unban = new ChatCommand("unban", unbanMsg, true, anyUser);
|
|
|
|
unban->SetDesc("Undo a previous ban, allowing the user to rejoin (if they "
|
|
|
|
"still want to).");
|
|
|
|
fCommands.AddItem("unban", unban);
|
|
|
|
|
|
|
|
BMessage muteMsg(IM_MESSAGE);
|
|
|
|
muteMsg.AddInt32("im_what", IM_ROOM_MUTE_PARTICIPANT);
|
|
|
|
ChatCommand* mute = new ChatCommand("mute", muteMsg, true, roomUser);
|
|
|
|
mute->SetDesc("Disallow a user from sending visible messages.");
|
|
|
|
fCommands.AddItem("mute", mute);
|
|
|
|
|
|
|
|
BMessage unmuteMsg(IM_MESSAGE);
|
|
|
|
unmuteMsg.AddInt32("im_what", IM_ROOM_UNMUTE_PARTICIPANT);
|
|
|
|
ChatCommand* unmute = new ChatCommand("unmute", unmuteMsg, true, roomUser);
|
|
|
|
unmute->SetDesc("Restore a user's ability to send messages.");
|
|
|
|
fCommands.AddItem("unmute", unmute);
|
|
|
|
|
|
|
|
BMessage deafenMsg(IM_MESSAGE);
|
|
|
|
deafenMsg.AddInt32("im_what", IM_ROOM_DEAFEN_PARTICIPANT);
|
|
|
|
ChatCommand* deafen = new ChatCommand("deafen", deafenMsg, true, roomUser);
|
|
|
|
deafen->SetDesc("Disallow a user from reading messages sent in the room.");
|
|
|
|
fCommands.AddItem("deafen", deafen);
|
|
|
|
|
|
|
|
BMessage undeafenMsg(IM_MESSAGE);
|
|
|
|
undeafenMsg.AddInt32("im_what", IM_ROOM_UNDEAFEN_PARTICIPANT);
|
|
|
|
ChatCommand* undeafen = new ChatCommand("undeafen", undeafenMsg, true, roomUser);
|
|
|
|
undeafen->SetDesc("Restore a user's ability to receive messages.");
|
|
|
|
fCommands.AddItem("undeafen", undeafen);
|
|
|
|
|
|
|
|
BMessage inviteMsg(IM_MESSAGE);
|
|
|
|
inviteMsg.AddInt32("im_what", IM_ROOM_SEND_INVITE);
|
|
|
|
ChatCommand* invite = new ChatCommand("invite", inviteMsg, true, knownUser);
|
|
|
|
invite->SetDesc("Invite a user to the current room.");
|
|
|
|
fCommands.AddItem("invite", invite);
|
2021-06-15 00:45:51 -05:00
|
|
|
|
|
|
|
BMessage helpMsg(CAYA_REQUEST_HELP);
|
|
|
|
ChatCommand* help = new ChatCommand("help", helpMsg, false, List<int>());
|
|
|
|
help->SetDesc("List all current commands, or get help for certain command.");
|
|
|
|
fCommands.AddItem("help", help);
|
2021-06-15 00:19:52 -05:00
|
|
|
}
|
|
|
|
|
Support for "Roles" (user, moderator, admin, etc.)
Add scaffodling support for arbitrary roles and permission-based (and
varying!) UI.
A new class, Role, represents a user's role in a given room, with three
values:
* The role's title
* The role's permission-set
* The role's priority
The permission set is a bitmask value for various permissions (e.g.,
PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy.
A user with higher priority (and PERM_BAN) can ban a user with lower
priority, but not vice-versa. Two users with the same priority can't
ban/kick/mute each other, etc.
These permissions should be used to determine what UI elements are
displayed― if the user doesn't have permission to ban users, then a
"Ban" button shouldn't exist. If the user is muted, they shouldn't be
able to type. So on and so forth.
For now, permissions are sent with a IM_ROLECHANGE message and stored
by the Conversation, but aren't really in use yet.
This system should be flexible groundwork to account for the varying
administrative hierarchies and norms of different protocols.
2021-06-06 00:41:45 -05:00
|
|
|
|