[Freeipa-devel] [PATCH] 062-065 Ticket 1466 Validate AAAA records as valid IPv6 prior to sending to server

[Endi Sukma Dewata]

On 1/9/2012 9:20 AM, Petr Vobornik wrote:
>> 2. The DNS record adder dialog doesn't validate the A/AAAA records. We
>> might want to define some hidden fields, one field for each record type,
>> then the field will only appear if you select the type from the
>> drop-down list. This way each field can have its own validators. This
>> solution is similar to permission target widget and will be the basis
>> for ticket #2208.
>
> Done. I'm dynamically changing only validators for the field. In #2208 I
> will probably drastically change it. My idea is prepare nice metadata
> (like record type - validator mappings and such) and generate adder and
> edit dialogs.

One problem, try adding an A record but enter an IPv6 address, you'll 
get an error message. Then change it to AAAA, the message is still there 
even though the data is now correct. I think the on_type_change() should 
call validate().

Another problem, after adding the AAAA record, close the dialog, then 
then an A record, the validator is still IPv6. I think the 
on_type_change() should be called from reset() instead of 
widgets_created(). The change to select_widget.save() might not be 
necessary because the dialog will call create() before reset().

>> 6. Existing problem, in the extract_child_value() in
>> IPA.multivalued_text_widget if the value is an empty array the function
>> will return the array itself instead of empty string.
>
> Fixed

It works, but it might be better to use if (value instanceof Array).

> Some thoughts when I was implementing #2:
> I wanted to use only one field and abandon the overriding of
> create_add_command in record_adder_dialog (I don't like that hack).
> I was thinking about two possible solutions:
> 1) Override field's save method and use something like this:
> "record[type_got_from_other_widget] = values". Problem is that this
> method doesn't work with command construction in adder dialog and
> details facet - they rely on fields.name will be different from the type.
> 2) Second approach was to dynamically change field's name. This seemed
> bad because the field can be saved in fields map under original name,
> not his current name. (Adding and removing from the map seemed even worse).
>
> In the end I left it as it was.
>
> How evil are those approaches or the relying on fields name (the field
> can put something other or even more values to record in its save
> mehtod.) in command construction? Do we want to keep those constrains
> (field should save under its name only one value)?

We might be able to fix the create_add_command() in entity_adder dialog 
to iterate through the record's contents instead of using the fields 
list. Then you can customize the save() to produce the correct record.

-- 
Endi S. Dewata