ovirt-web-ui
ovirt-web-ui copied to clipboard
VM events: For a non-admin user, only display their own events
Followup #1592
For an admin user, display all events for a VM as would be done in webadmin.
For a non-admin user, only display events for a VM that the user is explicitly tagged in. These should only be actions performed on the VM by the user themselves.
Given these events on VM "SilerBlue":

For userA, VM Portal VM detail overview card shows:

And the VM events view shows:

All tests passed
if that's a client-side filtering then I don't think we should have taken it that seriously. Whatever API gives you access to should be "acceptable" to show in UI. though of course you do want to primarily see your own events and not everything.
:exclamation: Note :exclamation: - PR #1592 was reverted (#1604) and as such this PR is no longer valid / relevant.
@michalskrivanek @sgratch
Whatever API gives you access to should be "acceptable" to show in UI.
Yep. UI is here just a REST API client.
though of course you do want to primarily see your own events and not everything.
We can add a new filter for that and let the users decide. As a user I would be interested in all destructive actions triggered by other users i.e. shutdown, restart, etc.
All tests passed
@michalskrivanek @sjd78 @rszwajko
if that's a client-side filtering then I don't think we should have taken it that seriously. Whatever API gives you access to should be "acceptable" to show in UI. though of course you do want to primarily see your own events and not everything.
The only problem I can see with that approach is that the VM portal doesn't include all REST permitted actions and doesn't reflect all oVirt info so it is not that one replaced the other. Not all actions and info available via REST are available via the VM portal by a design. E.g. hosts are entities that the user can't manage/view via the vm portal and therefore should be transparent for him. So there is no good reason to show the user events like on which host their VM is running/stopped. There might be other events that are triggered by user actions but we don't want the user to see via the VM portal as well like quota etc. So need to check which such events can be triggered for both vms and pools and decide if to filter them out or not.
@sgratch
There might be other events that are triggered by user actions but we don't want the user to see via the VM portal as well like quota etc. So need to check which such events can be triggered for both vms and pools and decide if to filter them out or not.
IMHO this is not a blocker for https://github.com/oVirt/ovirt-web-ui/pull/1592 .
IMHO this is not a blocker for #1592 .
This new events viewer enhancement is not a question of a blocker or not, but IMHO if we add this new functionality then let's do it correctly and avoid releasing a version with info that we don't want to expose via the portal.
I only raised a concern here. We can still debate if to expose that info or not though. If not then let's filter that out.
Closing the PR since this change was based on #1592, and that change was reverted by #1604, this PR is no longer valid.