Does anyone else have the problem that the trash icon is missing in the list view for normal users?

[luckow]

For a few days now, I have been missing the trash icon in list views (as a normal user). As soon as I switch to a user with admin rights, the trash icon is there again. I have looked in the permission settings for users and mailboxes, but have not found an option to restore the trash icon (the “bulk delete” option) for normal users.

Trash icon is only displayed for the admin role.

I reported this upstream.
https://github.com/freescout-help-desk/freescout/issues/4819

[luckow]

Ok, I checked the behavior again. My results:
The freescout demo server is working as expected. As soon as a user has the right to delete messages, the trash icon is displayed in the list view.

a fresh install of Freescout on Cloudron (without any module), shows exactly my experience.

https://freescout-missing-trashicon.demo.cloudron.io/login
admin: admin@cloudron.local:changeme123
user: agent@example.org:changeme123

[james]

Hello @luckow

Just to double-check, did you make sure this is no caching issue?
Do you see any errors in the Browser Web Console or in the Cloudron app log?

[luckow]

@james No errors in the browser console. Different users & browsers - so no caching issue.

[james]

Hello @luckow

Thanks for confirming that.

@luckow said in Does anyone else have the problem that the trash icon is missing in the list view for normal users?:

a fresh install of Freescout on Cloudron (without any module), shows exactly my experience.

I will try to reproduce your issue now.

[james]

From a fresh install, added a mailbox, send some test mails.
Now added a new user.
Without changing anything, the new user has no permission to delete a ticket.

Now giving the new user the Permissions checkbox in the Mailbox configuration and pressing save.
In the user view in a private window, reloading the tab reveals no change at all. User still can't delete anything.
Logout and Login did also not change anything.
Something is wrong here!

When inspecting the browser console reveals only warnings.
Checking out the Network inspection reveals something interesting.
When pressing save the following POST request is made but returns HTTP Status Code 302:

https://$DOMAIN/mailbox/permissions/1

with payload

_token=REDACTED_TOKEN&users%5B%5D=2&managers%5B2%5D%5Baccess%5D%5Bperm%5D=perm

The UI refreshed and showed - Mailbox permissions aved! notification:

MySQL reveals that the permission was set:

mysql> SELECT id,first_name,last_name,permissions FROM users;
+----+------------+-----------+-------------+
| id | first_name | last_name | permissions |
+----+------------+-----------+-------------+
|  1 | Cloudron   | Admin     | NULL        |
|  2 | Tina       | Testing   | NULL        |
+----+------------+-----------+-------------+
2 rows in set (0.00 sec)

mysql> SELECT id,user_id,mailbox_id,access FROM mailbox_user;
+----+---------+------------+----------+
| id | user_id | mailbox_id | access   |
+----+---------+------------+----------+
|  2 |       2 |          1 | ["perm"] |
|  9 |       1 |          1 | []       |
+----+---------+------------+----------+
2 rows in set (0.00 sec)

Permissions are getting set. But still the user can't delete any ticket. I would have assumed that setting would have been it.
Setting no permissions for the user again and saving.

---

In the user setting I found that each user can have permissions.
There I also found the Users are allowed to delete conversations.
Setting the checkbox and saving.
Again HTTP Status Code 302.
MySQL shows permissions where saves:

mysql> SELECT id,user_id,mailbox_id,access FROM mailbox_user;
+----+---------+------------+--------+
| id | user_id | mailbox_id | access |
+----+---------+------------+--------+
|  2 |       2 |          1 | []     |
| 13 |       1 |          1 | []     |
+----+---------+------------+--------+
2 rows in set (0.00 sec)

mysql> SELECT id,first_name,last_name,permissions FROM users;
+----+------------+-----------+-------------+
| id | first_name | last_name | permissions |
+----+------------+-----------+-------------+
|  1 | Cloudron   | Admin     | NULL        |
|  2 | Tina       | Testing   | {"1":1}     |
+----+------------+-----------+-------------+
2 rows in set (0.00 sec)

Just with these permissions, the user is now allowed to delete tickets in the inbox, but only when viewing the ticket directly.
A multi select and delete is not possible.
After giving the user all permissions as a user and in the inbox, still no success.

Trying to set the new user as an Administrator, since the default admin can multi select delete.
When pressing save: Whoops, looks like something went wrong — check logs in /storage/logs

Logs:

strip_tags(): Passing null to parameter #1 ($string) of type string is deprecated {"userId":1,"email":"admin@cloudron.local","exception":"[object] (ErrorException(code: 0): strip_tags(): Passing null to parameter #1 ($string) of type string is deprecated at /app/code/app/User.php:1013)

When saving anything in the user profile as the default administrator this error is thrown.

Now as the new user, trying to add an Alternate Emails pressing save and getting the following critical notice:

When reviewing the POST request made there is only emails as a field send:

The Email input field has the html id tag email The Alternate Emails has the html id tag emails.
The html id tag email is missing the the POST request.
The input field Emails can not be edited.
Might not be related to the given issue, still is an issue.
Issue is known upstream => https://github.com/freescout-help-desk/freescout/issues/4812

Forcing the role administrator via MySQL UPDATE users SET role=2 WHERE id=2;
With this permission level single and multi select delete is possible again.
This is no solution tho.

I found no possible way to enable single or multi selected delete either then giving a user the administration role.

[james]

Oh! @BrutalBirdie just found the issue https://github.com/freescout-help-desk/freescout/issues/4819#issuecomment-2927528981

Since something was changed in 1.8.181 regarding Take into account APP_SHOW_ONLY_ASSIGNED_CONVERSATIONS option when deleting conversation
8484785

When applying this commit in reverse:

wget -O this.patch https://github.com/freescout-help-desk/freescout/commit/8484785a17fa1cd58d46016b45f6822a6adc9b64.diff
git apply --reverse this.patch

the issue resolves.
Since I am not that deep into the freescout code, I can't create a PR right now to fix this.
But my method of undoing that commit with a reverse apply proves that there is a regression.