The ability to delete an extension field is lost in APM 12.9 but was available in APM 11.3.4
Can you elaborate more on this idea? This is in our backlog in a priority list for future releases and more details or use cases would help us to validate the requirements.
A few questions -
- APM 12.9 allows you to hide an extended field if its not required to be present on UI. Is this not helpful ?
- What type of extended fields you would like to delete, is it Simple, or reference , or hierarchy field ?
- If APM is integrated with SDM, do you expect the extended field to be deleted from SDM also ?
Thanks for posting this idea.
I like this idea. It is something that has been more than once.. I no longer need an extended field that I created, can I delete it?
You do a typing errror when you created the custome field. Now you must create the same field again but with another fieldname. This will become a problem if you already have created interfaces that need exactly the name of the field you cannot use anymore.
Hi to all,
i agree for deleting custom fields and also the possibility to delete referenced tables, if not used or mispelled.
11.3.4 did not allow this when it was first released; but this option was then made available after many customer requests with a patch delivery (Test Fix that was included in the Cumulative C3 / RO08547). So what customers now requesting that this availability to delete Extended Fields be brought back into current releases.
We need the ability for APM system administrators to remove the following types of extension fields:
- simple fields (free form text fields)
- reference fields (fields with a discrete set of drop down values)
- hierarchy fields (a set of fields with data dependencies between the fields)
currently these fields can be removed only with custom queries.
Request that we develop this delete functionality, but with the understanding that the APM system administrator user must also have delete rights in the backend database - delete permission for removing rows from a table, and also delete permission to remove a column from a physical table.
In some customer environments this is permitted, but in other customer environments, only the DBA can perform this type of delete action.
If/when we develop this functionality - we need to explain these requirements in the documentation.
I agree with these statement as we are currently on a customer site where the 'quirky' behaviour of creating Configurations and Extensions has left us with a number of values in List Management that we cannot get rid of.
We also cannot delete the Global Configurations.
This is a great idea and much needed. The ability to delete fields from tables does add a layer that will need to be addressed and well documented.
Retrieving data ...