mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2024-12-25 08:21:05 -06:00
65bd82eaa1
It's hard to detect if or which type dialog is displayed becouse not all dialogs have IDs. On dialog open, it's id or name (if id is not set) is used for containing element id. Many of dialog types were missing id or name so name was added to each dialog type. In HTML, element's id should be unique. Our framework allows opening two dialogs with the same id. It may lead to state where getElementById method may have unpredicted behaviour. Therefore attribute 'data-name' with dialog's name was added to dialog's containing element. Automation framework can search more reliable by using this attribute instead of id. https://fedorahosted.org/freeipa/ticket/2853 |
||
|---|---|---|
| .. | ||
| conf | ||
| html | ||
| migration | ||
| po | ||
| restart_scripts | ||
| 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.