Post

6 followers Follow
0
Avatar

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.   

Any ideas, are we alone?

Thanks all for any input!

Bernie

Bernie Bonn

Please sign in to leave a comment.

15 comments

0
Avatar

No, you're not alone! This feature has been requested by other parties and we would love to tackle it. There are some practical issues we need to overcome but it is definitely on our roadmap. 

Let me check if there is something we can do in the meanwhile.

Kind regards,

Hes Siemelink 0 votes
0
Avatar

Hi Bernie, here's an approach that may work for now.

We can use the repository service, which is also exposed in XL Release. Access is only granted to users with admin role.

You can use it to query the repository for objects of a certain type. Say that you have a type custom.MyTask, then you can use the following query call.

    http --auth admin-user:pass GET http://localhost:5516/repository/query?type=custom.MyTask

The result is a list that contains the ID and the type. The first part of the ID refers to the ID of the template it is in. For example:

 

[

    {

        "ci": "Applications/Release494474/Phase2437552/Task5367486"

        "type": "custim.MyTask"

    }

]

Now for each ID, call the change task type REST endpoint to change it to, say a manual task (xlrelease.Task)

This will change it for all tasks that are in active releases or templates. It will not change it for archived releases.

Hope this helps,

   Hes.

Hes Siemelink 0 votes
0
Avatar

Thanks a bunch Hes!

 

This is a cool solution.   Do you know if we will still see a stack trace if the mismatched type is only in an archived release?  

 

Thanks again,

Bernie 

Bernie Bonn 0 votes
0
Avatar

Bummer.   So we would still break when we introduce new since we have a bunch archived.   I am glad to hear we are not alone and it is on a road map.  Keep us updated if possible.  

Thanks for your replies Hes!

Bernie

Bernie Bonn 0 votes
0
Avatar

Thanks Hes,

 

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.

Thanks!

Bernie

Bernie Bonn 0 votes
0
Avatar

Aah Yes.  Another concern here :)  Aren't we fun??

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.  

Just more fuel for the fire.

Bernie Bonn 0 votes
0
Avatar

Hi Bernie

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.

Kind regards,

Hes Siemelink 0 votes
0
Avatar

Hi hes,

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.  

Thanks,

Bernie

Bernie Bonn 0 votes
0
Avatar

Hi Bernie, it will be a feature of a coming release and it doesn't seem that difficult to do, so that improves the chances of being done sooner rather than later.

Loading archived releases with unknown types does not depend on the database backend.

I was only saying that if an auditor sees a converted type (with loss of information), in theory it would be possible to peek into the archive database to see the original contents. 

Kind regards,

Hes Siemelink 0 votes
0
Avatar

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"/>

Does the trick for now, but would love to see this addressed.

Cheers,

Michiel.

Michiel Sens 0 votes
0
Avatar

Nice trick, Michiel!

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" .

This way the task will be disabled in the Add Task menu. 

 

Hes Siemelink 0 votes
0
Avatar

Great Thoughts Guys,

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,

 

Bernie

Bernie Bonn 0 votes
0
Avatar

Hi Bernie

I agree it would be nicer to have the items hidden rather than disabled in the menu. This use case is a good argument in favor it -- let me see if we can pick this up for XLR 5.0 still.

Kind regards,

Hes Siemelink

 

Hes Siemelink 0 votes
0
Avatar

Hi, is there any update to this thread in XLR 6.0? I had an issue with a deleted parameter (task still exists) - it threw a fit and I've had to add the parameter back in as a hidden value.

Ben Newton 0 votes