Migrating from deprecated checkbox in 4.0.6
I've seen in RTC 4.0.6 that the multi select checkbox presentation is marked as deprecate in the editor configuration in the 4.0.6 client and that a warning is shown on every instance of the presentation in work items displayed using the browser rather than the client. In the RTC 4.0.6 new and noteworthy "This warning is in preparation for removing the presentations entirely in a future release. Work items that use these deprecated presentations must be reconfigured to use supported presentations."
From my testing, it doesn't seem possible to "reconfigure" the existing attribute's presentation to an alternative multi-select presentation (only valuesetcombo and valuesetpicker kinds are available). Also I've previously experienced difficulty with the restriction that an attribute's type cannot be altered once there is a work item has been created with that customisation. So my only option seems to be to create new attributes with different types (either Enumeration List or String List) to exploit the new presentation kinds that support multi-select.
What is the RTC recommended migration strategy for this deprecation issue?
From my testing, it doesn't seem possible to "reconfigure" the existing attribute's presentation to an alternative multi-select presentation (only valuesetcombo and valuesetpicker kinds are available). Also I've previously experienced difficulty with the restriction that an attribute's type cannot be altered once there is a work item has been created with that customisation. So my only option seems to be to create new attributes with different types (either Enumeration List or String List) to exploit the new presentation kinds that support multi-select.
- Enumeration List type based on the existing enumeration, would allow me to select a Checkbox presentation, but still does not enforce the dependencies of a valueset when using a multi-select presentation.
- String List type will allow me to restrict the values based on attribute dependencies with with a HTTP Filtered value set, but I can't use a checkbox display, only a "picker" box and I can't restrict the values to the value set returned because of 240267
What is the RTC recommended migration strategy for this deprecation issue?
2 answers
while not the original topic, the utility I posted in the answer here
https://jazz.net/forum/questions/137079/resolved-not-a-bug-with-user-mail-settings-and-receivemails
will allow you to turn off email notifications for a list of users (by email address), to prevent spam.
and then restore the settings later (using the same email list)..
as a side note, I discovered that turning off email at the server will NOT prevent the storm, as the emails will be queued anyhow (last experienced in 4.0.3) and go flooding out when email is re-enabled.
https://jazz.net/forum/questions/137079/resolved-not-a-bug-with-user-mail-settings-and-receivemails
will allow you to turn off email notifications for a list of users (by email address), to prevent spam.
and then restore the settings later (using the same email list)..
as a side note, I discovered that turning off email at the server will NOT prevent the storm, as the emails will be queued anyhow (last experienced in 4.0.3) and go flooding out when email is re-enabled.
Anytime a work item attribute is deprecated, (in short) you need to create a new work item attribute of the migrated type, export a copy of your work items, update the CSV so that the deprecated value is now the migrated attribute, and import the CSV to UPDATE existing work items (not create new ones).
The process is fairly intensive - I recommend opening up a PMR with IBM support and having them walk you through the process to minimize any issues.
The process is fairly intensive - I recommend opening up a PMR with IBM support and having them walk you through the process to minimize any issues.
Comments
Thanks for the response.
As this methodology requires each existing work item with the deprecated attributes to be updated, to populate the new attributes, do you know of a way to prevent the owners and subscribers of these work items being spammed with hundreds of emails notifying them of the changes to the work items?
Hi Stephanie,
This is really not good enough!
If your team decides to deprecate an attribute, then they need to provide an easy mechanism to migrate those attributes to the new one.
It can be very intensive, an exporting/importing really should not be the path you expect your customers to take (apart from this there are dashboard and reporting changes, not to mention the spam issue mentioned above).
No doubt, a RFE could be opened, but by then, it's probably too late, and I wouldn't expect that we would have to!