Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Options
How to deal with projects
shawn_crocker
Member, OS Professional Posts: 818 PRO
What do you do with projects after the project is complete? I am starting to explore different way we can make use of this feature that is new to us. As the project get created and loaded into the root, I am foreseeing after a short duration, the enterprise root directory becoming very busy and hard to navigate. Do people usually break the project after completion and load the documents into other folder locations?
Tagged:
1
Answers
Enterprise
Website: ovyl.io
I want to vote for your ask for an archive option. It feels like we are expected to absorb the docs into a folder structure archiving layout after the project is complete.
In the beginning of OS we were told that a version of a document was immutable but that's changed with configurations. Then, the idea of releasing all and publishing would make an immutable state of a project. I've never done this and not sure what it produces.
I'm still wondering if you put all project documents into a folder and changed the permissions to view only, would this work? Ultimately, you could build new projects from released assemblies and cut design time down. Seems like released assemblies need to be in their own folders so you can manage access but what happens to all the linked part studios and assemblies? Could this be one folder called "archive" and you move assemblies in/out of it. What about the supporting part studios and sub-assemblies? In the very beginning of OS, they didn't want folders but the file based folks kept asking for them. I'm not sure how they should be used.
The current project I'm working on will need to track what gets shipped to each company because it's going to be unlikely that every customer wants a standard release? How do I build that project that tracks what gets shipped to a customer? And then, the customer wants an upgrade in the future? How do I add this to a project's structure? Is this a customer centric project structure?
The immutable state seems to be elusive and constantly changing in OS. Please let us know what you figure out.
Not sure what I'm missing.
Thanks,
Projects is too much to setup for my little company and I'll be happy to set teams up correctly.
Cloud hell is controlled by permissions and not file management. It's a different way of thinking. I'm not sure there is a solution yet. @S1mon created a project using release & publishing which seemed to solve the issue with immutability. I'd start there.
How do you control who has permissions? Projects, teams, folders, documents, assemblies, part studios or parts?
Currently my project is one document, I have very few assemblies and I have a ton of vendor parts that I want to control in a library.
I'm currently building rigid part studios unless there are moving parts or I need to replicate parts. 50% of the time I need an assembly to represent something mainly due to replication. Only one of my components has moving items which is an assembly but I want the bom to only have one part/number, the one I order. Often I start out with a rigid part studio in a higher assembly and then I have to replicate something, this forces me to create an assembly, insert the assembly, then delete the rigid part studio. I should probably also use an assembly. In other words, never insert a rigid part studio into an assembly.
What's the definition of an assembly? Why do you use one? This is an age old conundrum.
At the end of the project, I know I have to track what gets shipped to each customer and I have to be able to track installed changes made to older systems. I won't have an archive, just a timestamp.
And oh yeah, the project structure has to be written down so all engineers abide by the rules of the project. Everyone has to agree on a project structure.
I know this thread started off with a simple concept called "achieve" but it's a deeper problem.
The last thing anyone wants to do is to create order to a project that was built with chaos.
There's a few papers on this subject in this forum and planning ahead is also one of the tenet of a project.
I appreciate you taking the time. I'll give it some thought.
@_anton of course I didn't know this...
I'm helping some friends build a product and the project is at the ground floor. I have never been one for letting engineers do what ever they want and I lock things down from the beginning. I've never had anyone quit on me and the efficiency of the team sometimes surprises me.
There's a lot of things I want out of the project and I'm formulating my ideas. Currently I have the BOMs working correctly, but you have to develop rules on how you import vendor supplied geometries.
Currently in my BOMs I use:
-parts
-composite parts (mostly)
-assemblies (may become a standard for everything)
Someone turned me on to a shrink-wrap FS written by Neil which could replace composite parts. I'd still have parts, composite parts & assemblies, but it would generate a different flavor of a part vs. composite part. I'm still not sure what to do.
With vendor assemblies that move, you have to hide the parts from the BOM. In a flatten BOM style, you don't see the assembly. In a structured BOM I get the motion, replication and the vendors part number which I want. I don't want an assy P/N & a part P/N to ever show up period! This means I always have to use a structured BOM which is fine as long as everyone knows this is how the project is structured.
Honestly, this is the 1st time I've had a CAD system create an accurate BOM. I've always used a spreadsheet in the past which is horrible.
My friend's company is using Katana and I know I can talk to it with a rest API. In a couple of years we should be able to buy the correct parts and plan production builds.
I'm still struggling with the immutable state. I haven't tried releasing things yet but will soon. @S1mon said he was able to create an immutable state by publishing released items. This is what I'm planning to do by creating timestamps of the project by releasing & publishing. The project will never end as long as customers keep buying products. I don't ever plan to archive the project.
As far as selecting who can do what, cloud based systems have infinite control over a data. This isn't a hard drive with folders and a crappy permission structure. I use linux and even it's hard to perform/refine the permissions, typically I only have one public folder. Currently in my little company, I'm sharing view only with everyone who's not an engineer. I haven't setup teams yet but will soon when I need to control access by groups of users.
I'm excited about this little project. I think Onshape can do it.