Upload Modified but Non-checkout Object

[jfoo]

Allow upload of modified but not check-out object to server-side workspace. The user might have changed the object without check-out for many reasons, eg: by accident, for trying out alternative design, etc. Currently, only new or check-out object can be uploaded to the server-side workspace and it is quite puzzling why modified non-checkout object is not able to upload.

The server-side workspace serves a few purposes:

1) As a "backup" of users work in case if the client machines has crashes

2) Allow user to goes to another machine and able to download his work to another machines without exporting to a external drive and carry

It seems like the "blocking" of uploading the modified and not-checkout object goes against the use of server-side workspace

[dnordin]

This would result in the server side WS and the local cache always being in sync (with some exceptions - like working offline.)  There are also some indirect benefits to this concept as well.  For example, if admins are granted access to the users server side WS's, they're better able to support the users without having to connect to the users machine that hosts the local cache.

[FrankMenendez]

Just some quick thoughts from my perspective. The key element here is the ability to save all work - with emphasis on all. If I modify something - I performed work. It is a simple fact that all work does include a subset of objects whereby the user wants to modify the object but not certain if such modification should be done using checkout - the reasons behind those decisions are many and vast. The reason can range from not having write access to the context, or the object is at a released/similar state and revise does involve a "committment", to not having ownership for checkout, to particpating on a team and refraining from "locking" out other users from checking out the same object - especially when those users may have "ownership." Many times, the process of proposing a change involves modifying the CAD objects first. In some organizations, a released object in the PLM system cannot be revised without an approved change - so now you need to propose it before it can even be revised. The capability of being able to upload the modified object to the secure server-side workspace and SHARE it with the reviewers/approvers on a change request would be VERY beneficial as well. It would prevent having to undo revisions attached to rejected changes (for some companies) and ensure that latest versions of obects in the system are either released or are being changed based on an approved change request - making some company's lives easier when trying to get an accurate CAD structure in the workspace to work on. Keep in mind that REUSE is a function within the REVISE capability - so the work would not have to be redone when approved - just leveraged during the revise process.

In short - the downstream potential value for this capability is potentially significant - which requires consideration of potential business use cases when planning and implementing. For example, I see "workarounds" today that would be made obsolete with this capability. A welcome change.

[J.P.Vanasse]

This is an easy "up", yes, vote.  From a data preservation standpoint alone, this capability would be worth having.  Few users have their local cache backed up nightly and most users have suffered some type of local Workspace issue.  Coupling the upload with controlled sharing will create powerful new functionality that preserves worked completed for proposals and what-if studies.

[SteveShaw]

If i had a vote I would vote this one UP as well.  In fact we are working on this problem today and hope to have something available in the next release of Windchill.  Being able to upload all cache content to the server-side workspace would provide many benefits:

1. Workspace backup (client disaster recovery, improved support for upgrades to new Windchill releases)
2. User mobility.  allowing users to access their WIP data from any machine at anytime (think of it as iCloud or Dropbox for the CAD user)
3. Provide workspace Save-As support for locally modified but not checked out data.  Allowing for users to more easily perform their "what-if" design investigations within their workspace.

The other thing we are thinking about is providing advanced warning/notice conflicts that might exist in your workspace.  During upload we could check for filename conflicts, attribute constraint conflicts, and other issues, allowing the upload to continue but providing status info in the workspace that these problems will need to be resolved prior to check-in.

All in all this feature should provide a much improved user experience for the CAD user, as well as provide an opportunity for future capabilities.

If this is important to you and your user base I'd like to hear from you.  Please add your comments.

[AllanThompson]

A better warning/notification system would be great.  A problem that many of our customers find is that users don't notice the tiny little red icon that appears in the status bar in Creo.

As for the upload option, is there any chance that this would make it into current released on Windchill (10.0/10.1)?

[DaveNelson]

I agree the concept of an option to have all local workspace content 'auto-uploaded' to the server would be useful.  It would solve a particular technical issue for us as we explore virtualized engineering workstation sessions for Pro/E (via Citrix) where a user would get one virtual session (system) one time, and a different one the next, losing access to any non-uploaded work.

[jfrankovich]

I'm most interested in this capability in terms of data security, portability, and WGM simplification. Currently we backup a user's workspace daily on ProE launch, so if we do have a ws corruption, we hopefully can roll back 1 or 2 days and not loose too much. In addition, local and server sync would aid user management of workspaces. It does take time for some users to truly understand the limitations of a local and server side WS.

[ocorten-2]

Another great thing about this functionality is that it will potentially allow us to do Save As in WS on Modified Objects.

Use case:

