webadmin and userportal should both have a User Preferences dialog that allows the user to edit his/her preferences for the applications. This would need to be designed, but my favorite prefs dialog ever is the one in Eclipse. I particularly like the search feature. See attachment for screenshot. We could mimic that design. Some things off the top of my head that people would want to control via prefs: * default tab when opening the admin * automatically connect to vm when opening userportal? * comment columns -- show a bubble icon, or put the comment right in the grid? (see bug 1122990) We could also potentially control grid column selection and order via this dialog -- or those could be in their own "grid preferences" dialog.
session timeout would be another setting instead of engine-config -s UserSessionTimeOutInterval=30 input the number in a dialog.
Actually the Engine user session timeout is embedded into GWT host page on each reload (with value taken from "get config value" query) so UserSessionTimeOutInterval is Engine (server-side) config option.
Others: * Setting default views of things, e.g. New VM Advanced view or Simple (Bug 1431712) * Setting column width, visibility, and order (we have this now, but only via Local Storage) * Perhaps making things in dashboard(s) configurable
I can start to put together design options for a settings page in admin portal if you like.
Here are the latest wireframes for it: https://docs.google.com/document/d/1apA6E4zT21JSJgeO2V3Q_LhK9xq4SOwNeD-gIsG5pNY/edit?usp=sharing
too late for 4.4 RFEs
Current state: Last year the user options API was created based on users.option column [1] REST API was provided by extending the existing /users/ endpoint [2]. In parallel there is an older API based on user_profiles table (currently) storing only users SSH public key (previously also user_portal_vm_auto_login flag). The profiles are not exposed directly via REST but a specialized API is provided to access only SSH keys [3]. Feature using the user_profiles API: 1. setting SSH public key (both WebAdmin and VM Portal) Features using the users.options API 1. grid settings persistence in WebAmin [4] 2. account settings in Vm Portal [5] - in review, blocked by permission issue [6] There is an ongoing effort to migrate to one API based on user_profiles only [7]. The motivation for migrating from users.options API: 1. manipulating users table requires different sets of permissions (admin) then updating user settings(standard user). Storing user settings in the user table require complex permission rules. 2. user entity is treated across the system as immutable (or rarely mutable) and is cached i.e. in session. User settings can change frequently. 3. user_profile table is used for the same purpose but limited to a subset of the functionality. Planned actions: 1. (in review) extend the capabilities of user_profiles [7] 2. migrate existing data and Java API (persisting grid settings[4] does not use REST but GWT serialization). 3. expose user_profiles via REST to support VM Portal [5] (and solve [6]) Last point requires some design decisions to be made. The alternative designs that come to my mind: 1. (preferred choice) create a new sub-resource: /users/123/profiles/456 Profile properties could be then accessed using: /users/123/profiles/456/properties/789 Advantages: + clean + extensible + allows accessing/modifying individual properties + naturally exposes resource identifiers ((used by user_profiles for a variant of optimistic locking) 2. use similar approach as for SSH public keys - don't expose the profile but instead expose the properties directly i.e. /users/123/properties/789 Disadvantages (compared to #1): - assumes that we continue to support only one profile per user 3. keep the existing /users REST API but internally delegate to user_profiles Disadvantages (compared to #2): - non-standard way of including sub-resources - no resource identifiers (each update overwrites all existing data) - only bulk access/update (increases risk of conflicts between clients due to stale data) Design #1 and #2 naturally lead to reverting [2] as it's no longer needed and rather not widely used (yet) in production. If we would prefer to keep it due to (strict) backward compatibility then at least we should acknowledge that it's only for admin users and/or make it read only. [1] https://gerrit.ovirt.org/104027/ [2] https://gerrit.ovirt.org/103300 [3] http://ovirt.github.io/ovirt-engine-api-model/4.0/#services/ssh_public_keys [4] https://bugzilla.redhat.com/1752751 [5] https://github.com/oVirt/ovirt-web-ui/pull/1088 [6] https://gerrit.ovirt.org/111856/ [7] https://gerrit.ovirt.org/112145/
@mperina @oliel Please comment on comment 10. In particular: what approach for exposing user_profiles via REST you would prefer?
As for the REST-API implementation: If we will want to support more than a single profile per user, option (1) from Comment 10 seems the best. But this option presents difficulties with backwards-compatibility: how would we maintain user-options simultaniously at the user (for backwards-compatibility) and user-profile (new implementation) levels? The only way I could think of is to have a 'default' profile, and to have the user-level pertain to it, meaning: PUT .../api/users/xxx <user> <user_options>....</user_options> </user> would make changes to the 'default' profile of user xxx. Without maintaining backwards-compatibility things would obviously be simpler, but formally we are required to do it (except for when releasing major versions, and also then - with prior deprecation notice). However, if the existing implementation is never or almost never used by customers, then perhaps breaking backwards-compatibility is tolerable - this I think is for PM to decide. Needless to mention - breaking backwards-compatibility in the API for this feature would do the same in oVirt SDKs. Another point to mention for this implemnetation: we would need to provide a way for a user to set the active profile, something like POST .../api/users/xxx/userprofiles/yyy/setactive. This should be simple. One last point, regardless of the chosen API implementation, is about the subject of documentation. We would want to document well which options user may set, and what are their valid values. And this carries into subject of validation
Current state of the story: 1. the idea of user settings per vm was dropped 2. no search integration is needed (since vm-level settings were the main scenario for search) 3. we plan to support only a single user profile per user (simplifies implementation as pointed in comment 12) 4. we will use "type-safe" REST endpoints for JSON property type similar as we do today for SSH keys ( users/<id>/sshpublickeys). 5. JSON properties count/size should be limited (and configurable) 6. users.options REST API [1] will be first deprecated and only then in subsequent release removed. [1] http://ovirt.github.io/ovirt-engine-api-model/4.4/#services/user/methods/update
looks we're getting closer
With patches [1] and [2] we have now an unified framework for saving user profile properties based entirely on the user_profiles table. Done: 1. grid settings persistence in WebAmin - implemented under [3] and now migrated to user_profiles 2. new options in VM Portal -> Account Settings [4] [5] use the new /options endpoint TODO: 1. JSON properties count/size should be limited (and configurable) -> from comment 13 2. default tab when opening the admin -> from comment 0 3. automatically connect to vm when opening userportal? -> from comment 0 4. Setting default views of things, e.g. New VM Advanced view or Simple -> from comment 3 5. making things in dashboard(s) configurable -> from comment 3 6. missing items visible on the design -> from comment 6 Dropped: 1. comment columns -> from comment 0 2. session timeout -> due to comment 2 [1] https://gerrit.ovirt.org/c/ovirt-engine/+/112145 [2] https://gerrit.ovirt.org/c/ovirt-engine/+/113128 [3] https://bugzilla.redhat.com/1752751 [4] https://github.com/oVirt/ovirt-web-ui/pull/1372 [5] https://github.com/oVirt/ovirt-web-ui/pull/1373
closing as done. Only a generic framework is finished as per comment #15, other settings will follow later
(In reply to rszwajko from comment #15) > Done: > 2. new options in VM Portal -> Account Settings [4] [5] use the new > /options endpoint > > [4] https://github.com/oVirt/ovirt-web-ui/pull/1372 > [5] https://github.com/oVirt/ovirt-web-ui/pull/1373 We also supported [6] as part of VM portal [6] https://github.com/oVirt/ovirt-web-ui/pull/1088
So for verification was defined as a basic functionality of this RFE: 1. 1088 - setting SSH key and impersistent blocking toast notifications 2. 1372 - Change locale and display email via Account Settings 3. 1373 - Change refresh interval via Account Settings
Steps: Settings SSH key and saving in WebAdmin: ---------------------------------------- 1) Login as admin 2) Go to Options 3) Insert correct SSH key and click on 'Ok' 4) SSH key is saved Results: ISSUE: When the user inserts the correct SSH key, the Ok button is still disabled until the user clicks somewhere else in the dialog since he's still in the text field. In my opinion, the Ok button should be enabled on its own without the user clicking somewhere else. 1) Login as admin 2) Go to Options 3) Insert incorrect SSH key and click on 'Ok' 4) SSH key is not saved and an error dialog shows up Results: PASS: Operation canceled dialog is shown and the SSH key is not saved. Other issues: Users can hide the whole text field, maybe a minimum field size should be set. Setting the permanent grid settings in WebAdmin: ------------------------------------------------ 1) Login as admin 2) Go to Options 3) Set Persist grid settings on 4) Change some grid settings (for example in Virtual machines list change order of Host, FQDN and IP addresses and disable Host) 5) Logout, and login into another browser window 6) The changes should be permanent Result: PASS: Changes done in the grid settings are permanent. 1) Login as admin 2) Go to Options 3) Set Persist grid settings off 4) Change some grid settings (for example in Virtual machines list change order of Host, FQDN and IP addresses and disable Host) 5) Logout, and login into another browser window 6) The changes should not be permanent Result: ISSUE: Changes done in the grid settings are still permanent. Other issues: Persist grid settings have a weirdly formatted tooltip. Might be better if the list has a title. VMPortal User settings: ----------------------- 1) Add users as admin in AdminPortal 2) Check that every user has UserProfileEditor permission by default Result: PASS: Every user has UserProfileEditor permission by default. 1) Log in to VMPortal as one of non-admin users with UserRole 2) Go to Account Settings 3) Check the username and email 4) Check that email is read-only Result: PASS: Logged in user has correct username and email shown and email is read-only and cannot be changed. 1) Log in to VMPortal as one of non-admin users with UserRole 2) Go to Account Settings 3) Add correct SSH key to SSH key field and save Result: PASS: Correct SSH key is saved and a confirmation message is shown. 1) Log in to VMPortal as one of non-admin users with UserRole 2) Go to Account Settings 3) Add bad SSH key to SSH key field and save Result: PASS: Incorrect SSH key is not saved and an error message is shown. 1) Log in to VMPortal as one of non-admin users with UserRole 2) Go to Account Settings 3) Clear SSH key field and save Result: PASS: SSH key field is empty and no SSH keys are saved. 1) Log in to VMPortal as one of non-admin users with UserRole 2) Go to Account Settings 3) Change the language. Result: ISSUE: Even though the language is changed correctly and the translations are shown, in the process of changing the language several error messages appear and disappear. 1) Log in to VMPortal as one of non-admin users with UserRole 2) Go to Account Settings 3) Set the notifications to Do not disturb (for example for 10 minutes) Result: PASS: No notifications are shown, but they keep stacking in the notifications box in case the user wants to see them anyways. After the time limit is reached, notifications start showing up as usual. Please review the scenarios where I found some issues if they are blocking this bug or not. I will add some screenshots supporting the issues. Tested in: ovirt-web-ui-1.6.8-1.el8ev.noarch ovirt-engine-4.4.5.11-0.1.el8ev.noarch
Created attachment 1768417 [details] Missing list title tooltip
(In reply to Ivana Saranova from comment #21) > Steps: > > Settings SSH key and saving in WebAdmin: > ---------------------------------------- > 1) Login as admin > 2) Go to Options > 3) Insert correct SSH key and click on 'Ok' > 4) SSH key is saved > > Results: > ISSUE: When the user inserts the correct SSH key, the Ok button is still > disabled until the user clicks somewhere else in the dialog since he's still > in the text field. In my opinion, the Ok button should be enabled on its own > without the user clicking somewhere else. This should be fixed, best way is to always enable the OK button, regardless to user's input. > > 1) Login as admin > 2) Go to Options > 3) Insert incorrect SSH key and click on 'Ok' > 4) SSH key is not saved and an error dialog shows up > > Results: > PASS: Operation canceled dialog is shown and the SSH key is not saved. > > Other issues: > Users can hide the whole text field, maybe a minimum field size should be > set. This behavior is reproduced with previous "User's Public Key" field as well, as checked on version 4.4.1. So it's not a regression and not sure if worth fixing. > > > 1) Login as admin > 2) Go to Options > 3) Set Persist grid settings off > 4) Change some grid settings (for example in Virtual machines list change > order of Host, FQDN and IP addresses and disable Host) > 5) Logout, and login into another browser window > 6) The changes should not be permanent > > Result: > ISSUE: Changes done in the grid settings are still permanent. This should be fixed. > > Other issues: > Persist grid settings have a weirdly formatted tooltip. Might be better if > the list has a title. > This should be fixed. > > 1) Log in to VMPortal as one of non-admin users with UserRole > 2) Go to Account Settings > 3) Change the language. > > Result: > ISSUE: Even though the language is changed correctly and the translations > are shown, in the process of changing the language several error messages > appear and disappear. > This should be handled for 4.4.6 as part of locale enhancements issue: https://github.com/oVirt/ovirt-web-ui/pull/1396 Radek, please approve. > > Please review the scenarios where I found some issues if they are blocking > this bug or not. I will add some screenshots supporting the issues. > > Tested in: > ovirt-web-ui-1.6.8-1.el8ev.noarch > ovirt-engine-4.4.5.11-0.1.el8ev.noarch It seems to me that none of founded issues is a blocker for this bug ,even though they should still be fixed. Ivana, can you please open followup bugs with those issues or do you prefer that we'll open them? Thanks
(In reply to Sharon Gratch from comment #27) > (In reply to Ivana Saranova from comment #21) > > Steps: > > > > Settings SSH key and saving in WebAdmin: > > ---------------------------------------- > > 1) Login as admin > > 2) Go to Options > > 3) Insert correct SSH key and click on 'Ok' > > 4) SSH key is saved > > > > Results: > > ISSUE: When the user inserts the correct SSH key, the Ok button is still > > disabled until the user clicks somewhere else in the dialog since he's still > > in the text field. In my opinion, the Ok button should be enabled on its own > > without the user clicking somewhere else. > > This should be fixed, best way is to always enable the OK button, regardless > to user's input. > I would recommend improving change detection here - react to content changes and not to focus change. 'Ok' button enabled by default is IMHO bad choice as it encourages user to click it but the state is invalid (no change yet). > > > > 1) Login as admin > > 2) Go to Options > > 3) Insert incorrect SSH key and click on 'Ok' > > 4) SSH key is not saved and an error dialog shows up > > > > Results: > > PASS: Operation canceled dialog is shown and the SSH key is not saved. > > > > Other issues: > > Users can hide the whole text field, maybe a minimum field size should be > > set. > > This behavior is reproduced with previous "User's Public Key" field as well, > as checked on version 4.4.1. > So it's not a regression and not sure if worth fixing. I would fix it . The required effort should be rather small. > > > > > > > 1) Login as admin > > 2) Go to Options > > 3) Set Persist grid settings off > > 4) Change some grid settings (for example in Virtual machines list change > > order of Host, FQDN and IP addresses and disable Host) > > 5) Logout, and login into another browser window > > 6) The changes should not be permanent > > > > Result: > > ISSUE: Changes done in the grid settings are still permanent. > > This should be fixed. > We need more information here: was it the same browser profile? Was the local state cleared(cookies and local storage)? Changes to grid settings are always persisted - disabling the flag only means that they are persisted in the local storage only(not on the server). The UI works then "the old way" (as before this story): each browser profile has its own settings. When the flag is re-enabled the (current profile's) settings are exported to the server. In order to see the difference you need to open UI in private mode or use different/clean profile. > > > > Other issues: > > Persist grid settings have a weirdly formatted tooltip. Might be better if > > the list has a title. > > > > This should be fixed. > The tooltip adds more details to the main label (which is more general like the title). However if you think it's not enough we can try to improve it. What title would you suggest? > > > > 1) Log in to VMPortal as one of non-admin users with UserRole > > 2) Go to Account Settings > > 3) Change the language. > > > > Result: > > ISSUE: Even though the language is changed correctly and the translations > > are shown, in the process of changing the language several error messages > > appear and disappear. > > > > This should be handled for 4.4.6 as part of locale enhancements issue: > https://github.com/oVirt/ovirt-web-ui/pull/1396 > Radek, please approve. > In general changing a language alone should not trigger any errors. Error handling of complex scenarios will be definitely improved in [1]. There are good chances that the reported errors will be prevented too. However we need some more information here: what kind of errors were displayed? Does it happen each time? Does it happen with all the languages? Just for reference - an example complex scenario: 1. provide invalid SSH key 2. change language 3. submit changes Expected results (details in [2]): 1. SSH key update failed but language was changed successfully 2. error message appears via component specific notifications informing which settings was not saved 3. shortly after the notification a native browser window appears asking if user wants to leave the page and lose the data(invalid SSH key that was not saved). At this point user may read the error message and make his decision: a) cancel reload and continue editing i.e. correct SSH key and submit again OR b) confirm reload in which case the invalid key will be lost [1] https://github.com/oVirt/ovirt-web-ui/pull/1396 [2] https://github.com/oVirt/ovirt-web-ui/pull/1372#issuecomment-791576420
> > > 1) Login as admin > > > 2) Go to Options > > > 3) Set Persist grid settings off > > > 4) Change some grid settings (for example in Virtual machines list change > > > order of Host, FQDN and IP addresses and disable Host) > > > 5) Logout, and login into another browser window > > > 6) The changes should not be permanent > > > > > > Result: > > > ISSUE: Changes done in the grid settings are still permanent. > > > > This should be fixed. > > > We need more information here: was it the same browser profile? Was the > local state cleared(cookies and local storage)? > Changes to grid settings are always persisted - disabling the flag only > means that they are persisted in the local storage only(not on the server). > The UI works then "the old way" (as before this story): each browser profile > has its own settings. > When the flag is re-enabled the (current profile's) settings are exported to > the server. > In order to see the difference you need to open UI in private mode or use > different/clean profile. > You are right, I forgot to open the portal in another browser, so the changes seemed to be persistent. After opening it in another browser with a different profile, the changes seem to be not applied - not persistent. > > > > > > Other issues: > > > Persist grid settings have a weirdly formatted tooltip. Might be better if > > > the list has a title. > > > > > > > This should be fixed. > > > > The tooltip adds more details to the main label (which is more general like > the title). > However if you think it's not enough we can try to improve it. What title > would you suggest? > I would add a sentence like "These changes will be saved/persistent:" or something similar. > > > > > > 1) Log in to VMPortal as one of non-admin users with UserRole > > > 2) Go to Account Settings > > > 3) Change the language. > > > > > > Result: > > > ISSUE: Even though the language is changed correctly and the translations > > > are shown, in the process of changing the language several error messages > > > appear and disappear. > > > > > > > This should be handled for 4.4.6 as part of locale enhancements issue: > > https://github.com/oVirt/ovirt-web-ui/pull/1396 > > Radek, please approve. > > > > In general changing a language alone should not trigger any errors. Error > handling of complex scenarios will be definitely improved in [1]. > There are good chances that the reported errors will be prevented too. > However we need some more information here: what kind of errors were > displayed? Does it happen each time? Does it happen with all the languages? Yes, it happens for all the languages. I managed to screenshot the error in both console and VM Portal, although it's not always shown in console. I will be enclosing the screenshots. The error seems to be having a permissions problem with accessing time zones in user options. > Just for reference - an example complex scenario: > 1. provide invalid SSH key > 2. change language > 3. submit changes > > Expected results (details in [2]): > 1. SSH key update failed but language was changed successfully > 2. error message appears via component specific notifications informing > which settings was not saved > 3. shortly after the notification a native browser window appears asking if > user wants to leave the page and lose the data(invalid SSH key that was not > saved). > At this point user may read the error message and make his decision: > a) cancel reload and continue editing i.e. correct SSH key and submit > again OR > b) confirm reload in which case the invalid key will be lost > > Confirming the scenario works as expected. > [1] https://github.com/oVirt/ovirt-web-ui/pull/1396 > [2] https://github.com/oVirt/ovirt-web-ui/pull/1372#issuecomment-791576420
Created attachment 1769543 [details] vmportal_error
> It seems to me that none of founded issues is a blocker for this bug ,even > though they should still be fixed. > > Ivana, can you please open followup bugs with those issues or do you prefer > that we'll open them? > Thanks Sure, I will open the follow-up bugs for the issues that I have mentioned.
Okay, based on the conversation, I'm verifying this bug and opening separate bugs for the found issues. Verified in: ovirt-web-ui-1.6.8-1.el8ev.noarch ovirt-engine-4.4.5.11-0.1.el8ev.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: RHV Manager (ovirt-engine) 4.4.z [ovirt-4.4.5] 0-day security, bug fix, enhance), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:1186