It's all about the answers!

Ask a question

Migrating from deprecated checkbox in 4.0.6


Rachel Alderman (331518) | asked May 06 '14, 11:36 a.m.
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.
  • 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
So not only creating new attributes with diffierent types would be hugely inconvenient - requiring manual migration of the data over to the new attributes plus changing all reporting, queries, scripting etc that use the existing attributes - but the options don't resolve all the issues with multi-select presentations anyway!

What is the RTC recommended migration strategy for this deprecation issue?

2 answers



permanent link
sam detweiler (12.5k6195201) | answered Jun 10 '14, 7:15 p.m.
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.


permanent link
Stephanie Bagot (2.1k1513) | answered May 06 '14, 1:29 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
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.

Comments
Rachel Alderman commented Jun 10 '14, 9:52 a.m.

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?


N Z commented Jun 10 '14, 6:17 p.m.

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! 

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.