Bug 435409

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.

(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

Just removed the test user which I created to make the test, let me create it again and show you.

Created attachment 137594 [details]
context menu with a user who doesn't have edit/delete permissions

Created attachment 137595 [details]
trying to delete wihtout permissions

Created attachment 137596 [details]
editing without permissions

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

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

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

(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();

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();
}

yep

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"

(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.

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

>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.