cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Creating Change Tasks in different context as Change Notice

Creating Change Tasks in different context as Change Notice

While an application context like a product/library is the frame for common responsibility and access, a change context (ECN) is the frame for all modifications to be performed together.
Such change context can easily expand multiple app contexts and therefore it should be possible to create a change task in another context. This change task will then resolve the roles with others context team based on the defined resource pool of the workflow.
8 Comments
Peridot

Oliver - this would be better to state as business case rather then a solution.  The technical solution might vary as there can be other ways to solve this without increasing complexity. 

 

Can you update the idea with the Business process case please.

Regular Member

This would be helpful for us.  We have situations where we want to store the change task in a different context for access control reasons (i.e. submitting a task to an offshore contractor that we don't want other contracting companies to see).

Peridot

@cforeman - Security labels would help solve this today without the extra complication of different containers.




 

Regular Member

Jeff, I guess it depends on your definition of complication.  Do we really want to implement security labels just for this purpose?  Also, as others have mentioned, the different contractor libraries have different context teams with different participants that we would want to resolve appropriately.

Peridot

@cforeman - this goes to my first point of jumping to solutions.  Again - there are ways today through typing to solve that challenge in conjunction Security Labels are very much inline with the use case you care mentioning.

 

A better process would be to disucss business challenge and goals before solutions.

Regular Member

I guess there is more than one way to view complexity/complication... PTC tends to look at complexity through the lens of how much coding it would take to implement.  Users view complexity as how easy and intuitive it is to do their job.  Just because it's possible to do something doesn't mean it's easy or intuitive.

 

Today we have a single workflow and type that resolves to context roles.  Works great... We bring a new contractor on board, we create a library for them with their folks in the various roles.  The workflow is hooked to a document, however.  Ultimately we'd like to be able to tie the workflow to a change activity instead.  If we could just put the change activity in the context of our choice, everything would just work.

 

I thought that the purpose of this community was for people to share ideas and get feedback... Not to be scolded by PTC for sharing their thoughts.

Peridot

@cforeman I think you misread my comments

Above I was not suggesting a "simple" way to solve to avoid discussion.  I was suggesting that there are ways to streamline this for your need today and keep it easy for the user.  That is not to say there is not room for improvement.

 

I was suggesting to keep it in terms of business cases and needs before moving to solutions so that in understanding them we can best think about ways to solve.  Thinking in terms of solutions tends to limit the answers.

 

 

Garnet

Jeff

I thought i have explained the business case. Implementing a change which affects multiple products/departments but which needs to be released together. I called this a change context.

Now multiple objects in multiple products need to be changed which underly certain authorities which are the context teams.

 

Creating a change task in that context you can pick a correct designer as well as approver and after ALL departments have completed their work it will be released together. Especially if you have to handle complex changes in systems or systems of systems this would work very handy