Does a field need to be changed to read-only, mandatory, or has a particular value or another setting? You can view these settings on its dictionary entry.
Dictionary Entry (without the override)
Right-click on a field and select “Configure Dictionary.”
The dictionary entry record for this Zipcode field is where the primary attributes of a field are set– its column label, its length, the field type, along with features to indicate whether it is read-only or not, etc. This information defines the field as in a dictionary. (Each table itself also has a dictionary entry, but discussion of that is outside the scope of this article.)
Is it safe to make changes to this entry? Not necessarily! First, take a look at the Table field on the dictionary entry. Does it list the table on which you want to change this field?
In this example, the change was determined to be safe because
- The ABC Request table on which we right-clicked to open the Zipcode (u_zip) field definition is the same table listed in the “Table” field.
- We also know that we want this change to affect any tables extending ABC Request and using the u_zip field. Or, if ABC Request is not itself extensible, we would not worry about this change affecting child tables. [If you don’t know how to tell if a table is extended, see the end of this article.]
If safe, the change can be made on this entry. To do something like make the field mandatory by default, it’s a simple matter of checking the Mandatory checkbox and saving/updating this record.
The Zipcode is now mandatory when looking back at the ABC Request form.
The need for an override
ABC Request did not inherit the Zipcode field from another table. But what if it did?
When fields are inherited from or by other tables, a change to a field on the base table (parent table) will show on all of the other tables that use the field. An example is the many tables extended from the “task” table (incident, problem, sc_request, and others), which have inherited fields like short_description, priority, and state.
In this example, ABC Request is extended from the task table, so some fields are inherited from the task. One of them, in this case, is “Short description”.
View its dictionary information by right-clicking on the field and selecting “Configure Dictionary.”
The Dictionary Entry for short_description displays.
Notice:
- The Table field does NOT list the ABC Request table – it lists the task table!
- There is a “Dictionary Overrides” related list at the bottom. That is what we’ll use to make this change.
- You may or may not get a message at the top saying the record is in a different application – but regardless of whether you change the scope, this is NOT the record to update.
Why is a different table listed?
The ABC Request table inherits short_description from the “task” table. It can do this because ABC Request extends the task table. The dictionary entry for a field will list its base table, so that’s why short_description lists “task” for the table, but u_zip from the first example lists the ABC Request table on its entry.
Why not make the change here?
If the change for short_description is made directly on its dictionary entry, it will affect the base “task” table itself and all tables that extend from it and inherit the short_description. For example, making the field read-only here would be read-only on task, incident, problem, sc_request, and other tables.
Time for Dictionary Override
This is where a dictionary override comes into play. An override entry allows you “override” the base table definition to make customizations specific to a table.
Scroll down and select the “Dictionary Overrides” related list tab.
This lists the overrides for different tables that inherited the short_description from the task. Search to see if your table already has an override entry. In this case, no results for *abc were found, so an entry for this table did not exist for short_description.
If there had been an override entry already in place for the table, it could be opened and updated accordingly.
Otherwise, in this example, click “New.”
The Dictionary Entry Override screen appears. The base table for this field (in this case, the task table) will be listed. The table on which you update the field properties should be in the “Table” field. The changes you make will only affect this table and any tables that extend it, but not its base table or other tables extended from the base table.
Now check the “Override read-only” checkbox, then the “Ready only” checkbox. These will change the field to read-only on the ABC Request only.
Submit or Save the record and return to the Dictionary Entry page. A listing for this new dictionary override should appear in the Dictionary Overrides related list.
Testing the result
The Short description field is read-only on the ABC Request form, as specified.
Confirm that the ready-only change to field “short_description” on ABC Request did not affect another table extended from the task, as we did on the “sc_request” form in this screenshot. Until familiar with working with dictionary overrides, it is good to check some other tables extended from the same parent to make sure the field was not affected.
Warnings
Dictionary changes can have unintended effects if not done correctly.
- Use a Dictionary Override to avoid making changes to the base table.
- Consider that reports from a base table-like task might be affected by Dictionary Overrides on fields like state in particular. For instance, using a dictionary override for the state field to “Override attributes” for the state on the incident table could throw off a report done on the task table for all open records across incidents, requests, etc.
Conclusion
- The Dictionary Entry for a field defines its properties. If it is changed, it will affect any tables that inherit that field.
- The Dictionary Override related list provides a way to make changes to a field on the specific form(s) on which the changes are needed.
- In either case, consider what the effects of the change might be.
P. S. – One way to tell if a table is extended or not:
When viewing a record in the table, click on the context menu and select “Configure” > “Table.”
Select the “Controls” tab and look at the “Extensible” checkbox to see if the table is extended.
If it is checked, tables extended from it can be viewed at System Definitions > Tables in the Application Navigator (or type sys_db_object.list in the navigation filter). Search the “Extends table” column by the table to see if it is extended. In this example, ABC Child is found to be extending ABS Request.
- If no results are returned, the table is not extended.
- If results are returned, the table is extended, and it needs to be determined whether the affected tables will benefit from the dictionary change. If the affected child tables should not have the change, one way of handling that is to put overrides on them to counteract the override on their parent.