mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
Problem: Rule association widget was displaying standard records with external records in one table. User couldn't distinguish the values. When clicking on the external record link it navigated to appropriate page for that entity. But for external value there is no record to show so it displayed error. Solution: * For tables with possible external values a 'external' column was added. It displays "True" if the value is external and nothing if not. Displaying nothing is intentional. If user sees some text in external column he imidiately knows that the record is external without even reading the "True" text. * Rows with external values don't have a link for navigating to record page. This prevents showing the error as no record exists. Additional changes: * Association table widget was stripped of get_records method. Loading records isn't its resposibility it's a resposibility of field. * Column was extended by possible suppressing of link creation. It's done by optional suppress_link argument in setup method. * To allow setting suppress_link attribute in inherited tables a new overridable method was created - setup_column. Posible future improvements: * Table is using dynamic setting of width for columns. Each column has the same width. For flag columns such as 'external' the width of the column is too big. It would be better to be able to set smaller fixed width and the rest of the columns width (without the width set) would be computed (to fit the table). * When a table has displayed buttons in its last column header the cells in column header have different vertical alignmnent. It should be united. https://fedorahosted.org/freeipa/ticket/1993
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.