PDM/Works Backdoor

[alexsasdad]

To all concerned,

There is a backdoor into the vault in PDM/Works. I found this while writing procedures for checking in work. Basically if you take ownership of a file that you have changed during check-in, it is possible for you to overwrite someone else's changes to that file. See the following scenario:

User #1 - Checks out an assembly and copies all references to his/her local drive.

User #2 - Checks out a different assembly that has common parts with User #1's assembly and copies references to his/her local drive.

User #2 - Realizes that a change is needed in one of the common parts and checks out that part. He/she retrieves latest copy from the vault, makes changes, checks in the part and releases ownership of that part.

User #1 - Makes his/her changes to the assembly and upon check-in is told that one of the common parts is different than the file in the vault. He/she realizes that they had to change one of the common parts. This common part happens to be the same part that User #2 just checked-in, but he/she is unaware of the change that User #2 has made, and user #1 takes ownership of that file upon check-in. If User #1's date stamp is older than the file that User #2 checked in he/she will get a warning about the file being checked in is older and will be asked if he/she wants to continue. If User #1's date stamp is newer, then he/she is totally unaware that the file in the vault is not the same file that he/she copied to their local drive and when check-in is completed, User #2's changes are lost/overwritten.

We have verified this with PPDM/Works and this is a problem that they created by following requests from a couple of large customers. They are correcting this problem in the next release. Our datecode is 2001/312.

Sorry for the length of this post, I just thought that this might not be known to other PDM/Works users. I have a wmf file of this process if anyone thinks that they would like to see it. My email address is mcampbell@stereotaxis.com.

Hope this helps,

Mike

 

[LisaJo]

Mike -

As we have already discussed, this scenario happens only when using Working Copies, not actual revisions. If there were revisions, then there would two revisions stemming from the one prior revision.

Here are the details and where the users in this scenario would see indications of a "problem":

User #1 - Checks out an assembly and copies all references to his/her local drive.
[Lisa Costa] First of all, this user checks out the assembly, but not the referenced parts (copies, not check outs). Okay, so this person didn't take ownership of the referenced parts and this is why they're going to have an issue later if they make changes to the assembly that result in changes to the component parts.

User #2 - Checks out a different assembly that has common parts with User #1's assembly and copies references to his/her local drive.
[Lisa Costa] Fine.

User #2 - Realizes that a change is needed in one of the common parts and checks out that part. He/she retrieves latest copy from the vault, makes changes, checks in the part and releases ownership of that part.
[Lisa Costa] Fine. But they don't know that somebody else has a copy on their local drive and that person is inadvertently making changes to it without having had checked it out.

At this point in this process, User #1 should see a change to their visual cue for this part in their local drive view. They will see their local copy get a red down arrow next to it, indicating that a newer version is available in the vault. Granted, they may not pay attention to this and may miss it.

User #1 - Makes his/her changes to the assembly and upon check-in is told that one of the common parts is different than the file in the vault. He/she realizes that they had to change one of the common parts. This common part happens to be the same part that User #2 just checked-in, but he/she is unaware of the change that User #2 has made, and user #1 takes ownership of that file upon check-in. If User #1's date stamp is older than the file that User #2 checked in he/she will get a warning about the file being checked in is older and will be asked if he/she wants to continue. If User #1's date stamp is newer, then he/she is totally unaware that the file in the vault is not the same file that he/she copied to their local drive and when check-in is completed, User #2's changes are lost/overwritten.
[Lisa Costa] "User #2's changes are lost/overwritten." While it is true that both User #1 and User #2 have both checked the same part into the vault unaware of the others changes, both have created new revisions - with the exception of using Working Copies, which you wouldn't be doing if you were creating revisions. User #1 should also notice that when checking in this part it is "skipping" a revision (this would be the clue that somebody has gotten here first). They would only notice this if they knew the revision that they originally copied out, however.


We have verified this with PPDM/Works and this is a problem that they created by following requests from a couple of large customers. They are correcting this problem in the next release. Our date code is 2001/312.
[Lisa Costa] There is no change in PDMWorks 2003 that corrects this behavior. If the above scenario was using Working Copies, then the correct fix would be to change the revisioning scheme to include a development level so that data is not overwritten/lost.

Sorry for length, hope this helps clarify and clears up that official revisions don't have an issue and only Working Copies can be inadvertently overwritten.

Lisa

 

[Standing]

We use PDM/Works and our revision scheme does not override any revisions unless we use the plus symbol +. Our scenario can be the same as stated in the last two posts. What I do and encourage others in my department to do is take ownership the moment they plan on making a change. I do not let go of ownership until I check-in the changed parts. What makes this work is the fact that I delete the PDM/Works working directory every time I complete a project and check-in. If someone interrupts my work, I move the files I am working on into a temp folder. After I am completed with the interruption I delete PDM/Works working directory and move my project back into the working directory. PDM/Works has made my job so much easier than before PDM/Works. Bradley