Re: [Freeipa-users] Troubles with extending FreeIPA Web UI to fit my environment
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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubles with extending FreeIPA Web UI to fit my environment
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? 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). 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? 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. 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). Thanks, Mateusz Małek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubles with extending FreeIPA Web UI to fit my environment
On 08/27/2015 05:17 AM, Mateusz Małek wrote:
Hi everyone,
We're trying to adjust FreeIPA to our environment... quite a bit. Here
are some bullet points:
1. User home directory location is dependent on user primary group and
its value should be autogenerated on user creation.
2. User administrator should be able to select user account type (its
primary group) in some user-friendly way from pre-determined list of
possible choices - without the need to remember GID number associated
with each account type.
3. Passwords need to be generated automatically, so user administrator
won't be required to invent them for every single user. It should appear
on-screen after user account creation.
4. If username was not provided, it should also be generated using some
pre-determined method. It also should be shown after creating new user.
5. Some user accounts have an expiration date and need to be renewed
every year. User administrator should be able to extend user account
validity with single mouse-click in Web UI (with additional click for
confirmation prompt, probably).
6. Many user account attributes are not in use in our environment - they
should be hidden in Web UI to avoid confusion (for example job title in
search view).
And probably the most important thing: *all these things have to been
done without modifying files installed from RPM package* - we are using
ipa-server from CentOS 7 repositories and we don't want things to break
on update.
Point 1 was easy one - we used additional script in ipalib/plugins and
user_add.register_pre_callback to hook into user account creation
process. We also use this hook to assign gidNumber based on "User class"
specified in account creation form in Web UI (point 2).
Unfortunately, I have trouble with point 4 - uid attribute is specified
in takes_params with default_from=lambda givenname, sn: givenname[0] +
sn and when hook gets called, entry is already filled with this default
value. How can I override this behavior? Is it at least possible to
distinguish (in hook code) between value generated using default_from
and value manually typed into account creation form? (It seems that
default value is also checked for duplicates before calling hook - this
still needs to be overriden, as it will prevent our usernames generator
from even getting called.)
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?
I've copied
pre-minified freeipa/user.js file and turned it into a plugin.
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?
- reg.entity.register({type: 'new-user', spec:
exp.entity_spec}); - I get "IPA Error 3004: MaxArgumentError: command
'user_find' takes at most 1 argument".
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.
Best regards
Mateusz Małek
Intelligent Information Systems Group
Department of Computer Science
AGH University of Science and Technology, Kraków, Poland
--
Petr Vobornik
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubles with extending FreeIPA Web UI to fit my environment
W dniu 27.08.2015 o 15:18, Rob Crittenden pisze: Mateusz Małek wrote: We're trying to adjust FreeIPA to our environment... quite a bit. Here are some bullet points: (...) 3. Passwords need to be generated automatically, so user administrator won't be required to invent them for every single user. It should appear on-screen after user account creation. The ability is there on the CLI (don't know if it is exposed in UI): $ ipa user-add --first=random --last=user ruser --random -- Added user ruser -- User login: ruser First name: random ... Random password: Gu8VpULbb9xv ... Yeah, I've already found it ;) It isn't exposed in Web UI, but it wasn't extremely difficult to change these bits of code to send random: true with user_add request and then display dialog box with randompassword value sent in response (code is a bit ugly at the moment, as this is fair bit of copy-paste programming - but it works). I think the most problematic part of my struggles with adjusting IPA to my environment is point 4 of my list - it is easy to remove that single line responsible for creating default value of username, but I really want to avoid troubles with upgrades and that's why I'm trying to patch this in some pluggable, update-friendly way. Is there any interface to access definition of particular field from ipalib plugin code? At the moment I'm monkey-patching user object like that: from ipalib.plugins import user def patch(params): for param in params: if param.name == 'uid': yield param.clone(default_from=None) else: yield param user.user.takes_params = tuple(patch(user.user.takes_params)) It works, but is there any better (or more appropriate) way to replace one specific parameter definition? Best regards Mateusz Małek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubles with extending FreeIPA Web UI to fit my environment
Mateusz Małek wrote:
Hi everyone,
We're trying to adjust FreeIPA to our environment... quite a bit. Here
are some bullet points:
1. User home directory location is dependent on user primary group and
its value should be autogenerated on user creation.
2. User administrator should be able to select user account type (its
primary group) in some user-friendly way from pre-determined list of
possible choices - without the need to remember GID number associated
with each account type.
3. Passwords need to be generated automatically, so user administrator
won't be required to invent them for every single user. It should appear
on-screen after user account creation.
The ability is there on the CLI (don't know if it is exposed in UI):
$ ipa user-add --first=random --last=user ruser --random
--
Added user ruser
--
User login: ruser
First name: random
...
Random password: Gu8VpULbb9xv
...
rob
4. If username was not provided, it should also be generated using some
pre-determined method. It also should be shown after creating new user.
5. Some user accounts have an expiration date and need to be renewed
every year. User administrator should be able to extend user account
validity with single mouse-click in Web UI (with additional click for
confirmation prompt, probably).
6. Many user account attributes are not in use in our environment - they
should be hidden in Web UI to avoid confusion (for example job title in
search view).
And probably the most important thing: *all these things have to been
done without modifying files installed from RPM package* - we are using
ipa-server from CentOS 7 repositories and we don't want things to break
on update.
Point 1 was easy one - we used additional script in ipalib/plugins and
user_add.register_pre_callback to hook into user account creation
process. We also use this hook to assign gidNumber based on User class
specified in account creation form in Web UI (point 2).
Unfortunately, I have trouble with point 4 - uid attribute is specified
in takes_params with default_from=lambda givenname, sn: givenname[0] +
sn and when hook gets called, entry is already filled with this default
value. How can I override this behavior? Is it at least possible to
distinguish (in hook code) between value generated using default_from
and value manually typed into account creation form? (It seems that
default value is also checked for duplicates before calling hook - this
still needs to be overriden, as it will prevent our usernames generator
from even getting called.)
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. I've copied
pre-minified freeipa/user.js file and turned it into a plugin.
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) - reg.entity.register({type: 'new-user', spec:
exp.entity_spec}); - I get IPA Error 3004: MaxArgumentError: command
'user_find' takes at most 1 argument.
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?
Best regards
Mateusz Małek
Intelligent Information Systems Group
Department of Computer Science
AGH University of Science and Technology, Kraków, Poland
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] Troubles with extending FreeIPA Web UI to fit my environment
Hi everyone,
We're trying to adjust FreeIPA to our environment... quite a bit. Here
are some bullet points:
1. User home directory location is dependent on user primary group and
its value should be autogenerated on user creation.
2. User administrator should be able to select user account type (its
primary group) in some user-friendly way from pre-determined list of
possible choices - without the need to remember GID number associated
with each account type.
3. Passwords need to be generated automatically, so user administrator
won't be required to invent them for every single user. It should appear
on-screen after user account creation.
4. If username was not provided, it should also be generated using some
pre-determined method. It also should be shown after creating new user.
5. Some user accounts have an expiration date and need to be renewed
every year. User administrator should be able to extend user account
validity with single mouse-click in Web UI (with additional click for
confirmation prompt, probably).
6. Many user account attributes are not in use in our environment - they
should be hidden in Web UI to avoid confusion (for example job title in
search view).
And probably the most important thing: *all these things have to been
done without modifying files installed from RPM package* - we are using
ipa-server from CentOS 7 repositories and we don't want things to break
on update.
Point 1 was easy one - we used additional script in ipalib/plugins and
user_add.register_pre_callback to hook into user account creation
process. We also use this hook to assign gidNumber based on User class
specified in account creation form in Web UI (point 2).
Unfortunately, I have trouble with point 4 - uid attribute is specified
in takes_params with default_from=lambda givenname, sn: givenname[0] +
sn and when hook gets called, entry is already filled with this default
value. How can I override this behavior? Is it at least possible to
distinguish (in hook code) between value generated using default_from
and value manually typed into account creation form? (It seems that
default value is also checked for duplicates before calling hook - this
still needs to be overriden, as it will prevent our usernames generator
from even getting called.)
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. I've copied
pre-minified freeipa/user.js file and turned it into a plugin.
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) - reg.entity.register({type: 'new-user', spec:
exp.entity_spec}); - I get IPA Error 3004: MaxArgumentError: command
'user_find' takes at most 1 argument.
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?
Best regards
Mateusz Małek
Intelligent Information Systems Group
Department of Computer Science
AGH University of Science and Technology, Kraków, Poland
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
