mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2024-12-28 01:41:14 -06:00
a746c613a4
Brings the DNS record infrastructure in line with the other entities. Uses widgets, nested search, and a littel bit of overloading for dns specific behavior The records now have their own page. simplified link widget and use for dns links work for nested entities. change the field in the link widget to other_entity to avoid name collision. unit test for entity link. fixed reference to entity for getting pkeys work around lack of setattr for dns record mod. update wasn't deducing locked_field type correctly. don't overwrite param_info in init data is required on adder dialog delete works for multiple records use show instead of find for entity_link_widget. https://fedorahosted.org/freeipa/ticket/1038 https://fedorahosted.org/freeipa/ticket/1448 https://fedorahosted.org/freeipa/ticket/577 https://fedorahosted.org/freeipa/ticket/1460 |
||
|---|---|---|
| .. | ||
| conf | ||
| html | ||
| migration | ||
| po | ||
| share | ||
| tools | ||
| ui | ||
| updates | ||
| configure.ac | ||
| Makefile.am | ||
| README.schema | ||
Ground rules on adding new schema Brand new schema, particularly when written specifically for IPA, should be added in share/*.ldif. Any new files need to be explicitly loaded in ipaserver/install/dsinstance.py. These simply get copied directly into the new instance schema directory. Existing schema (e.g. in an LDAP draft) may either be added as a separate ldif in share or as an update in the updates directory. The advantage of adding the schema as an update is if 389-ds ever adds the schema then the installation won't fail due to existing schema failing to load during bootstrap. If the new schema requires a new container then this should be added to install/bootstrap-template.ldif.