1. A users downloads an assembly and starts redesigning it, trying different ideas with the intention to implement the final idea as new revisions of the models later on.
2. But after working some time the user decides that the changes are too big and not downwards compatible and he really needs to create new models (with new numbers)
3. Preferebly you want the user now to use the WS Save As functionality because it will take all external relationships of the modified models into account and would also allow him to save-as using wildcards. But currently you cannot do a WS Save-As on modified objects. This is disabled in WC because currently those models don't exist in CommonSpace and can therefor not be copied to new models.
4. So he has to go into ProE/Creo and rename the modified models there (if you've got that enabled through the config option let_proe_rename_pdm_objects). But at his point no checks will be done on all the parametric relationships to other models.

Combined with all the other advantages I'm all for this functionality.

[GregoryPERASSO]

it should be possible when the "upload to workspace non-checkouted objects" will be released ... in X-24 ...?

[BillRyan]

I vote this up because it eliminates confusion.  The roadblock I anticipate is the management of the "marked as modified, but untouched" objects in the workspace.  The companies using family tables will understand this one...   

[ptc-4646096]

I vote yes!

[KEVINJOHNSON]

"save as" to modified objects is one intralink functionality that we relied on daily as a mode of operation and causes the biggest work stoppage since moving to windchill 9.1

[ChrisPLM]

Hi

I justed voted up. I think this is a great idea and if wtdocuments are one day also added to the workspace this should also benefit this new features.

Let's the system manage everything and not have data outside (on local cache or drive) the system

[SteveShaw]

If you are attending PTC Live Global 2013 in Anhaheim, CA to learn more attend the CAD Data Management Roadmap presentation @ 11:15 am Tuesday June 11th.

[SteveShaw]

In case you missed PTC Live Global this year....

http://communities.ptc.com/videos/4104

[STEVEG]

I agree with this. However, I believe there is one aspect that is not addressed...unless I missed it in any of the comments.

What happens with this use case?  Say I modify an object that is not checked out.  Before I check it out to check it in someone else checks it out, makes their changes and checks it back in.  Will that advanced notification be a part of this?  Could it notify other users that someone has made changes but has not checked it out?  Another way?

[SteveShaw]

This upload support does not address this scenario. This same scenario exists today without upload support.  Of course, you would get the status update indicating that someone else has the item checked out, if they check it back in you would then get a status update indicating that the version that you are currently working with is out of date.

[STEVEG]

And I don't like the current scenario.  I may not look at my workspace while I am designing.  It might take me 10 minute or it might take me 5 hours depending on what needs to be done.  Other users need to be notified in some way.

[SteveShaw]

Fair enough. My only point was that the use case you have outlined was not the intention of this particular project.

[STEVEG]

Thank you Stephen.  I appreciate the responses.

I'm just curious why this wouldn't affect this project.  If uploading non-checked out files is allowed then I believe others should be notified.

[jfrankovich]

Stephen,

It doesn't sound like the design scenario you are proposing is for "experimental" or "what if" designs. It sounds like this is for standard active work. Is that correct? If that is the case, then couldn't multiple people be modifying the same file simultaneously with the anticipation that they can just check it out later?

[STEVEG]

It could be for anything.  If I change something and have not checked it out then I want others to know I have changed something.

I.e.: Say I work on an assembly all day (8 or 10 hours).  I need to make a change to a part model I originally didn't think I needed to.  But I forgot to check it out.  I am making some fairly major changes.  I am not looking at my workspace while designing.  In the meantime someone else checks the file out and works on it for half a day.  They also made some faily major changes. Then they check the files in.  At the end of my day I try to check my file in but see it is out of date.  This could be for standard active work or for experimental/what if's. 

If it were experimental I may decided that yes, I need to keep these changes.  We have both these situations at the place I work at.

We have been lucky enough that it has not affected us yet.  But we have been growing quite a bit lately and it may happen in the near future.

[ChrisPLM]

Hi

it look to me for a business process issue rather than a software issue. If my team was coming to see me and complaining that 3 of them work without communication on the same file making modification locally and then complain about the conflict this creates, I would not be able at all and be reviewing how my team works.

People should working on files because they have a task assigned to them. Therefore they could simply check out the object. Checking out an object does not affect, does not affect the latest released version etc.... 

I may underestimate your issue but from what I read, my first approach will be improving your data management practices and your process.

[STEVEG]

Then get rid of the check out notification.  From what you said it's not needed.

[jfrankovich]

Back in the Intralink 3.x days, everything in a workspace had to be checked out to somebody even if there was no intention to modify a file, so users were often forced to communicate in order to get the checkout permission to the user who was actually making a change.

PDMLink brought greater freedom, but greater responsibility to the user. We recommend that users Check Out only the files that they expect to change and Lock all of the rest. Then, if they realize that additional files need to be intentionally changed, they can Unlock those files and Check them out as needed.

Now a scenario like yours could still arise because somebody didn't checkout a file when they should have, but now it isn't just a case of getting busy or caught up in their work. They didn't follow the process. They stopped to unlock the file but didn't bother to check it out like they knew they should.

And as far as the Check Out notification, it is absolutely needed. Let's say a user checks out a file as part of a project, anticipating or knowing that the file needs to change, but as this project is progressing, a manufacturing request requires a different user to immediately modify the file. The check out notification will provide the means for these to users to communicate and work out how their respective changes will be implemented.