Open Guddetisandeep opened 5 months ago
Thanks @Guddetisandeep. I'm looking at this issue. Let me know if you discovered more information that could be helpful for recreating it. I'll let you know if I can find anything. Thanks!
Ok, it seems like the problem is that we don't display user's dashboards so you can't drill down to each user dashboard that contains the widget and remove it.
How would you expect this to work? Would you really want to manually visit possibly tens of user's dashboards to remove the widget from the dashboard or would you want to some other way to remove them in bulk?
I'm stuck on how this should work. We don't display all of the user dashboards so you can't see any of them that may have the widget you want to remove.
FYI, this is how the widget sets (dashboard) looks in the backend:
PostgreSQLAdapter#log_after_checkout, connection_pool: size: 15, connections: 1, in use: 1, waiting_in_queue: 0
MiqWidget Load (0.8ms) SELECT "miq_widgets".* FROM "miq_widgets" WHERE "miq_widgets"."id" = $1 LIMIT $2 [["id", 119], ["LIMIT", 1]]
MiqWidget Inst Including Associations (10.2ms - 1rows)
MiqWidgetSet Load (6.9ms) SELECT "miq_sets".* FROM "miq_sets" INNER JOIN "miq_set_memberships" ON "miq_sets"."id" = "miq_set_memberships"."miq_set_id" WHERE "miq_sets"."set_type" = $1 AND "miq_set_memberships"."member_id" = $2 AND "miq_set_memberships"."member_type" = $3 [["set_type", "MiqWidgetSet"], ["member_id", 119], ["member_type", "MiqWidget"]]
MiqWidgetSet Inst Including Associations (4.0ms - 2rows)
=>
[#<MiqWidgetSet:0x000000010e29f298
id: 181,
name: "test",
description: "test",
set_type: "MiqWidgetSet",
created_on: Wed, 03 Apr 2024 15:43:31.411489000 UTC +00:00,
updated_on: Wed, 03 Apr 2024 15:43:31.406018000 UTC +00:00,
guid: "0e9a7a08-e711-4c9b-ae69-485aef4e5bda",
read_only: nil,
set_data: "[FILTERED]",
mode: nil,
owner_type: "MiqGroup",
owner_id: 57,
userid: nil,
group_id: 57>,
#<MiqWidgetSet:0x000000010e3b7b58
id: 182,
name: "test",
description: "test dashboard for user joe in group id 57",
set_type: "MiqWidgetSet",
created_on: Wed, 03 Apr 2024 15:47:15.493941000 UTC +00:00,
updated_on: Wed, 03 Apr 2024 15:47:15.493941000 UTC +00:00,
guid: "d65011a7-76b1-4ade-811f-ebe11d541c40",
read_only: nil,
set_data: "[FILTERED]",
mode: nil,
owner_type: nil,
owner_id: nil,
userid: "joe",
group_id: 57>]
We don't display all of the user dashboards so you can't see any of them that may have the
When a group dashboard is created under a specific MiqGroup, and a user visits the dashboard for the first time, a user-specific dashboard is created that duplicates the main group dashboard. If there are ten users visiting dashboard it creates ten user-specific dashboards duplicating the main group dashboard. The widgets are set to refresh every hour, so whenever any widget stops refreshing, we replace that widget with a new one. However, when I try to delete the old widget by removing it from the main group dashboard, it results in an error indicating that this widget is present in user-specific dashboards.
I believe that if a group is created, all users of that particular group should be able to access that dashboard. Therefore, duplicating the group dashboard for each user might not be necessary. Changes made to the group dashboard should be reflected across all user dashboards within that group. If there are tens or hundreds of users, manually removing the widget from each user's dashboard is a time-consuming process. So, I think if the process of duplicating the group dashboard to create user-specific dashboards is stopped, we would be able to delete widgets without encountering errors.
Thanks @Guddetisandeep. I'm looking at this issue. Let me know if you discovered more information that could be helpful for recreating it. I'll let you know if I can find anything. Thanks!
Steps to reproduce:
1) Create a dashboard under a particular MiqGroup that includes users, and add the two or three widgets to the dashboard.
2) When users visit the created dashboard, it creates user-specific dashboard in database.(We check through miq_sets
table).
3) Try to remove the widget from the created dashboard and then try to delete the widget. An error will be displayed on the UI indicating the names of the dashboards where the widget is still present.
4) To further investigate the error, we run the following query:
SELECT id,name,description FROM miq_sets WHERE set_type = 'MiqWidgetSet' AND set_data LIKE '%<widget-id>%';
So, it looks like the solution could be any one of the following 1) show user dashboards associated with specific widgets. We currently only show group dashboards so we'd need to show users and have a way to navigate from the widget we'd like to remove to the user dashboards that use it. The problem is you could have tens or hundreds of users, so there would be many dashboards and showing all of them wouldn't be useful unless you only show the dashboards that are associated with the widget you want to remove.
2) provide a way to say "I'm sure" and allow the widget to be deleted even if the dashboard is orphaned
3) provide a way to delete widgets and clean up any dashboards so they are no longer pointing to an orphaned widget.
So, it looks like the solution could be any one of the following
- show user dashboards associated with specific widgets. We currently only show group dashboards so we'd need to show users and have a way to navigate from the widget we'd like to remove to the user dashboards that use it. The problem is you could have tens or hundreds of users, so there would be many dashboards and showing all of them wouldn't be useful unless you only show the dashboards that are associated with the widget you want to remove.
- provide a way to say "I'm sure" and allow the widget to be deleted even if the dashboard is orphaned
- provide a way to delete widgets and clean up any dashboards so they are no longer pointing to an orphaned widget.
I think option 3 would be beneficial. This way, if we remove a widget from the main dashboard and try to delete it, it should be deleted and any user dashboards referencing it should be cleaned up to no longer point to the orphaned widget.
So, it looks like the solution could be any one of the following
- show user dashboards associated with specific widgets. We currently only show group dashboards so we'd need to show users and have a way to navigate from the widget we'd like to remove to the user dashboards that use it. The problem is you could have tens or hundreds of users, so there would be many dashboards and showing all of them wouldn't be useful unless you only show the dashboards that are associated with the widget you want to remove.
- provide a way to say "I'm sure" and allow the widget to be deleted even if the dashboard is orphaned
- provide a way to delete widgets and clean up any dashboards so they are no longer pointing to an orphaned widget.
I think option 3 would be beneficial. This way, if we remove a widget from the main dashboard and try to delete it, it should be deleted and any user dashboards referencing it should be cleaned up to no longer point to the orphaned widget.
I agree. The concern is we have to make sure if you have permission to delete widgets, which most roles do, that you can't delete widgets used by dashboards of other users, as the new behavior would mean you are modifying other user's dashboards. For example, if I'm a basic user, I shouldn't be able to delete widgets used in dashboards for administrators or other higher privilege users. It might be something only a super administrator can do. I'll have to think about it.
So, it looks like the solution could be any one of the following
- show user dashboards associated with specific widgets. We currently only show group dashboards so we'd need to show users and have a way to navigate from the widget we'd like to remove to the user dashboards that use it. The problem is you could have tens or hundreds of users, so there would be many dashboards and showing all of them wouldn't be useful unless you only show the dashboards that are associated with the widget you want to remove.
- provide a way to say "I'm sure" and allow the widget to be deleted even if the dashboard is orphaned
- provide a way to delete widgets and clean up any dashboards so they are no longer pointing to an orphaned widget.
I think option 3 would be beneficial. This way, if we remove a widget from the main dashboard and try to delete it, it should be deleted and any user dashboards referencing it should be cleaned up to no longer point to the orphaned widget.
I agree. The concern is we have to make sure if you have permission to delete widgets, which most roles do, that you can't delete widgets used by dashboards of other users, as the new behavior would mean you are modifying other user's dashboards. For example, if I'm a basic user, I shouldn't be able to delete widgets used in dashboards for administrators or other higher privilege users. It might be something only a super administrator can do. I'll have to think about it.
Yes, the ability to delete widgets should be restricted to super administrators. I think it would be beneficial to include an option that allows the deletion privilege to be enabled or disabled when copying this role to create other roles.
This issue has been automatically marked as stale because it has not been updated for at least 3 months.
If you can still reproduce this issue on the current release or on master
, please reply with all of the information you have about it in order to keep the issue open.
When I create a group dashboard and add widgets, and when users from that group access the dashboard, it automatically creates a user-specific dashboard by duplicating the group dashboard for each user in the database. When widgets are removed from the group dashboard and when I try to delete the widget an error occurs stating that the widget is present in user-specific dashboards and cannot be deleted. However, when the specific user checks their dashboard, the widget is not present.
ManageIQ-Verison: 4.2.0
Error:![Screenshot 2024-03-15 165453](https://github.com/ManageIQ/manageiq-ui-classic/assets/123159143/94898540-fc5d-47a7-a890-8bf902755de3)
We are running this query to view the complete error: