Red Hat Bugzilla – Bug 1008918
Only 1 process shown for 2 versions of deployment
Last modified: 2016-07-31 21:08:24 EDT
Description of problem:
Imagine you have a project A with version 1. In this project, you have a process P. You deploy this project. Then you need to do some changes and deploy an updated version of the project, version 2. But for some reason, you cannot undeploy the first version - perhaps some instances of process P are still running. You just deploy the new version, successfully.
Now, in the Deployments, you can see the two version deployed at the same time. But you can only see one process P in the Process Definitions perspective.
These two processes might be different, they are definitely from different deployments, so they should be both displayed.
Same thing happens if you also change the process version before the new deployment.
Only the old version of the process is available. If you remove the older deployment, the older process also disappears, of course, but the new version still isn't available, even after refreshing.
Version-Release number of selected component (if applicable):
BPMS 6.0 ER3
Steps to Reproduce:
1. Create project A, set version 1.
2. Create process P, set version to 1, in project A.
3. Save the process and build and deploy the project.
4. Check the Deployments and Process Definitions for the project and process.
5. Go back to Authoring and change the process version to 2, save it.
6. Change to project version to 2, save, build and deploy.
7. Check the Deployments - the project v.2 is there as well.
8. Go to Process Definitions.
9. Go to Deployments, remove deployment of project A, version 1. Repeat step 8.
8. There is only process P, version 1 available.
9. There is no process P, none of the versions are available.
8. There should be two versions of process P available - 1 and 2.
9. Only one v.2 of process P is available.
Zuzana, I just tried with both ER3 and master(community) and was not able to reproduce the described behavior. Would you mind to check it once again on your end that the right deployments were removed. Maybe a good idea would be to have a hangout quickly where you could show me how to reproduce it. Maybe I am missing something here...
(In reply to Maciej Swiderski from comment #1)
> Zuzana, I just tried with both ER3 and master(community) and was not able to
> reproduce the described behavior. Would you mind to check it once again on
> your end that the right deployments were removed. Maybe a good idea would be
> to have a hangout quickly where you could show me how to reproduce it. Maybe
> I am missing something here...
Well. I've reproduced this again. Then started recording another attempt, so that I'd have a short .mpeg for you at least and since then I am unable to reproduce this as well.
The only cause for this that seems at least a bit probable is linked with bug 983585 comment 4 - I used save, not autosave, and I'm quite sure the changes got saved, that I got the green message about successful save, but.. who knows.
When I tried with no changes made to the process, the results were the same as in this bug. So, if you have 2 deployments with the same process (name, id, version), only one of them is shown in the Process Definitions. Not sure if this is ok. If it is, perhaps we can close this issue and I'll focus on the Designer - whether there is some intermittent problem with 'Save'.
I would say then it behaves as expected as we have only process name, id and version as elements that the UI considers and that causes they are not visible - or only one is visible. If we would included another column e.g deployment id then both should be visible. Not sure that we should add another column for that. Most likely different deployments will have independent process id, etc.
So my vote is to close this one unless we decide that the current behavior shall be altered.
At this point we should move forward with what exists (option 1) with mouse over note that may highlight the difference, I would not be comfortable adding the ids to the table at this point. We need to think through this properly and come up with something that is intuitive to the user. We can tackle that for post 6.0.
I believe this can be either marked as modified or as duplicate - see https://bugzilla.redhat.com/show_bug.cgi?id=1167610 that is marked as modified.
*** This bug has been marked as a duplicate of bug 1167610 ***