We need to update some data Inside our vault, during working hours, but we want to prevent our users to open them with solidworks or explorer (even read only without checking them out) while retaining access for administrators to modify those files.
We have around 100 users in different offices so it is difficult to simply tell them to stay out and monitor their compliance.
Any idea or a best practice vailable somewhere?
I thought about borrowing licenses and close the license server, but on pdm side it does not seem feasible.
Another question (outside the scope of the previous one)
I looked for some resources about working offline with the local vault and stumped upon this:
https://www.javelin-tech.com/blog/2018/ ... g-offline/
I am a little concerned a var would suggest to mess with read only flags and copy the data outside the vault...
Iirrc there was a very brief guide in the KB and it was telling basically the opposite (keep files you want to modify checked out)
Vault maintenance best practices?
Vault maintenance best practices?
I don't understand why it would matter if a user has files that are not checked out open. Once the machine has files cached locally I don't know that you can prevent them from opening those files.
What you can do is block logins from the Admin tool. Hopefully you have an "All users" group. Just remove your admins from that group if they are in there and check the "refuse login" box.
Now, back to preventing them from reading files. The above will block login, but users could still use work offline mode and access the files. You could narrow that down by going to Cache Options for that group and on the root folder select "Clear cache during log out" But you'll need them to all log out for that to happen. Can you get everyone to log out of windows or shut down computers?
Also, what about users with files checked out? Blocking check out from user/group is not easy as it's a permission granted, not revoked. I think it simpler to go to the workflow where hopefully there's only a couple of states where checkout is allowed. Temporarily uncheck that permission in the workflow state, will need to re enable it once everything is checked in and users are all blocked out so the admins can check out files.
The more I look at this the more I wonder what operation requires this?
Re: Vault maintenance best practices?
If you're modifying them as an Admin within the vault, then just check them all out. That way, nobody else can do anything with them until you're done. Of course, I may be missing something so it would help if you could elaborate on "update some data" and what that requires.
Re: Vault maintenance best practices?
I don't understand why it would matter if a user has files that are not checked out open. Once the machine has files cached locally I don't know that you can prevent them from opening those files.
What you can do is block logins from the Admin tool. Hopefully you have an "All users" group. Just remove your admins from that group if they are in there and check the "refuse login" box.
Now, back to preventing them from reading files. The above will block login, but users could still use work offline mode and access the files. You could narrow that down by going to Cache Options for that group and on the root folder select "Clear cache during log out" But you'll need them to all log out for that to happen. Can you get everyone to log out of windows or shut down computers?
Also, what about users with files checked out? Blocking check out from user/group is not easy as it's a permission granted, not revoked. I think it simpler to go to the workflow where hopefully there's only a couple of states where checkout is allowed. Temporarily uncheck that permission in the workflow state, will need to re enable it once everything is checked in and users are all blocked out so the admins can check out files.
The more I look at this the more I wonder what operation requires this?
Re: Vault maintenance best practices?
@bnemec we had one big problem with local caches and read only files that was simply opened. I try to describe it below.
if you move or rename a checked in file (in case of checked out PARENTS there is a warnIng preventing so) while opened inside solidworks by someone logged in the pdm vault, that user gets a popup that he usually ignores.
The popup tells him to close SW: the reason is the moved-renamed data are locked in the local vault cache by SW and cannot be renamed or moved on the fly in a new location. we had lot of cases of such warning ignored: the local file copy of the moved-renamed file became preferentially loaded instead the correct one,even latest version was useless until the local cache was cleared of local data.
we had an engineer that while its assembly files were moved in another location had them opened, apparently he was not in front of the pc, when he came back the popup warning was long gone and he did not notice the small warning at the bottom of the task panel. then he check out the assy and made a whole 2d drawing of an assy full of local data instead of the correct vault copies. when another user opened the drawing all the references blown up.
if you move or rename a checked in file (in case of checked out PARENTS there is a warnIng preventing so) while opened inside solidworks by someone logged in the pdm vault, that user gets a popup that he usually ignores.
The popup tells him to close SW: the reason is the moved-renamed data are locked in the local vault cache by SW and cannot be renamed or moved on the fly in a new location. we had lot of cases of such warning ignored: the local file copy of the moved-renamed file became preferentially loaded instead the correct one,even latest version was useless until the local cache was cleared of local data.
we had an engineer that while its assembly files were moved in another location had them opened, apparently he was not in front of the pc, when he came back the popup warning was long gone and he did not notice the small warning at the bottom of the task panel. then he check out the assy and made a whole 2d drawing of an assy full of local data instead of the correct vault copies. when another user opened the drawing all the references blown up.
Re: Vault maintenance best practices?
I forgot there is an explicit refuse login option inside user group rights!
thank you very much.
thank you very much.
Re: Vault maintenance best practices?
In the end is an half an hour operation, i have to batch rename some 100 catalog part files with a dispatch, but I need to be sure that no one is reading them otherwise the problem described above could bite us again.
usually for server maintenance we ask all users to check in all the files and shutdown the vault. we often end up with 3-4 files kept checked out that we force back to check in if needed.
this time we need to be able to log in inside the vault while preventing other "accidental" user logins until the operation is finished.
usually for server maintenance we ask all users to check in all the files and shutdown the vault. we often end up with 3-4 files kept checked out that we force back to check in if needed.
this time we need to be able to log in inside the vault while preventing other "accidental" user logins until the operation is finished.