James Mason wrote:
Yes, that's exactly the problem. I noticed this and thought it was odd, so I removed the inherited field on the custom GUI client I'm writing if the inheritedFrom maches the current uri. That's why my custom client was working correctly but the slide command line client was not. I had forgotten I implemented that workaround.
Guido Casper wrote:
Carlos Villegas wrote:
James Mason wrote:
There seems to be some bug on writing ACLs through the command line client. But I think it's a different issue. Sometimes all the non-inherited ACEs are deleted when I issue a grant command and afterwards only the one granted remains.
Which version of the client and server are you using? There was a bug in the server that could cause this, but it should be squashed in the latest release (2.1b1).
2.0. I'll upgrade during the following days and I'll report whether the issue is still there.
Hmm, isn't this the way supposed to be (on the server)? You always have to specify all your ACEs. If you want to add an ACE you have to read the ACL, add the ACE and submit the new complete ACL. So this shouldn't really be an issue on the server?
The problem was the inherritedFrom field on an ace was being set to the uri of the object. This would confuse the client (and maybe the server) since if that property is set it assumes that the ace can't be changed/removed (since it's inheritted). You end up in a situation where you add an ace and any old aces get ignored during the proppath (since they're "inherrited") and the acl ends up containing only the last ace you added.
-James
I assume this is now fixed in the latest release and I don't need my workaround anymore.
Carlos
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
