AnsweredAssumed Answered

Is possible to block merging operations if the original and branched file's state is not the same?

Question asked by Paolo Magalini on Dec 30, 2020
Latest reply on Jan 7, 2021 by Paolo Magalini

Like • Show 1 Like1
Comment • 15

Good Morning.

I have a file in state "Approved". I branch this file that is saved as a new file with version 1/1 and with state "New". After I edited the file I noticed that I can merge the branched file even if it is in a different state: that means that a user can merge a "non approved" file as a new version of an already approved file with the consequences that one can imagine.

I wish to ask you if there are some settings that can block the merging of files that are not in the same state of the original source file or any other similar strategy.

Thank you

No one else has this question

Outcomes

15 Replies

Mike Dekoning Dec 30, 2020 7:06 AM
Mark Correct
Correct Answer
You bring up a valid point, but I know of no setting that would prevent this.
Like • Show 0 Likes0
Actions
- Paolo Magalini @ Mike Dekoning on Dec 30, 2020 9:33 AM
  Mark Correct
  Correct Answer
  Thanks Mike. In fact I am induced to think that the "branch and merge" tool looks like as it is not well integrated into the PDM Workflow and looks like a "parallel" Add-In that doing a copy-rename operation simply adds a crossed reference between the new and old file. Let's see how this will develop in future.
  Like • Show 0 Likes0
  Actions
