[Freeipa-devel] Web UI refactoring effort ready for review

[Petr Vobornik]

Hi,

1, 2 and 3a are fixed and pushed to the private repo. Rest won't be 
fixed during the refactoring.

I changed SingletonRegistry behavior that it returns null when 
builder/construction spec is missing. It's more consistent with build of 
unsupported entities (also returns null).

On 04/26/2013 12:51 PM, Petr Vobornik wrote:
> On 04/25/2013 06:37 PM, Ana Krivokapic wrote:
>>
>> Hi,
>>
>> While reviewing and testing the new UI changes, I have encountered the
>> following issues. (Some of them may be unrelated to the webUI
>> refactoring effort, but I will list them here just so we are aware of
>> them.)
>
> Thanks for review, I will fix regressions today. We might open a ticket
> for the rest.
>
>>
>> 1) When in self service mode, you are now allowed to go to pages of
>> related objects. If you go to e.g. User Groups for your user, there are
>> Add/Delete buttons and they are enabled, but if you try to use them, you
>> will be denied access. However, a message will appear, saying 'Items
>> added' / 'Items removed' even though the operation had failed. Should we
>> disable these options in self service mode? I think we should at least
>> make sure that the misleading message which suggests that the actions
>> was completed, does not appear.
>
> Regression. Links should not be clickable and buttons should be hidden.
>
>>
>> 2) This one was already discussed with Petr in person: Runtime error on
>> invalid URL: https://ipahost/ipa/ui/#/e/doesnotexist will give an ugly
>> runtime error and any further navigation does not get rid of this error
>> - you have to reload the page. We should make sure that this is handled
>> more gracefully.
>>
>
> Kind of regression. I will fix it by redirecting to default facet (user
> search).
>
>> 3) Role Based Access Control, when trying to add a permission to a
>> privilege:
>> * Permissions which are already in that privilege appear in the list of
>> available permissions. They should not appear there (it doesn't make
>> sense to add something which is already there). (This behavior is
>> correct in other parts of UI, e.g. when you want add a privilege to a
>> role, the privileges which are already present for that role, do not
>> appear in the list of available privileges.)
>> * When you try to add such permission, first an Operations Error
>> appears, but when you click OK, a message saying 'Items added' appears
>> (similar issue is mentioned in 1) ).
>
> Not related to refactoring.
>
> a) permission-find doesn't have not-in-priviledge options so the
> not-offering of existing values is handled by association_adder_dialog
> dialog's `exclude` array. This array is filled with already added and
> then compared with the keys got from xx-find command. Problems is that
> memberships are lowercased and therefore the values have different
> casing -> don't match and therefore are still offered.  We might do some
> normalization in association_adder_dialog.
>
> I don't mind fixing it along with the refactoring.
>
> b) the success message might be a more wide-spread problem I noticed
> similar behavior in group's external member.
>
> Because of the wider scope please open a ticket.
>
>>
>> 4) Host Based Access Control:
>> When modifying a HBAC rule, workflow can be a bit confusing. For
>> example, if you have a rule with 'Anyone' selected in the 'WHO' section,
>> then you decide to change it to Specified Users and Groups, and then
>> click on Add to add users/groups, a dialog appears requiring you to save
>> your selection first (you have to click on Update, or click Cancel, then
>> Update the changes and then try to Add users again). Is it possible to
>> call the Update when Add is clicked, so that this step is automatically
>> performed, requiring no action from the user? I think it would feel more
>> intuitive to the user.
>
> I see one problem with the proposal. User might have changed also a
> description field or other category rule radio. I'm not sure if he wants
> to apply these changes automatically as well.
>
>>
>> 5) For sections that have Expand All/Collapse All link (for example,
>> when looking at a user's details page), I think that when you expand all
>> sections manually, the Expand All link should change to Collapse all.
>> And also the other way around: when you collapse all sections manually,
>> the Collapse All link should change to Expand All. This is probably
>> nitpicking too much, it is just a nice to have (does not make sense to
>> 'expand all' if everything is already expanded).
>>
>
> Open a ticket. I wonder how many users is using this feature.
> Personally, I don't.
>


-- 
Petr Vobornik