Reputation: 576
I am new to Perforce. There seems to be a a misconfiguration in our current Server, as anybody can change anyone else's workspace options.
Does anyone know how to quickly fix that problem ?
Thanks,
Thomas
Upvotes: 1
Views: 659
Reputation: 576
Locking the workspace is the way to go, thanks Heath.
I have worked on a small PERL script to lock all existing workspaces:
#*******************************************************************************
# Module: LockClients.pl
# Purpose: A perl script using the CLI to lock all clients on a server
#
# Debug Flag:
$DEBUG_FLAG = 1 ; # 1 for TRUE, 0 for FALSE
# Get the list of clients on the server:
@list = `p4 clients`;
foreach $client (@list) {
# Get client name:
$clientname = (split / /,$client)[1];
if ( $DEBUG_FLAG ) { print ("Client name: $clientname \n"); }
# Prepare temporary file name (will contain the new config spec of the client):
$filename = sprintf("tmp_%s.txt",$clientname);
if ( $DEBUG_FLAG ) { print ("Temporary file: $filename \n"); }
# Get client spec:
@clientspec = `p4 client -o $clientname`;
# Write client spec to file:
open (VIRTUAL , ">$filename" ) || die "ERROR: Could not create $filename \n";
foreach $line (@clientspec) {
if ($line =~ m/^Options:.*$/m){
if ( $DEBUG_FLAG ) { print ("Line before substitution: $line"); }
$line =~ s/unlocked/locked/;
if ( $DEBUG_FLAG ) { print ("Line after substitution: $line"); }
}
print VIRTUAL $line;
}
close (VIRTUAL);
# Import new config spec in client:
`p4 client -i -f < $filename`;
if ( $DEBUG_FLAG ) { print ("Workspace $clientname locked !\n\n"); }
}
exit 0;
I will now work to try to enforce the lock option with a trigger after a workspace is created or edited. :)
Thomas
Upvotes: 0
Reputation: 701
If you set the 'locked' option in the workspace, then the workspace can only be modified by its owner (or by a user with 'admin' or higher access level). It'll also prevent other users from using or deleting that workspace.
Upvotes: 5
Reputation: 5739
Not a direct fix, but you can track changes made to client specs by implementing a "Spec Depot". See KB article here.
I must admit prior to reading your question I did not even realise you could modify another user's client spec without admin rights. In the 9 years of using Perforce I have never come across that as being an actual problem for people.
cjhuitt's suggestion of prefixing a client spec with user name/initials is a good one, and is pretty common practice, particularly in larger installations.
Upvotes: 2
Reputation: 14941
I don't know of a way to easily or quickly fix the problem.
Having said that, is the ability being there really a problem? Or is it that different people think they have ownership of different workspace configurations? Here where I work, we prefix the username to any workspace that we want to maintain as our own, and leave it off of shared workspaces (or use a different prefix, at times).
If it is a situation where the ownership of a workspace is unclear and that is causing issues, this would resolve your problems. If it is a situation where coworkers are ignoring the ownership and intentionally making changes, you likely have other problems to worry about.
Upvotes: 4