Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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

Publication History?

eric_pestyeric_pesty Member Posts: 1,523 PRO
So I haven't used publications much and I understand the point is to have a "single source of truth" so it makes sense that it wouldn't have actual "versions" in it, however I expected to have a history tree so that you would be able to tell what happened and when.

My usecase here is that I had created a publication for "revA" set of drawings and parts to send to a vendor for feedback. I then went back and updated to "in progress" versions of the project, including removing some tabs etc, but I realize there is now no way to know what "used to be" in the publication so I can't check if I ever sent them a specific drawing/part etc...

Am I the only one suprised not to have the change history available in a publication?

Comments

  • Options
    martin_kopplowmartin_kopplow Member Posts: 281 ✭✭✭
    No, you aren't. I have asked myself the same question recently.
  • Options
    romeograhamromeograham Member, csevp Posts: 657 PRO
    I agree - this seems like an oversight to me as well. I think one approach could be to have a unique Publication for every "release"...which I don't like. You can still use the "Revision History" on each item / tab in the publication (if they have been released). I know that isn't what you asked!
  • Options
    NeilCookeNeilCooke Moderator, Onshape Employees Posts: 5,412
    One of the problems Publications are trying solve is the end users' access to the Version graph. With regular Document sharing, a supplier can navigate through versions and workspaces and make the wrong thing.
    Senior Director, Technical Services, EMEAI
  • Options
    eric_pestyeric_pesty Member Posts: 1,523 PRO
    NeilCooke said:
    One of the problems Publications are trying solve is the end users' access to the Version graph. With regular Document sharing, a supplier can navigate through versions and workspaces and make the wrong thing.
    That part makes sense, but the publication's own version graph is different. You probably don't want the recipient to be able to use anything except the "latest", however the author of a publication should still have access to the history of the publication itself, if anything for auditing purpose.
    For example what if the publication used to have revA of a drawing and gets updated to use revB instead, now anyone looking at it can't even know that something is changed, which could be very confusing. Also if the recipient's process involves exporting a STEP file, they might have grabbed it when the publication showed revA and could end up making the wrong thing! Without history this is worse than emailing the STEP file (as this would at least leave a trail)...
    As it is currently anyone who has write access can modify a publication with no accountability or traceability so that seems like a potentially serious issue.

    There are a few ways this could be handled:
    - Maybe the publication's history is not accessible to anyone that doesn't have write access to the publication
    - or you cannot enable any exporting, measuring, etc of anything except the "workspace" of the publication
    - of maybe even anything from the history can only be displayed as a "ghost"
    - Maybe a publication need to undergo a "workflow" process so that you can't just "update" it without checks


    I guess in the meantime, the only "safe" way to use publications seems to be to not update them after the link has been shared (i.e. create a new one for each "version").
  • Options
    shawn_crockershawn_crocker Member, OS Professional Posts: 814 PRO
    Ya I don't like that there isn't a version graph either. It's a wierd departure from the system norm.  If I delete a bunch of tabs and then realize I needed them, I can't get them back. When I use publications all I can think about really is how disappointingly simplistic they are. And how time consuming they are to simply drop in a few drawings and assemblies. And above all else, simulation results are not available to be explored when the publication has been link shared! Publications in my opinion should be publications. A document that you create to publicize something in a way most people expect. Like creating views of an item, creating exploded views, hiding and showing things. Basically creating a document that allows really digging into an item without modifying the actual item. All these customizations would be held within the publication only. And you could version it to track changes like everywhere else in the system rather than duplicating.
  • Options
    Urs_Egger_REACTUrs_Egger_REACT Member Posts: 59 PRO
    I don't like the publications approach at all. It is a copy of a version of a collection of document tabs. It is a similar approach as creating step and pdf files. 
    Most of my external partners understand step and pdf but they don't understand publications. 

    I'd rather share the original version of a part or drawing. So in this case I would send a message as e.g. "please send me a quotation for part xyz rev A and attacht the link to that specific part and drawing revision. Unfortunately that's not possible. 


Sign In or Register to comment.