[ZBX-15792] Different and misleading messages when copying objects to destination with no write permissions Created: 2019 Mar 08  Updated: 2024 Apr 10

Status: Open
Project: ZABBIX BUGS AND ISSUES
Component/s: Frontend (F)
Affects Version/s: 4.2.0beta1, 4.2.0beta2
Fix Version/s: None

Type: Problem report Priority: Trivial
Reporter: Ivo Kurzemnieks Assignee: Zabbix Development Team
Resolution: Unresolved Votes: 0
Labels: inconsistency, permissions
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Team: Team B

 Description   

In a very rare case when superadmin suddenly changes regular admins rights and the admin was copying an object like item, trigger or graph in that time, user might get misleading and strange error and success messages depending on what object was copied, to what destination and how the permissions to that destination have changed. Even if nothing was copied and target permissions are "Deny", we can have a success message.

Let's say that we're copying items and during the copy process superadmin strips the user of his rights and changes the targets' permission from "Read-write" to "Deny" or "None". The message is saying that the item was successfully copied. Although it wasn't and nothing was done. However, when the target has "Read" permissions, there is a proper "no permissions" error message and the form is visible. Same thing happens with triggers. But with graphs there are more strange things. If we would select the destination "Host groups" and suddenly permissions change from "Read-write" to "Read", "Deny" or "None", it displays the "no permissions" error, but blocks the page afterwards. The form is not visible. In case the destination is "Hosts" and we have "Read" permissions at that moment, then it displays a success message.

These messages are misleading and highly inconsistent for all three objects - items, triggers and graphs and also inconsistent with the destination we chose "Host groups", "Hosts" or "Templates".


Generated at Fri Apr 11 18:28:10 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.