Restrictions to the Customization in Libraries
Deleting Entries from Collections in Object Model / Function
You cannot customize an existing collection in an Object Model or Function by removing entries from it. When you delete entries and save, the Function editor will not flag an error but the customization business logic will internally not honor your removing. Consequently, when re-reading the Object Model or Function thereafter, you will keep seeing the removed entries.
This applies to the following collections and entries:
At the top-level Object Model/Function
- You cannot customize by removing a property as a whole (from a Function).
- Neither can you customize by removing symbols or templates.
- Mappers cannot be removed in the Scope of customizing either an Object Model or Function.
At Property level
- You cannot remove command rules in the Scope of customizing a single property.
At Mapper level
- You cannot remove mapping rules in the Scope of customizing a single mapper.
Please note that these delete restrictions only apply to entries originating from ‘deeper’ customization levels. For example, when customizing a project on top of an HQ library, a project engineer will not be able to remove HQ symbols. In contrast, previously-added project-specific symbols can be removed again.
Customizing commands configuration
Commanding is defined from a set of rules, the addressing of which is governed by their Name property.
Command Rule Name
- Command rules names must be unique within the property they apply to. Particularly for newly-added rules, make sure that their names are not identical with already existing names.
- An empty string is not a valid command rule name.
- Never customize existing rules by changing their names.
- As command rule names explicitly occur on the Northbound Interface, you must select them with care. Try to choose an adequate name in the beginning to avoid having to rename the command rule in future releases.
Command Rule Alias
This is the other textual property for identifying command rules. In contrast to the mandatory names, aliases are optional. Only use the alias when its semantics truly matches, otherwise better leave it n/a. Also, keep in mind that aliases must be unique throughout the entire Object Model. In contrast, names only need to be unique within a property.
Command Dependencies
You must not add, remove nor change command dependency in the Scope of customization. However, be aware that the genuine source of the Object Model (for example, HQ) may change command dependency in future releases.
Special Recommendations for Librarians
Librarians must not delete a command rule and then insert a new command rule with the same name. Even though the identical name suggests that the new command rule is identical to the deleted one, there are hidden identifiers so that the new command rule will internally always differ from the old one. As a result, updating a library in this way can cause severe customization issues on the project.
Also, you must not delete an existing command rule and then give its name to another existing command rule. If you update your library in this way, the new release will publish the re-named command rule with the distinct internal identifiers with respect to those sitting in the customized projects.
Avoid these kinds of conflicts by never changing or re-using command rule names. Remember that the command rule names must only be unique within one property.
