Bug 435409 - Honor message permissions like edit or delete
Summary: Honor message permissions like edit or delete
Status: REPORTED
Alias: None
Product: Ruqola
Classification: Applications
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Laurent Montel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-06 07:38 UTC by Angel Docampo
Modified: 2021-04-16 13:03 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
context menu with a user who doesn't have edit/delete permissions (58.20 KB, image/png)
2021-04-14 12:51 UTC, Angel Docampo
Details
trying to delete wihtout permissions (14.27 KB, image/png)
2021-04-14 12:52 UTC, Angel Docampo
Details
editing without permissions (13.72 KB, image/png)
2021-04-14 12:54 UTC, Angel Docampo
Details
showing last chat window (78.07 KB, image/png)
2021-04-14 12:55 UTC, Angel Docampo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Angel Docampo 2021-04-06 07:38:02 UTC
SUMMARY
Ruqola seems not to honor permissions on chat messages for administrators, so as an admin, I cannot delete or edit other user's messages

STEPS TO REPRODUCE
1. Log in as an admin or other user with enough permissions to edit or delete messages from other users.
2. Right-click on a message of other user

OBSERVED RESULT
There is no option to edit or delete message

EXPECTED RESULT
I should be the options for delete and edit messages
Comment 1 Angel Docampo 2021-04-14 12:38:14 UTC
In ruqola 1.3.81 beta 2 seems to be improved. Now there are those options to everyone on the context menu, and if the user has permissions, can proceed with edit or deletion, and if the user hasn't the permissions, and error arises when trying to edit or delete a message.

