Previous Entry Share Next Entry
Release 0.4.1.2: Who Can Edit Children
querki
jducoeur wrote in querki_project
I've mostly spent the past week or so on non-feature work: adding unit tests, fixing a bunch of bugs that I had noticed by code inspection, and dealing with legal matters. Today, I went to send out the next couple of invites for Alpha users, and hit a sudden roadblock, as I realized that Querki's current definition of the Who Can Edit Property was a big fail.

The idea was elegant and clever. The permissions for a Thing come from four sources, in order:

-- If a permission is defined on the Thing itself, use that.
-- Otherwise, if the permission is defined on its Model, use that.
-- Otherwise, if the permission is defined on its Space, use that.
-- Otherwise, use a sensible default.

That all seemed to work fine, and indeed, I think in practice is usually correct for the Who Can Read permission. (And Who Can Create, although that's a bit weirder.) But I suddenly realized this morning, as I went to create the Alpha Sandbox Space, that it totally fails to do what I need for Who Can Edit. I want the root page of that Space to be well-controlled (that is, only I can edit it), but the Space is otherwise a free-for-all. The correct way to do that was to set Who Can Edit to Members on the Space -- but then, everyone can edit the Space itself!

Basically, I was overusing inheritance, and conflating "who can edit *me*" with "who can edit my children". After thinking that through, I don't think there's any good way around the fact that those are very different concepts, and are *often* going to want to be different. In particular, I believe it's going to be terribly normal to want to allow Members to edit *instances* of Foo, but not the Model Foo.

So today was all about rewriting the edit permission, to split apart Who Can Edit from Who Can Edit Children. This is a breaking change -- please point out to me if there are Spaces where you could previously edit things and can't any more, because they probably need tweaking for this. In future, Who Can Edit Children is typically going to be the permission you want to reach for.

(Note that, when applied to a Model, "children" means descendants, whereas for a Space it means the constituent Things.)

On the plus side, I'm keeping up the discipline of unit tests -- a side-effect of this change (and indeed, what took the bulk of the day) was writing a collection of unit tests for the edit permissions. This mostly consisted of introducing new test-harness concepts of users and members and such, which should pay off in making it easier to keep adding to the test suite.


TOMORROW: with any luck at all, set up that Sandbox I was going to build today, issue invites to several more people to join, and dive into Editor improvements...
Tags:

  • 1
(Deleted comment)
Have commented on a couple of your pages. Good observations and thoughts -- please ask questions whenever desired...

(Deleted comment)
That's fine. In the medium term (possibly within the next week or two), I probably need to create a Space specifically for issue tracking, but this makes a good start...

Thanks, I used this to report a few of the things I ran into right away before I forgot them.

  • 1
?

Log in

No account? Create an account