Community

Post

Question: How to handle problems caused by modifying types, such as changing/removing properties?

Hi all,

We have been running into a lot of type problems during our upgrade when trying to develop custom tasks and plugins for XLR. The issue seems to be when we have an existing or archived releases using this custom task and then we attempt to modify it the existing releases will fail if there is a property or field mismatch.

So, I was wondering what others are doing to mitigate this. It would be painful to go through existing releases and remove these tasks. We love the extensibility of XLR but we keep getting caught by dead or new types that put us into catch 22 situations.

So in our scenario, we have a custom task that has been included in releases for some time. We recently removed a field (property) and tried to redeploy. Are you saying if any of those releases that use this task are archived we will not be able to move forward? Is there no recourse for this? Maybe a way to keep an old type but not have it show in the UI. If I am understanding this right it seems like it would really hinder or custom task development.

We were talking internally about fixing this problem by changing releases and it got us thinking about audit implications. Should these releases be immutable, maybe they are when they are archived? Just making the observation if indeed the only choice when updating custom tasks is to 'change' types in a release.

Was experimenting a bit and it seems not to involve too much witchcraft to replace unknown tasks in archived releases with a flagged manual task. Its the same mechanism we use for importing a template.

You maintain original task details like comments, attachments, assignee, duration and task output (in the comments) and the task is flagged as being changed. Would this suffice for the audit? I think that even the original task is stored in the database somewhere, so you could get to that, albeit not easily. On the other hand, you did throw away a type definition, so indeed some data maybe lost.

Thanks for talking this through with me. So are you saying we could potentially get around a type change even if it was used in an archived release? Or are you saying this is something you will develop for future versions? I think think archived releases that used the task type are the hang up.

Does this become easier for users that use an external Db instead of the JCR? Any difference there.

Yes, I would suggest putting this high on the backlog. Same issue here.

Removing releases because they do not map on a modified type definition is not preferred as this would mean you'd be removing value data for statistic purposes as well.

The trick I use a lot is making properties hidden with a default 'default'.

Example:

<!--mvnPomVersion below is deprecated. Needs to be removed, but old processes still use it.--> <!-- Please do not remove (yet). For now left it 'hidden' with default 'default'--> <property name="mvnPomVersion" category="output" hidden="true" default="default"/>

For types we can do something similar. Leave the old type definition in, bit in Configuration > Task Access restrict rights of the old task to a Role with nobody in it, for example a dedicated role called "Deleted task" .

We will use these tricks to get us through short term. I was hoping that the Task Access would remove the old types from the menu completely. Is that possible? I can live with having them disabled for now, but would love it if could totally hide stuff from our users.

Thanks again for the input we have sure been struggling with this problem,