I think it would be idea to hide the options from the context menu if the user has no permissions to carry on with them.
Comment 2 Laurent Montel 2021-04-14 12:44:51 UTC
(In reply to Angel Docampo from comment #1)
> In ruqola 1.3.81 beta 2 seems to be improved. Now there are those options to
> everyone on the context menu, and if the user has permissions, can proceed
> with edit or deletion, and if the user hasn't the permissions, and error
> arises when trying to edit or delete a message.
> 
> I think it would be idea to hide the options from the context menu if the
> user has no permissions to carry on with them.

it's the case. Here I don"t have this menu entry if I don"t have permission for it
Comment 3 Angel Docampo 2021-04-14 12:46:35 UTC
Just removed the test user which I created to make the test, let me create it again and show you.
Comment 4 Angel Docampo 2021-04-14 12:51:21 UTC
Created attachment 137594 [details]
context menu with a user who doesn't have edit/delete permissions
Comment 5 Angel Docampo 2021-04-14 12:52:30 UTC
Created attachment 137595 [details]
trying to delete wihtout permissions
Comment 6 Angel Docampo 2021-04-14 12:54:05 UTC
Created attachment 137596 [details]
editing without permissions
Comment 7 Angel Docampo 2021-04-14 12:55:48 UTC
Created attachment 137597 [details]
showing last chat window

In this image, I'm showing how the user test12 just when logs in, can see the content cached where the last user (angel.docampo) was looking at, in this case, the IT channel, where test12 has no access at all.

I'm wondering if context menu has some kind of cache as well, and that's why I'm seeing the options
Comment 8 Laurent Montel 2021-04-14 18:39:23 UTC
Could you show me permission from your user please ?
+
    if (hasPermission(QStringLiteral("force-delete-message"))) {
        return true;
    }
    if (hasPermission(QStringLiteral("delete-message"))) {
        return true;
    }

=> could you look at permission "force-delete-message" /"delete-message" permission for your user please ?
as I look at it.
not sure why your user has permission but not authorize to delete
Comment 9 Angel Docampo 2021-04-14 22:26:43 UTC
Create Public Channels
Create Direct Messages
Create Private Channels
Create Personal Access Tokens
delete-own-message
Leave Channels
Leave Private Groups
Mention All
Mention Here
Preview Public Channel
start-discussion
start-discussion-other-user
View Public Channel
View Direct Messages
View History
View Outside Room
View Private Room
Comment 10 Laurent Montel 2021-04-15 05:10:36 UTC
(In reply to Angel Docampo from comment #9)
> Create Public Channels
> Create Direct Messages
> Create Private Channels
> Create Personal Access Tokens
> delete-own-message
> Leave Channels
> Leave Private Groups
> Mention All
> Mention Here
> Preview Public Channel
> start-discussion
> start-discussion-other-user
> View Public Channel
> View Direct Messages
> View History
> View Outside Room
> View Private Room

bool RocketChatAccount::isMessageDeletable(const Message &message) const
{
    if (!allowMessageDeletingEnabled()) {
        return false;
    }
    if (hasPermission(QStringLiteral("force-delete-message"))) {
        return true;
    }
    if (hasPermission(QStringLiteral("delete-message"))) {
        return true;
    }
    if (message.userId() != userId()) {
        return false;
    }
    if (ruqolaServerConfig()->blockDeletingMessageInMinutes() == 0) { // TODO verify it
        return true;
    }
    return (message.timeStamp() + ruqolaServerConfig()->blockDeletingMessageInMinutes() * 60 * 1000) > QDateTime::currentMSecsSinceEpoch();
}

So your user doesn't have force-delete-message or delete-message permission, "message.userId() != userId()" can be different
=> it will return false

So I don't understand why it's true for you.
no idea how to debug it without access to server...
Or perhaps adding debug as qDebug() << " message.userId() " << message.userId() << " userId() " << userId();
Comment 11 Angel Docampo 2021-04-15 06:41:10 UTC
like this?
bool RocketChatAccount::isMessageDeletable(const Message &message) const
{
    if (!allowMessageDeletingEnabled()) {
        return false;
    }
    if (hasPermission(QStringLiteral("force-delete-message"))) {
        return true;
    }
    if (hasPermission(QStringLiteral("delete-message"))) {
        return true;
    }
    if (message.userId() != userId()) {
        return false;
    }
    if (ruqolaServerConfig()->blockDeletingMessageInMinutes() == 0) { // TODO verify it
        return true;
    }
    qDebug() << " message.userId() " << message.userId() << " userId() " << userId();
    return (message.timeStamp() + ruqolaServerConfig()->blockDeletingMessageInMinutes() * 60 * 1000) > QDateTime::currentMSecsSinceEpoch();
}
Comment 12 Laurent Montel 2021-04-15 07:17:17 UTC
yep
Comment 13 Angel Docampo 2021-04-15 13:37:15 UTC
ok, I've compiled with debug, open ruqola and... context menu showed *without* edit and delete options for the user without permissions...

I logged in back with my user (which is an administrator), and the options were there, so far so good.

I logged it back with the non-privileged user and the options this time were shown...
Closing ruqola and open it back, showed the context menu just fine, without the options.

I think you can reproduce the error by yourself, if not, tell me how to to send the debug, as in the output I can just see this:
org.kde.rocketchatqtrestapi: "RocketChatRestApi::UpdateMessageJob" error reply:  "Error transferring https://chat.eoniantec.com/api/v1/chat.update - server replied: Bad Request"
org.kde.rocketchatqtrestapi: errorType "error-action-not-allowed"
org.kde.rocketchatqtrestapi: RESTAPI:  "UpdateMessageJob: problem: {\n    \"details\": {\n        \"action\": \"Message_editing\",\n        \"method\": \"updateMessage\"\n    },\n    \"error\": \"Message editing not allowed [error-action-not-allowed]\",\n    \"errorType\": \"error-action-not-allowed\",\n    \"success\": false\n}\n"
Comment 14 Laurent Montel 2021-04-15 14:00:53 UTC
(In reply to Angel Docampo from comment #13)
> ok, I've compiled with debug, open ruqola and... context menu showed
> *without* edit and delete options for the user without permissions...
> 
> I logged in back with my user (which is an administrator), and the options
> were there, so far so good.
> 
> I logged it back with the non-privileged user and the options this time were
> shown...
> Closing ruqola and open it back, showed the context menu just fine, without
> the options.
> 
> I think you can reproduce the error by yourself, if not, tell me how to to
> send the debug, as in the output I can just see this:
> org.kde.rocketchatqtrestapi: "RocketChatRestApi::UpdateMessageJob" error
> reply:  "Error transferring https://chat.eoniantec.com/api/v1/chat.update -
> server replied: Bad Request"
> org.kde.rocketchatqtrestapi: errorType "error-action-not-allowed"
> org.kde.rocketchatqtrestapi: RESTAPI:  "UpdateMessageJob: problem: {\n   
> \"details\": {\n        \"action\": \"Message_editing\",\n       
> \"method\": \"updateMessage\"\n    },\n    \"error\": \"Message editing not
> allowed [error-action-not-allowed]\",\n    \"errorType\":
> \"error-action-not-allowed\",\n    \"success\": false\n}\n"


What is the debug for " qDebug() << " message.userId() " << message.userId() << " userId() " << userId();" ?

you need to put it just after
"    if (hasPermission(QStringLiteral("delete-message"))) {
        return true;
    }"

There is not caching so perhaps you change setting without restart ruqola and ruqola doesn't react on it but if you relaunch it it will get permission etc from server.
Comment 15 Angel Docampo 2021-04-16 12:52:38 UTC
Where should I see debug output? If I invoke ruqola from the command line, the output is the same with and w/o debug options
Comment 16 Angel Docampo 2021-04-16 13:03:57 UTC
>There is not caching so perhaps you change setting without restart ruqola and ruqola doesn't react on it but if you relaunch it it will get permission etc from server.

That's exactly what I'm doing. Closing the session but not closing ruqola. When I close and re-open ruqola, permissions and visibility are shown properly
More precisely, if I log in first with an unprivileged user and close the session, and re-open with an administrator user, permissions and visibility are shown properly: I can see and edit/delete posts
If I do the contrary, close the session with a privileged user and re-open with an unprivileged user, I can see **the last chat where the administrator was connected**, and I'm able to see the "Edit" and "Delete" menu option, yet they throw an error.

So the menu re-draws properly from non-privileged to privileged user but not vice-versa, and it happens the same with the conversation chat window: when I log off from an administrator account and log in with an unprivileged user, that unprivileged user sees the chat where the administrator was before the logout (although if he changes to another chat, he cannot see again the administrator chat conversation), but if with that unprivileged user I select a chat room where the administrator has no access and log off, and re-log on with the administrator account, it cannot see that chat.
So, it seems re-drawing of the interface works with the admin account at logon time, but with the unprivileged user works at launch time.