-
Suggestion
-
Resolution: Fixed
-
100
-
3
-
Summary
Custom fields provided by add-ons can be added to the customer portal. When these add-ons are disabled and the customer portal or request type configuration page (/servicedesk/admin/<pkey>/request-types/request-type/{id}) is visited, these custom fields will be removed from the configuration. Re-enabling the add-on will not bring them back. Users will have to manually add and re-configure the custom field to get it to work.
This also happens for custom fields provided by default (eg. URL, Number, etc). Steps to reproduce below uses the default custom fields to reproduce
Steps to Reproduce
- Create a Service Desk project
- Create a custom field of type Number Field and add the field to the appropriate Service Desk screen
- Configure one of the request type for the Service Desk (/servicedesk/admin/<pkey>/request-types/group) and add the custom field to the request type
- Verify that this field is visible when visiting the Customer Portal
- Navigate to the Manage add-ons page, filter for All add-ons and expand Custom Field Types & Searchers. Load all modules and disable the Number Field module (Because we used Number Field in step 2)
- This simulates a disabled add-on when a custom field from an add-on is used instead
- Refresh the customer portal page where this field is visible in step #4
- Either that, or refresh the request type configuration page where you added this custom field (eg. /servicedesk/admin/<pkey>/request-types/request-type/{id})
- Repeat step 5 but this time enable the Number Field module instead
- Refresh the page in step 7 again
Expected Results
- Once the module is enabled, the field will re-appear in the customer portal and the configuration page when they are refreshed
Actual Results
- The field doesn't re-appear and users will have to manually add the field again
- When checking the AO_54307E_VIEWPORTFIELD table in the database, we can see that the relevant row is removed from the database after step 6 when the customer portal or configuration page is refreshed/loaded
Notes
- If these pages aren't loaded/refreshed when the module/add-ons is disabled, the custom field configuration will remain
- This is raised as a Suggestion because it is intended behaviour. This feature is meant to automatically remove obsolete fields from the customer portal.
- is duplicated by
-
JSDSERVER-6567 Refreshing the portal forms page constantly while plugin is being updated causes custom field (from plugin) to disappear
-
- Closed
-
-
JSMDC-5768 You do not have permission to view this issue
- blocks
-
PS-55022 You do not have permission to view this issue
- causes
-
PSR-319 You do not have permission to view this issue
- mentioned in
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
-
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-5474] Custom field configuration for a request type will be lost when add-on / module is disabled
Does anyone know exactly how Atlassian resolved this bug? Did they release a new version which does not remove fields related to an add-on, regardless of the the add-on being disabled/uninstalled?
I concur with Matthew Dell on this problem. I think it is up to us to determine what constitutes an obsolete field, not Atlassian. Reconstruction and testing of the SD portal configuration is a significant amount of effort, and we're the ones that look stupid when we have to go back to clients for information because they didn't have the fields available in our forms when raising the request through the portal in the first place. This is extremely unprofessional.
Carla his this on the nose: I lost fields during an update and they were not obsolete. This needs to be fixed. My client has multiple custom insight object fields since we are using that for asset management. I have these items tied to the SD portal forms and they will be tied to other Jira projects. THIS is BAD and needs to be fixed. Vote 1 to fix this bug
So .. thank god .. I updated in our QA environment ... and all custom fields for an Add-on - that we also use for Asset management - are gone from all our requests ... having put work in the request in JSD for over 18 months ... upgrade Jira .. and in a few minutes - all the fields are removed. Unbelievable ... I feel ... and ..wouldn't it be nice .. for Atlassian to maybe ..put a note in their release notes .. maybe a warning .. how to prevent this .. or present it as a risk. And yes .. I had the add-on disabled during the upgrade .. but .. with upgrading add-ons.. etc.. should be able to disable/enable and/or install/uninstall without having Jira assist in wiping out fields. We manage our JSD - and can decide when/where to remove fields from screens.
Another example .. love getting all the work life BS from Atlassian ... but .. how about putting that energy into fixing bugs ... still waiting on another bug that is four years old .. just to fix a webhook issue ...
FYI. I have escalated this with Atlassian and finally got their attention. This issue (bug) prevent their promise, for Data Center customers, to be able to run a zero-downtime upgrade. And therefore it will be considered a bug. Atlassian stated they will attend this shortly.
I lost fields during an update and they were not obsolete. This needs to be fixed. My client has multiple custom insight object fields since we are using that for asset management. I have these items tied to the SD portal forms and they will be tied to other Jira projects. THIS is BAD and needs to be fixed. Vote 1 to fix this bug
This is a bug and nothing else. In the suggestion it states that this is intended behaviour to clean up any JSD forms using a field provided by a plugin that is removed. That is a good intention. But there are tons of use-cases when we need to disable a plugin for other reasons. Upgrades, re-indexing for example. And also when your support is recommending us to go into safe mode to troubleshoot a scenario. If we do this, all custom fields provided by plugins will be potentially lost in our JSD forms.
Please consider this for what it is: a severe Bug
I'd much rather manually remove obsolete fields from customer portal forms than lose configurations as a result of this behavior. In some cases it's easy to recover; other, more complex forms with field dynamics and automatic value setting would take considerable effort to rebuild and retest, even with adequate documentation, not to mention the added effort it would take an entire team to process requests manually and poor customer experience while forms are under construction.
After upgrade , he haven't accessed to portal but fields removed. Now our customer wants from me to restore these fields and I don't know how previous design was
We also hit this issue at VMware when upgrading last night. We had to actually manually recreate the insight fields to the portal forms. Please address this, very annoying problem and hopefully it does not happen in future upgrades. So +1 vote here!
Hi 07ea9a086d10! Yes, we released JSM versions 4.5.5 and 4.9.0 that do not remove add-on fields even when the add-on is disabled. If you upgrade to those or versions newer than 4.9, that behaviour doesn't occur.