[Freeipa-users] Backend & UI plugin update for 4.4.x

[Pavel Vomacka]

Hello Steve,

I tried to reproduce what you described on the very same version of 
ipa-server and I was not successful. Actually I was not used your 
back-end plugin. I tried it with no plugin and then with your UI plugin 
and both worked correctly. Did you do any other changes somewhere in 
your installation?

I will try it again also with your Python plugin and we'll see.

On 01/24/2017 08:59 PM, Steve Huston wrote:
> And now I'm convinced this has nothing to do with my plugin and
> instead is a bug somewhere in FreeIPA.
>
> I removed the entirety of the "astrocustom" plugin that I wrote,
> restarted httpd, and force reloaded the page in chrome.  I clicked to
> add a new user, gave the basic information, and clicked "add and
> edit".  The bottom of the page shows the "Employee information" on the
> left side bottom, and the manager drop-down is empty.  I entered '1'
> in the "employee type" field and clicked save, and now "Employee
> Information" is on the right side directly under "Contact settings",
> and the manager drop-down is populated with the list of UIDs on the
> system.
>
> When the UI is in the failed state, the "email address" field is also
> blank, but when things switch to how they should be (after submitting
> a change) it is populated with the email address in the record.  I
> just tested by adding a telephone number to the record, and that also
> made the contact information and employee information facets refresh
> with the proper data.  Pressing shift-reload again makes all the
> information disappear (including the telephone number I just entered).
>
> This is with ipa-server-4.4.0-14.el7_3.4
>
>
> On Mon, Jan 23, 2017 at 1:55 PM, Steve Huston
> <huston at astro.princeton.edu> wrote:
>> Just tested again, and this is still baffling:
>>
>> * Create a stage user with the right data, works fine, can be edited.
>> * Enable that user, and now the two fields ('manager' and
>> 'employeeType') appear to have bogus data in the UI, and I cannot save
>> the page without changing them to something else.
>> * Once that user is saved, the "Employee Information" facet moves to
>> the right side of the page, and now shows not only the current data in
>> the manager drop down but also the other choices (uids).  Change the
>> value of manager and employeetype back to what they were previously
>> and it saves.
>> * An ldapsearch run when the user is first created (as the directory
>> manager), and after having two edits (one to change the values to
>> something else to let the webui save them, and one to change them back
>> to what they should be and were the first time) produce completely
>> identical results.
>> * The output of "ipa user-show <uid> --all --raw" is also identical at
>> those same steps.
>>
>> So something, somewhere, is being saved in a way that prevents the
>> webui from displaying them properly, that gets fixed when those values
>> are manually changed via the webui.
>>
>> On Thu, Jan 19, 2017 at 2:44 PM, Steve Huston
>> <huston at astro.princeton.edu> wrote:
>>> Even more interesting...
>>>
>>> I tried to modify one of the records that was not displaying properly
>>> in the "active users" group, and sure enough the webui complained that
>>> the "Requested By" (relabeled "manager") field was not filled in since
>>> it was blank.  It also, however, complained that the "User tier"
>>> (relabeled "employeetype") was incorrect, even though it showed the
>>> label associated with the value 1.  I clicked the search drop-down for
>>> manager, typed in my own uid, and even though everything had been
>>> blank in the drop down before now my uid showed up.  I clicked on it,
>>> and my uid was now in the manager field.  I then clicked the drop down
>>> for employeetype, and chose one of the other options.  I was now able
>>> to save the changes to the record.
>>>
>>> Upon reloading the page, the "Employee Information" facet now shoed up
>>> on the right side bottom, instead of the left side bottom where it was
>>> appearing.  I was also now able to change the drop-down fields for
>>> manager and employeetype to another value, and save them, and they
>>> worked fine even filling in all the data that should have been there.
>>> This almost seemed like the data being returned by the server was
>>> flawed somehow, and confusing the webui, but once it was forced to
>>> have the right data and re-saved it worked fine subsequently.
>>>
>>> I looked at the output of "ipa user-show <uid> --all --raw" both
>>> before and after making such changes on a user, and can detect no
>>> difference between them.
>>>
>>> On Thu, Jan 19, 2017 at 1:14 PM, Alexander Bokovoy <abokovoy at redhat.com> wrote:
>>>> On to, 19 tammi 2017, Steve Huston wrote:
>>>>> On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy <abokovoy at redhat.com>
>>>>> wrote:
>>>>>> In short, FreeIPA 4.2 -> 4.4 change was by splitting server and client
>>>>>> side plugins into different paths (ipaserver/plugins and
>>>>>> ipaclient/plugins instead of being common in ipalib/plugins). The client
>>>>>> code was also changed to always read metadata about API from the server
>>>>>> side. This means the client can adopt to any server version that
>>>>>> supports API metadata.
>>>>>
>>>>> Right, and I think that the most of the plugin I had belongs
>>>>> server-side; in fact, that's where I migrated it to, and things work
>>>>> fine.  I haven't tested if I can change those values with the cli, but
>>>>> I'm less concerned about that at the moment.
>>>>>
>>>>>> In my sample external plugin you referenced above you can see that I
>>>>>> have client-side change that replaces an input string by a file
>>>>>> reference so that a file can supplied instead of typing the content of
>>>>>> the file on the command line. This is one of most used patterns for
>>>>>> client side plugins.
>>>>>
>>>>> In this case, my biggest problem is with the web UI.  The 'manager'
>>>>> drop down (which I have renamed through the UI plugins to "Requested
>>>>> By" to show what user requested and is responsible for this account)
>>>>> works fine in the 'add/modify stageuser' context, but not at all in
>>>>> the adduser/moduser context, and I can't seem to find out why.
>>>> I'll defer answer for this to our web UI wizards but they would need to
>>>> see your code to help, I'd guess.
>>>>
>>>> --
>>>> / Alexander Bokovoy
>>>
>>>
>>> --
>>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
>>>    Princeton University  |    ICBM Address: 40.346344   -74.652242
>>>      345 Lewis Library   |"On my ship, the Rocinante, wheeling through
>>>    Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
>>>      (267) 793-0852      | headlong into mystery."  -Rush, 'Cygnus X-1'
>>
>>
>> --
>> Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
>>    Princeton University  |    ICBM Address: 40.346344   -74.652242
>>      345 Lewis Library   |"On my ship, the Rocinante, wheeling through
>>    Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
>>      (267) 793-0852      | headlong into mystery."  -Rush, 'Cygnus X-1'
>
>

-- 
Pavel^3 Vomacka