Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
- Home
- General
- Feature Requests
- RE: Unable to update object definition fields in UI / batch client-extension
RE: Unable to update object definition fields in UI / batch client-extension
Our use-case:
We developed some features by using Liferay Objects. In order to consistently and automatically configure these Liferay Objects, we created batch client-extensions in our codebase that hold the object definition yaml files for these objects, much like the following GitHub example from DevCon 2023: https://github.com/LiferayCloud/client-extensions-deep-dive-devcon-2023.
Now the customer has been using these Objects for a while, creating a whole bunch of them. And after some time the customer asks for a change in the object definition for certain fields: "Make this field mandatory", "Change this field's type from Long to String".
The issue:
Changes like these are not supported through the UI, and neither are these kind of changes applied after updating the object definition in the batch client-extension. They are simply ignored. This issue is also partially. discussed over here: https://help.liferay.com/hc/en-us/articles/22034314807821-Unable-to-adjust-the-Mandatory-status-of-a-field-after-publishing-the-Object-Definition. Sadly the proposed solution in this article causes a lot of unwanted side-effects:
- Exporting Liferay Objects data through the Export / Import center does not export tags and categories, so these are lost
- Deleting the object definition and recreating it causes:
- Linked vocabularies to be linked to the old object definition id, these will have to be reconfigured.
- Collections for these Liferay Objects are linked to the old object definition id, these will have to be reconfigured.
- Display templates for these Liferay Objects are linked to the old object definition id, these cannot be reconfigured and will have to be deleted and recreated.
- Display pages for these Liferay Objects are linked to the old object definition id, these also cannot be reconfigured and will have to be deleted and recreated as well.
Possible? solutions:
- Allow us to include the object definition id in the yaml file, so we can delete and recreate the object definition without using a different id. In this scenario only the export and import of tags and categories in the Liferay Object export and import would have to be fixed.
- Allow all possible updates in the object definition yaml. Yes this might cause mandatory fields to not be filled, and this might cause fields to lose data since the datatype has changed.
Feature Request Created: https://liferay.atlassian.net/browse/LPD-16285
Hi Thomas,
Please see our response from Product Management:
We are making some changes with the help of headless team to allow users to make mandatory fields to be not mandatory, but we do not support making non-mandatory fields mandatory, this happens because you would need to have to add some type of logic to define what would be the default value of the empty fields when this configuration is done, as we can’t guarantee that those fields would be populated. You would need to do those changes manually indeed, one suggestion could be create another field and move with a script the existing values and the ones empty to add a default value based on the necessary logic from your application.
The same rational is for changing the field types from a field, you would need to create a new field and add a custom logic to move the values from one column to the other with some kind of data transformation.
Exporting Liferay Objects data through the Export / Import center does not export tags and categories, so these are lost
The problem there is that categories and tags are usually scoped to sites, where object structures are at instance level (even though the data can be scoped by sites).
Powered by Liferay™