Duplicate Named Document Tabs

StephenG

I have discovered it is possible to have document tabs, of the same element type, to have identical names at the same tab (folder) hierarchy level.

I am surprised duplicate names are not at least flagged as a warning to the user. I know this doesn't confuse the OS since the name is metadata to its real GUID, but this is a source of confusion and potential error for humans.

Is there a good reason why OS allows this?   

lougallo

Onshape has no restrictions when it comes to naming. Documents, features, tabs, etc are all allowed to be named anything, even duplicate and to this point we have stuck to that principal. Mainly it was not a limitation to our system and so we did not put in additional logic to prevent it. 

StephenG

I see that OS took the "maximum flexibility" (not my job) path here and makes no attempt to enforce "human readable" ID uniqueness throughout the product. However, at some point it must be possible to ensure an element is uniquely identified and not duplicated within a specific domain.

I can use OS Search to find specific duplicates based on any criteria I use for unique ID, ex. equivalent Part Numbers, but I have to explicitly look for it. I was hoping there was a global method to help prevent and/or locate "human readable ID" duplicates. 

It has been my experience that "Part Numbers" and "Document Numbers" are highly controlled within a company. Is there anything in OS that helps enforce/integrate with a company's part/document naming/numbering scheme? 

Jake_Rosenfeld

@StephenG

Professional customers have access to our Release Management capabilities, which provide automatic unique part numbering.

https://www.onshape.com/videos/release-management-and-approval-workflows
https://www.onshape.com/videos/introducing-release-management-and-approval-workflows-040518

Please raise an improvement request if you would like to see increased visibility w.r.t. duplicated tab names, document names, part numbers, etc.

StephenG

@Jake_Rosenfeld
As a non-Professional user I didn't pay much attention to the Release Management capabilities when they were announced; I should have just to be better informed about Data Management capabilities and where the OS product is going.

I have started to watch the videos; 15 minutes in I can see it provides a basic part numbering uniqueness mechanism that probably fits small companies. I guessing the OS Enterprise greatly extends what you can do regarding workflow/release management making the product more attractive to larger, multi-organizational companies. 

If you have time... a few questions: (response optional)
  
Have you encountered a customer that wants to give a drawing a separate unique "Part Number" and a separate unique "Drawing/Document No."?

Have you encountered a customer using a Revision scheme that distinguishes "Major" vs "Minor" releases based on changes related to "Fit, Form, and/or
 Function"? 

I didn't see an option to prevent release of an assembly or drawing unless all the referenced elements have been released and are not obsolete. Is there one? (New assembly design created with a released element which subsequently was made obsolete.)

It appears that the default release flow only has one approval step. Is is possible to created multiple approval steps in order to serialize a review/approval process? (Answer: Custom workflows coming? In Enterprise?)

How would one connect a design activity (ex. date creation, change) to a authorization document (ECO)?  (Answer: Release Name/Notes?)

Can you explain the difference between "Reject" and "Discard"?

john_mcclary

@StephenG

Having multiple parts with the same name can be a benefit in some cases.
Take for example this problem: https://forum.onshape.com/discussion/comment/41645#Comment_41645

The best solution is to name all the parts with the same name and use OpenBOM's group by name option to combine similar parts.

StephenG said:

I see that OS took the "maximum flexibility" (not my job) path here and makes no attempt to enforce "human readable" ID uniqueness throughout the product. 

Please realize it really is NOT their job to ensure you properly name your parts, nor should they care at all.

If you have ever worked with solidworks (or any other file based cad) you would know how detrimental this limitation can be.
When using solidworks you need to use a unique filename on a per/project basis. Even for purchased parts like bearings or pneumatic cylinders ect.
Because if you DON'T then you open 2 different projects that have parts with the same name, solidworks would automatically use whatever part that is currently loaded in memory and replace the parts in the assembly. This is hell on earth when trying to work with even opening an old job to double check your work. It required so much more overhead just to copy an old job as a start point for a new one.

Also if you want to rename a drawing tab they have this single name "feature". So if you remove one tab from the middle of a drawing file with 50 or so drawing tabs. You have to rename starting from the bottom and rename them all one at a time in reverse order, and hope you counted properly. Otherwise you would need to do it again. OR you can rename them all to something random, then start at the top and name them in order.

Yes I have lived that hell for 8 years, no thank you!

Onshape is not name based, everything is an object in a database, which gives US a lot of freedom when it comes to naming. Why waste resources to constantly check for naming overlap? I would pull my hair out if I got prompted for every time I had a name overlap.

Also I have a lot of left hand/right hand parts. It is very convenient to select both parts in the parts list, open properties, name both parts the same thing "Discharge Shingle CCW" then rename only one part by deleting one of the "C"s to make "Discharge Shingle CW" it seems trival, but I do all the renaming at the END of the project. So there are plenty of part 1, part 2's throughout until just before detailing. It's just one less thing I need to worry about while I should be thinking about the design itself!

Great Job Onshape, don't you DARE change a thing! 

StephenG

@john_mcclary

I guess I should consider myself fortunate the two 3D MCAD systems I have had the most experience with (Euclid/I-DEAS) had little to no dependency on underlying Operating System (OS) file names used; CAD data management (parts, assy, drawings, etc.) was object oriented even though OS files existed in a data store behind the RDB curtain. Believe it or not, object oriented (non file based) 3D CAD systems are have existed for decades; Onshape is not breaking new ground in this respect.

I certainly do not expect Onshape (OS) to ensure my parts are properly named, but I did have an expectation OS would help manage/mitigate the inherit confusion when duplicate named elements of the same type, exist in the same context. I do not want to waste resources (my time) looking through duplicated named tabs to locate the one I am really interested in.

Onshape's normal behavior is to generate a context unique name when a new element is created; I was just surprised it does not enforce it, more surprised it doesn't warn the user of potential confusion in creating a duplicate, and really surprised after a 1+ yr of light OS usage I never noticed it. 

I think I should clarify what I mean by "human readable" name uniqueness; it is the sum of its context, type, name and part number. For a non-Professional user this is My Account+Document Folder Path+Document Name+Element Tab Name+(if a Part Studio:Part/Surface/Curve). For professional and enterprise users one or more additional context levels probably exist.      

I see your point, sometimes as an intermediate step, it might be convenient to allow elements with duplicate names. But this should be a short lived condition which is quickly corrected before any confusion can result.

The main point of this post was to get better understanding of why Onshape decided not to concern itself with possible end-user confusion when duplicate named elements exist.  Therefore, as I said and confirmed by @lougallo, OS doesn't concern itself with human readable uniqueness (it is not its job). However, it should be pointed out this laissez faire view changes somewhat when Release Management is activated: part number attribute uniqueness is enforced.

Now that I know OS doesn't worry about name uniqueness I will just have to be more mindful of the possibility, that within the same context, multiple element tabs, and parts in the same Part Studio might have the same name.

At least you provided a couple reasons why the ability to duplicate "human readable" element names are sometimes helpful.

  

S1mon

Related to these issues, I have created an IR to help track down which document a part/subassembly is coming from.