Ben Nemec Dec 30, 2020 10:56 AM
Mark Correct
Correct Answer
I thought the user doing the merging needed to have check out permissions on the master file to be able to merge?
Like • Show 1 Like1
Actions
- Paolo Magalini @ Ben Nemec on Jan 5, 2021 2:36 AM
  Mark Correct
  Correct Answer
  Thanks Ben. I could say that this is adding a possible additional problem to me:
  In our workflow an "Approved" document is always considered not "checkable out" from drafters and only few users with higher privileges can check out an "Approved" file. Beside the fact that a file in "NEW" state can "overwrite" an "Approved" using the MERGE operation, you are showing me that I would also need an Admin (who has enough permissions) to transit the file from "Approved" to (for example) "In Edit" otherwise drafters would have no permissions to merge the modified document with the original "Approved" document because the merge command imply the need to perform the well known operation of "CheckOut and Overwite" (aka "Merge"). The problem of this, it is that my need is to avoid a "useless" transition because the "Approved" file must no need to be transitioned at all.
  
  Under some point of view I like the idea of Branch and Merge as it follow the source control practices, but on other sides I tend (maybe wrongly) to believe that a good logic in the workflow can probably work better.
  What do you think about Branch and Merge? Do you use heavily?
  
  Thank you.
  Like • Show 0 Likes0
  Actions
  - Ben Nemec @ Paolo Magalini on Jan 4, 2021 9:28 AM
    Mark Correct
    Correct Answer
    Paolo Magalini wrote:
    
    Thanks Ben. I could say that this is adding an additional problem to me: In our workflow an "Approved" document is always considered not checkable out from drafters and only few users with higher privileges can check out an "Approved" file.
    That sounds good, in theory, only Admins should be able to check out a file that is "Approved"
    
    This means that beside the fact that a file in "NEW" state can "overwrite" an "Approved" file as stated in the beginning,
    I'm not sure I follow this. You're saying that the branch file (NEW) can overwrite the source file (Approved)? Only if the user that is doing the merge operation has check out permissions for the Approved state, which would not be ideal use of PDM.
    My understanding is checking out a file in the Approved state is a no-rev change and not part of normal process, only for occasional fixing such as typo in a note or something.
    
    ...I would need a further operation that would require someone with enough permissions, to transition the original file from "Approved" to (for example) "In Edit" because otherwise a drafter would have no permissions to merge the document he had created, but this means that I loose the advantage of creating copy of a document letting the PDM to "remember" the reference to the original source file in "Approved" state.
    Yeah, the further operation would be a revision, as the file is going from Approved to Work in Process or Edit whatever you call the state where designers are doing edits.
    
    I think I am failing to understand your process.
    Are you making a new part just like the old or a potential revision to a part?
    new part just like the old, use Copy Tree, not merge.
    potential revision to a part, branch and merge ok
    branch the part that is "Approved", no checkout permission needed
    once changes confirmed, transition the original to Edit state (which is a new revision) so designer can merge.
    Are you branching and merging without a revision? That workflow doesn't make sense to me, but I'm not seeing the whole picture.
    Who has permissions to revise a file? ie, transition file from Approved to Edit?
    
    Under some point of view I like the idea of Branch and Merge as it follow the source control practices, but on other sides I tend (maybe wrongly) to believe that a good logic in the workflow can probably work better.
    What do you think about Branch and Merge? Do you use heavily?
    
    Thank you.
    We are fairly new to PDM here but are using Branch-Merge sparingly. It's helpful in those cases where there are pie-in-the-sky type changes. Where customer wants to try some stuff before making the change. With branch and merge the existing released (approved) parts can stay released while the R&D is performed on the branch file(s) Then, if and when the change is confirmed the original (source) files(s) are revised by transitioning from Released to WIP which creates a new revision on the source file and the branch can be merged in.
    Like • Show 2 Likes2
    Actions
    - Paolo Magalini @ Ben Nemec on Jan 5, 2021 2:56 AM
      Mark Correct
      Correct Answer
      
      Hi Ben. Firstly I wish to thank you for the time you paid on this topic. I have edited some text to try to make it more concise and clear than before but later i noticed you copied some of the original text and I am sorry I did not notice that until I sent my edits.
      
      For the sake of discussion I try to replay to your list:
      
      Are you making a new part just like the old or a potential revision to a part?
      new part just like the old, use Copy Tree, not merge. Yes indeed. Brand new parts no need PDM references
      potential revision to a part, branch and merge ok
      branch the part that is "Approved", no checkout permission needed
      once changes confirmed, transition the original to Edit state (which is a new revision) so designer can merge. Need to try this because drafter have no checkout rights on "Approved" original source file. An Admin surely can do if that is the logic.
      Are you branching and merging without a revision? That workflow doesn't make sense to me, but I'm not seeing the whole picture. Possibly yes, because the branching operation was meant by us (not a rule) as a possible way to experiment on components, without transitioning the already approved original document. Keeping an "Approved" document has a positive effect on all the other PDM logics. For example the approval transition of an assembly only if referenced documents are already approved or at least are "approvable" by automatic transitions.
      Who has permissions to revise a file? ie, transition file from Approved to Edit? In "Approved" state the idea is to keep only few people with rights to check out the files. In "Edit" state, the drafters.
      Like • Show 0 Likes0
      Actions
      - John Matrishon @ Paolo Magalini on Jan 5, 2021 8:25 AM
        Mark Correct
        Correct Answer
        I think Ben is on the right track here. It also sounds like you may be using Branch/Merge for the wrong reason. Not all workflows are created equal so it's difficult for us to assume all possibilities. I also agree with Ben about the restriction of editing parts at Approved states. I suggest talking with your VAR directly as they can work with you to improve how your Workflow behaves and maybe fix some habits.
        
        JM
        Like • Show 1 Like1
        Actions
        Paolo Magalini @ John Matrishon on Jan 5, 2021 8:43 AM
        Mark Correct
        Correct Answer
        Noted. Thank you John.
        Like • Show 0 Likes0
        Actions
        Ben Nemec @ Paolo Magalini on Jan 5, 2021 9:13 AM
        Mark Correct
        Correct Answer
        As John Matrishon, make sure you talk with support at your VAR. I kind of assumed you have been. One thing to keep in mind, If you have a solidified process workflow that cannot change just for the sake of PDM "best practices" due to other departments or whatever, make sure you communicate that to the VAR. Make sure they understand enough of your process that you're not getting boiler plate responses.
        Like • Show 0 Likes0
        Actions
        Paolo Magalini @ Ben Nemec on Jan 7, 2021 2:14 AM
        Mark Correct
        Correct Answer
        Thanks Ben, beside our VAR it's because I like to get opinions from a broader audience.
        Like • Show 0 Likes0
        Actions
      - Ben Nemec @ Paolo Magalini on Jan 5, 2021 10:49 AM
        Mark Correct
        Correct Answer
        Paolo Magalini wrote:
        
        Hi Ben. Firstly I wish to thank you for the time you paid on this topic. I have edited some text to try to make it more concise and clear than before but later i noticed you copied some of the original text and I am sorry I did not notice that until I sent my edits.
        
        For the sake of discussion I try to replay to your list:
        
        Are you making a new part just like the old or a potential revision to a part?
        new part just like the old, use Copy Tree, not merge. Yes indeed. Brand new parts no need PDM references
        potential revision to a part, branch and merge ok
        branch the part that is "Approved", no checkout permission needed
        once changes confirmed, transition the original to Edit state (which is a new revision) so designer can merge. Need to try this because drafter have no checkout rights on "Approved" original source file. An Admin surely can do if that is the logic.
        Are you branching and merging without a revision? That workflow doesn't make sense to me, but I'm not seeing the whole picture. Possibly yes, because the branching operation was meant by us (not a rule) as a possible way to experiment on components, without transitioning the already approved original document. Keeping an "Approved" document has a positive effect on all the other PDM logics. For example the approval transition of an assembly only if referenced documents are already approved or at least are "approvable" by automatic transitions.
        Who has permissions to revise a file? ie, transition file from Approved to Edit? In "Approved" state the idea is to keep only few people with rights to check out the files. In "Edit" state, the drafters.
        Maybe a screen shot of your PDM workflow would help us help you. It sounds like your Approved state is terminal. Are your files not revised? Do they ever go from Approved back to Edit? I think I'm making bad assumptions about your work flow.
        Like • Show 0 Likes0
        Actions
Wayne Marshall Jan 6, 2021 3:07 AM
Mark Correct
Correct Answer
Hi Paolo,

