Custom document attribute not visible in UI after MQL import

PLM ENOVIA
, , , , , , , ,
1

We’ve added a custom attribute called ‘ReviewCycle’ to our document type using MQL schema updates. The attribute was successfully created and I can see it in the database, but it’s not appearing in the UI forms or search tables where users need to filter documents.

Here’s the MQL command we used:


add attribute ReviewCycle type string
add property ReviewCycle to type DOCUMENTS

The attribute exists in the schema, but when users open document properties or try to add it as a table column, it’s missing from the available fields list. We’ve verified the attribute is applied to existing documents, but the UI configuration doesn’t reflect this change. Users can’t filter or sort by this field, which is blocking our document review workflow. Has anyone dealt with UI form configuration not syncing after MQL schema changes?

system 2

Let me walk you through the complete solution covering all three areas: MQL schema updates, UI form configuration, and cache management.

First, your MQL command needs enhancement. While you created the attribute, you need to ensure it’s properly registered for UI access:


add attribute ReviewCycle type string
modify attribute ReviewCycle add range "value"
modify type DOCUMENTS add attribute ReviewCycle

Second, update the UI form configuration. Navigate to your ENOVIA UI config directory (typically <install>/config/ui/) and locate the document properties form XML file. Add this entry within the form definition:

<Field name="ReviewCycle">
  <Setting name="Registered Suite" value="Framework"/>
  <Setting name="Field Type" value="attribute"/>
</Field>

For table column visibility, you’ll also need to update the table configuration XML in the same directory. Add ReviewCycle to the available columns list with appropriate display settings.

Third, address the application cache refresh. After making these changes, you must clear ENOVIA’s metadata cache to force the UI layer to reload form definitions. Execute these steps:

  1. Stop the ENOVIA application server
  2. Clear the cache directory: `/Windchill/codebase/wt/cache/
  3. Delete compiled JSP files: `/Windchill/temp/
  4. Restart the application server
  5. In the admin console, go to Utilities > Cache Management and click ‘Refresh All Caches’

The key issue is that MQL schema updates operate at the database layer, while UI forms are configured separately in XML metadata files. The application caches these form definitions for performance, so even after updating the XML, you need an explicit cache refresh to make the UI layer recognize the new attribute configuration.

After completing all three steps - enhanced MQL registration, XML form updates, and cache refresh - your ReviewCycle attribute should appear in document properties forms, be available as a table column, and work properly in search filters. The attribute will be visible to all users with document access permissions, and you can further customize its display properties (label, order, required status) through the form XML settings.

If the attribute still doesn’t appear after these steps, check the application server logs for form parsing errors. Sometimes XML syntax issues prevent form definitions from loading correctly, and the logs will show specific error messages about which configuration file failed to parse.

This draft is based on general ENOVIA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this before. The MQL schema update creates the attribute at the database level, but ENOVIA’s UI forms and tables need explicit configuration to display custom attributes. Your attribute exists but isn’t registered in the UI metadata. Check if you’ve updated the form definitions in the admin console under Document Management > Forms. You’ll need to add ReviewCycle to both the properties form and any table views where you want it visible.

4

Also worth checking the application server cache. After MQL schema changes, ENOVIA caches the old metadata definitions. We had a similar issue where custom attributes weren’t visible until we cleared the cache and restarted the app server. The UI layer was serving stale form configurations even though the database schema was updated. Try clearing wt.cache and redeploying the UI components.

5

The issue is that MQL schema updates don’t automatically propagate to UI configuration files. You need to update the form XML definitions manually. Navigate to your ENOVIA installation’s UI config directory and locate the document properties form XML. Add an entry for ReviewCycle with the appropriate field type and display properties. After modifying the XML, you’ll need to register the updated form definition through the admin interface and clear the metadata cache. The form configuration is separate from the schema layer, which is why your attribute isn’t showing up even though it exists in the database.

6

Check your attribute range definitions too. Sometimes attributes are created but not properly configured for UI display because they lack range or display settings. The attribute might need additional MQL properties like ‘default’ or ‘range’ to be fully recognized by the UI layer.

7

Thanks for the pointers. I checked the form XML and the attribute wasn’t registered there. Is there a specific XML structure I should follow for adding custom attributes to document forms? Also, which cache directories need to be cleared specifically?

chloe_functional 8

“Tested this on ENOVIA V6R2013x — adding the modify type DOCUMENTS add attribute ReviewCycle MQL step was the missing piece that made the attribute visible in the document properties form.”