Bert Huijben wrote:
> Following editor v2 (and v1), deletion of a child is changing the
> list of children in the parent directory and as such requires (at
> least) write access to the parent.
The editors don't control authorization. The parent path may be
mentioned in an editor call, but that doesn't necessarily mean the
repository authorization code has to require authorization for that
> What happens if paths to within multiple repositories are passed
> to the function? Was/is this supported?
Yes, it's supported: delete_urls_multi_repos() calls
single_repos_delete() once for each group of targets that are in the
> Should the delete be handled atomically or not?
> (Atomic deletion requires rooting at a common parent)
A delete of targets in one repository should be (and is) atomic, using
From the point of view of driving a commit editor, yes we must root
the edit at a single common parent directory. But this makes me
wonder, is the problem in fact lower down? Like I said above, just
because the edit is rooted at a directory doesn't mean the repository
should require read authorization for that directory, if the edit does
not actually touch that path.
I'm now thinking the bug is in RA-neon or lower down.
> Julian Foad wrote:
>> I went looking at the Book and found nothing about what access
>> is required for a delete. That's an omission we should remedy.
>> What is the correct authorization requirement for deleting a
>> node? Read-write required on the node's parent directory and on
>> the node itself? Only on its parent? Only on the node itself?
>> Read access on the parent and read-write on the node?
Received on 2012-08-16 20:50:33 CEST