I think it may be worth summarizing how we (a UK VAR) would expect the Branch and Merge process to work in the scenario you describe. This would be tied to the design of your workflow which we would assume has a route from Approved back to an editable State (e.g Work In Progress) in order to allow it to be checked out then subsequently approved again to create the new Revision. Dependent on the reason for doing the investigation or any links to 3rd party tools (e.g. ERP where you may want to halt production whilst under change) you may also want to 'hide' the Approved file in an intermediate 'Under Change Review' State whilst the investigation is carried out (as per below)
1. Approved File set is moved to 'Change Review' State or equivalent.
2. File set has one or more Branches created as part of an investigation into an innovation or corrective action.
3. If a variation created in one of the 'Branches' is identified as being the next revision...
  File Set is 'transitioned' to Editable (Work in Progress) State
  Selected Branch 'merged'
  File Set is then submitted for Approval and can be 'released' as the next Issue by your standard Workflow route.
4. If it is decided that the Branches are not going to be used the file set can be transitioned back to Approved directly (resetting the 'Revision' stamp to the existing Revision)
I hope that this helps. Essentially as others have suggested, Merging over a released file is not good practice as this changes the existing file without changing the 'issue' number and documenting the reason for the change. Something that your Workflow could be doing for you (and driving a SolidWorks Revision Table)

Kind regards

Wayne Marshall
Solid Solutions Management (UK)
Like • Show 4 Likes4
Actions
- Paolo Magalini @ Wayne Marshall on Jan 7, 2021 2:54 AM
  Mark Correct
  Correct Answer
  Wayne Marshall wrote:
  
  Hi Paolo,
  
  I think it may be worth summarizing how we (a UK VAR) would expect the Branch and Merge process to work in the scenario you describe. This would be tied to the design of your workflow which we would assume has a route from Approved back to an editable State (e.g Work In Progress) in order to allow it to be checked out then subsequently approved again to create the new Revision.
  Yes of course a reviewer can transition a file from "Approved" back to "Work in Progress" and automatize the revision increment upon next approval.
  
  Dependent on the reason for doing the investigation or any links to 3rd party tools (e.g. ERP where you may want to halt production whilst under change) you may also want to 'hide' the Approved file in an intermediate 'Under Change Review' State whilst the investigation is carried out (as per below)
  
  Approved File set is moved to 'Change Review' State or equivalent.
  File set has one or more Branches created as part of an investigation into an innovation or corrective action.
  If a variation created in one of the 'Branches' is identified as being the next revision...
  File Set is 'transitioned' to Editable (Work in Progress) State
  Selected Branch 'merged'
  File Set is then submitted for Approval and can be 'released' as the next Issue by your standard Workflow route.
  If it is decided that the Branches are not going to be used the file set can be transitioned back to Approved directly (resetting the 'Revision' stamp to the existing Revision)
  That's a good point! So the branched file follows it's own life and eventually it might be merged to the original file. Regarding the point 2 I wish to ask you if I could use the RollBack operation, so I would effectively return the original file to Approved state without adding any possible additional logic to the WorkFlow.
  
  I hope that this helps. Essentially as others have suggested, Merging over a released file is not good practice as this changes the existing file without changing the 'issue' number and documenting the reason for the change. Something that your Workflow could be doing for you (and driving a SolidWorks Revision Table)
  
  Kind regards
  
  Wayne Marshall
  Solid Solutions Management (UK)
  Totally agree with you. Indeed I wrote this post because of my surprise noticing that I have not been blocked from merging file with different states (transforming an "Approved" document suddenly as "New") . Ben Nemec correctly notified me that if a user has no checkout rights on "Approved" documents, it could not merge the file anyway. You are stating that a good use of "Branch and Merge" imply the use of some additional logic into the WorkFlow so I would say that it remains the fundamental tool to use even while branching and merging.
  
  Thank you.
  Like • Show 0 Likes0
  Actions
  - Wayne Marshall @ Paolo Magalini on Jan 7, 2021 3:16 AM
    Mark Correct
    Correct Answer
    Hi Paolo,
    
    No problem.. and yes. Rollback could be an option if you decide to not make the changes. I tend to avoid talking about Rollback if I'm honest (and when training Users I often advise alternative approaches). This is not because it doesn't work, but generally because, no matter how many warnings are displayed when carrying out a Rollback, we still (at least a few times in the last year) find we need to help Customers restore a Vault from a backup after a Rollback was done that 'wiped' out months of work when the dialog boxes / warnings were not fully understood by the users. For Customers who do want to have Rollback as pat of their tool set I tend to suggest that they limit the permission to one or two 'super-users'
    
    Cheers
    
    Wayne
    Like • Show 2 Likes2
    Actions
Paolo Magalini Jan 7, 2021 6:31 AM
Mark Correct
Correct Answer
Thanks for your opinion Wayne. I will stay on the options to "return" to "Approved" instead of rolling back.
Like • Show 0 Likes0
Actions

Is possible to block merging operations if the original and branched file's state is not the same?

Outcomes

Related Content

Recommended Content