Wow, that's a weird one! So you have someone deliberately
circumventing the checkout process? Not nice.
I tested this for myself using RSC. First of all, let me tell
you that the "Set Read/Write" box never went away. Here's how the
rest of the testing went:
<Scenario One, with no restrictions on local checkouts>
1. User A checked out a file legitimately and made edits.
2. User B did a "get" of the same file, checking the Set
Read/Write box.
3. User B then attempted to check out the file from RSC. This
failed with a message saying that the file could not be multiply
checked out.
4. User B, being persistent, then tried to do a local
checkout. This was successful. User B was then able to edit the
topic.
5. User B checked in his file.
6. User A checked in his file.
7. Results were different in two separate tests. In one
instance, I got a dialog for resolving the differences between the
two checkouts. In another instance, both changes were simply
integrated into the file. Not sure what caused the difference.
**************************
<Scenario Two, with local checkout permission removed>
1. User A checked out a file legitimately and made edits.
2. User B did a "get" of the same file, checking the Set
Read/Write box.
3. User B then attempted to check out the file from RSC. This
failed with "...cannot be multiply checked out."
4. User B tried to do a local checkout. RSC denied the
request with the message "Error - you have insufficient rights to
perform this operation."
5. User A checked in his file normally.
*******************
Admittedly, this was a quick-and-dirty test, but it would
suggest that if you removed Local Checkout rights, that it would
stop the end-run around multiple checkout restrictions.
HTH,
G