[Freeipa-users] Troubles with extending FreeIPA Web UI to fit my environment

[Petr Vobornik]

On 09/05/2015 09:12 PM, Mateusz Małek wrote:
>
>
> W dniu 01.09.2015 o 13:27, Petr Vobornik pisze:
>> On 08/27/2015 05:17 AM, Mateusz Małek wrote:
>>> We're trying to adjust FreeIPA to our environment... quite a bit. Here
>>> are some bullet points:
>>>
>>> (...)
>>>
>>> For points 3, 5, 6 and to limit available choices in 2, we need to plug
>>> into Web UI. Samples at https://pvoborni.fedorapeople.org/plugins/
>>> provided us with some basic info how to write plugins.
>>
>> Glad to read that the plugin support is used. Especially in this scale.
>>
>> I'd like to ask you for a feedback. What are the main things that
>> would make extending IPA easier for you?
>

Thank you for the feedback.

> I think that some Web UI documentation is needed - some kind of index of
> available widgets (their names, parameters, some usage examples for more
> complex widgets like entity_select), dialog windows and facets (like
> search), examples for various things like how to add new batch actions
> (with a new button at the top of search view) or to make layout and
> contents of facets/dialog boxes dependent on which user is using Web UI
> (like self-service differs from admin view).

Yeah, this needs more love. Web UI has a documentation generated from 
comments but a lot of code is not commented/documented and examples are 
still missing.

https://pvoborni.fedorapeople.org/doc/#!/api

>
> UI seems extremely extensible and probably many "examples" of how to do
> different things are already there, but it takes some time to find which
> part of UI uses them and can be copied to custom module (or adjusted in
> some other way).
>
> Do you have some tips on how to setup programming environment for UI
> development?

only https://pvoborni.fedorapeople.org/doc/#!/guide/Debugging

>
>>> However, I face some issues when I register my module under different
>>> entity name instead of overriding user (I want to keep original user
>>> module available)
>>
>> Just curious, why do you want to keep the original user entity object?
>
> Maybe not necessarily to keep original entity object, but to manage the
> same object using two different UI plugins (keeping original module
> available was quick test of such scenario). We have sysadmins - who can
> modify all user details - and user administrator - who needs really
> simple interface for creating new accounts and prolonging validity of
> existing.

Maybe a plugin can switch the entity in registry according to user role 
after the role is known - as in this plugin:

https://pvoborni.fedorapeople.org/plugins/simpleuser/simpleuser.js

User data should be in `IPA.whoami`

>
>>
>>> It seems that check if (that.entity !== that.managed_entity) in
>>> freeipa/search.js fails (condition is true), which causes
>>> managed_entity_pkey_prefix function to return [""] instead of [] -
>>> object inspection shows both entity and managed_entity refer to user
>>> entity, but probably these are two different JS objects (and thats why
>>> they are considered different). Am I doing something wrong or is it some
>>> bug?
>>
>> There is no claim that it should  work so I would say that it is a
>> limitation of original design and unfinished refactoring than a bug.
>> The code can be improved to support multiple entity objects for the
>> same IPA object but I'm worried that it can break something else.
>>
>> Maybe simple comparison by an entity name would help.
>
> Oh, I see. I'll probably try to find other way around, as I'm a bit
> short on time. Extending FreeIPA is part of my engineering thesis, but
> at the same time I'm applying my changes to our CentOS-based production
> environment - that's why I'm trying to keep existing codebase intact
> (and it would take some time before any changes make their way to
> packages in RHEL repositories).

It can be patch in a plugin, but it's not nice.

Example: 
https://pvoborni.fedorapeople.org/plugins/association_search_fix/association_search_fix.js

>
> Thanks,
>
> Mateusz Małek

-- 
Petr Vobornik