Is our revprop auth policy too strict?

Back when we introduced the idea of authorization policies for revision
metadata, we designed things such that a given user could have "full",
"partial", or "no" access to a given revision's metadata. The determination
of these access levels is based entirely on the paths affected as part of
the revision:

   * "full" access is granted when there is no such path the user
     can't read.

   * "no" access is granted when there is no such path the user
     can read.

   * "partial" access is granted when there's at least one path
     the user can read, and at least one he can't.

How do these policies affect what the user sees?

Well, in all cases, the user only gets to see the paths he can read. But
the policy affects revision properties, too. "No" access, no properties.
"Full" access, all properties. "Partial" is the oddball -- you only get to
see the svn:author and svn:date properties (because the log message and
custom properties might contain text that mentions the priveleged paths).

I think those are all quite fine as policies go, and I'm not proposing a
lick of change there. (If others wish to do so, please use a different thread.)

But I noticed the other day that when it comes to *write* access for
revision properties, "full" and "no" access do what you'd expect, but
"partial" is treated just like "no" access -- in other words, the user can
read svn:author and svn:date, but can't change them. That seemed odd to me
(and to sussman, when I raise the question elsewhere).

Is there a compelling reason to prevent a partial-access-granted user from
changing the two properties he's allowed to see?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand