Custom (proprietary) attributes: management and per-level visibility

1. TermPortal: ‘Attributes management’ screen:
   1. Client-side
      1. ‘Default / TBX Basic attributes’ tab - 3 new columns  should be added as checkcolumns for grid (“Entry”, “Language”, “Term”):
         1. Must be a read-write representation of values from  entry, language and term boolean columns in terms_collection_attribute_datatype-table
         2. IMPORTANT: if a certain datatype is not applicable for some level - the checkboxes in the corresponding checkcolumns must be disabled.
      2. ‘Proprietary attributes’ tab - 
         1. 4 new columns should be added for grid:
            1. 3 checkcolumns (“Entry”, “Language”, “Term”): 
               1. Must be a read-write representation of values from  entry, language and term boolean columns in terms_collection_attribute_datatype-table
               2. IMPORTANT: if a certain datatype is not applicable for some level - the checkboxes in the corresponding checkcolumns must be disabled.
            2. 4th - actioncolumn (“Actions”) (see TRANSLATE-3034 for details):
               1. Edit-actionicon 
               2. Copy-actionicon
               3. Delete-actionicon
         2. Add top toolbar with ‘Create new plaintext’ and ‘Create new picklist’ buttons (see TRANSLATE-3034 for details)
   2. Server-side
      1. Migrations
         1. Add collectionId column to ‘terms_attributes_datatype’ table
            1. For each datatype-record that represents a proprietary datatype (i.e having isTbxBasic=0) - set collectionId with ID of the TermCollection where such datatype is really used (i.e. where at least one attribute-record exists with the corresponding dataTypeId)
            2. For each datatype-record that represents a proprietary datatype and that is really used in multiple TermCollections
               1. Clone that datatype-record for each of those TermCollections and set the corresponding collectionId for each clone.
               2. Update the attribute-records with dataTypId=<cloned id> where dataTypId=<original id> and collectionId = <corresponding collectionId>
            3. For each datatype-record that that represents a proprietary datatype but is NOT really used in any of TermCollections - remove such a datatype-record, as we won’t be able to detect and set collectionId and we don’t need orphan proprietary datatypes
            4. Add UNIQUE index on type + collectionId in terms_attributes_datatype-table
         2. Add entry, language and term as boolean columns to terms_collection_attribute_datatype-table - these columns will store the info about whether an attribute of a specific datatype in a specific TermCollection is viewable at the corresponding level in Simple UI TermPortal. Default values are false.
            1. Clean up terms_collection_attribute_datatype-table so the records representing proprietary datatypes for collection where they do not belong to - are removed
      2. Runtime
         1. When a TBX file is imported with an attribute of a new proprietary datatype - only one terms_collection_attribute_datatype-record should be created (instead of X records for each of X currently existing TermCollections), so TBX import script should be amended.
         2. API test (as well as T5 CLI implementation) for checking terms_collection_attribute_datatype consistency - should be amended according to what we don’t anymore multiply terms_collection_attribute_datatype-record for each TermCollection.
         3. Check all places that rely on type-uniqueness on frontend and backend, decide whether adding ‘-<collectionId>’ suffix to values of type-column of proprietary datatype-records right after they're fetched from datatype-table - is needed, so from the viewpoint of any further php code and js code values of type-column will be still unique, which is crucial to keep things working.
         4. When proprietary datatype is created or an existing one’s `type` is edited - the duplication with types of TBX basic ones, and with types of proprietary ones within the same TermCollection - should be prevented (see TRANSLATE-3034 for details).

1. SimpleUI
   1. Client-side 
      1. For attributes of both kinds of datatypes (i.e. proprietary and TBX basic ones),  Simple UI app must respect per-level visibility status given for each datatype in json.filterWindow.attributes[..].simpleUI object containing visible: bool and {*}visibleAt: {collectionId1: {entry: bool, language: bool, term: bool}

         , collectionId2: {...}, ...}. The general *visible: bool property is added for convenience, and is indicating whether a specific datatype is configured as visible at at least one level for at least one TermCollection accessible to current user. If visible is false, it immediately means that the corresponding choice in Attributes-dropdown should not be shown at all in SimpleUI's Filter window. Else, if some TermCollections are selected in the TermCollections-dropdown in that window - then the visibility of the corresponding choice in Attributes-dropdown should be dynamically determined based on merged visibility status across these TermCollections choices. 

1. 1. Server-side
      1. Append simpleUI property for each of json.filterWindow.attributes[..] with the values structured as described above for proprietary and tbx basic ones.
      2. Make sure attributes are excluded from search results json response, if their datatypes are configured as not visible for the levels they're at and for the TermCollections they're in.

Properties management and multi-level visibility

1. TermPortal: ‘Attributes management’ screen:
   1. Client-side
      1. New ‘Properties’ tab should be added after ‘Proprietary attributes’ in Attributes management screen in current TermPortal, similar to ‘Proprietary attributes’ with columns:

      2. Name	Levels	Entry	Language	Term
         TermEntryTbxId	Entry	(checkbox)	(disabled)	(disabled)
         TermTbxId	Term	(disabled)	(disabled)	(checkbox)
         Created (by, since, until, at)	Entry,Language,Term	(checkbox)	(checkbox)	(checkbox)
         Updated (by, since,until, at)	Entry,Language,Term	(checkbox)	(checkbox)	(checkbox)

1. 1. 1. Checkboxes for inapplicable levels should be disabled
   2. Server-side
      1. Migrations
         1. New terms_properties_visibility-table should be created with columns:
            1. `id` INT
            2. `collectionId` INT
            3. `property` ENUM (‘termEntryTbxId’, ‘termTbxId’, ‘tbxCreated’, ‘tbxUpdated’)
            4. `levels` SET (‘entry’,’language’,’term’)
            5. `entry` BOOLEAN
            6. `language` BOOLEAN
            7. `term` BOOLEAN
         2. Table should be filled with records: 4 records per each TermCollection
      2. Runtime
         1. When a new TermCollection is created - 4 records in terms_properties_visibility-table should be INSERTED
         2. Non-disabled checkboxes should be (un)checkable and their (un)checked state must be saved into corresponding columns in terms_properties_visibility-table
2. SimpleUI
   1. Client-side
      1. For properties,  Simple UI app must respect per-level visibility status given for each property in json.filterWindow.properties[..].simpleUI object containing visible: bool and {*}visibleAt: {collectionId1: {entry: bool, language: bool, term: bool}

         , collectionId2: {...}, ...}. The general *visible: bool property is added for convenience, and is indicating whether a specific property is configured as visible at at least one level for at least one TermCollection accessible to current user. If visible is false, it immediately means that the corresponding filter-field should not be shown at all in SimpleUI's Filter window. Else, if some TermCollections are selected in the TermCollections-dropdown in that window - then the visibility of the corresponding filter-field should be dynamically determined based on merged visibility status across these TermCollections choices. 

1. 1. Server-side
      1. Append simpleUI property for each of json.filterWindow.properties[..] with the values structured as described above.
      2. Make sure properties are excluded from search results json response, if they're configured as not visible for the levels they're at and for the TermCollections they're in.

Testing

Attention TRANSLATE-3034 Manage custom attributes in TermPortal GUI

is contained in that issue! Test separatly.