setting-ize permissions+discussion
hoping this fixes permissions changing themselves
Migration is going to result in a *huge* number of edits on any decent-sized Wagn, some of which will expose errors. Probably good to give a big heads-up on this with lead-time for Wagn-owners, so that they know it's an opportunity to review permissions on their site and set things right.
--John Abbe.....Mon May 10 15:19:23 -0700 2010
edits will only be huge on sites with irregular permissions settings, otherwise all of the permissions on the site will be represented by comparatively few cards. in any case, reviewing and fixing permissions will be far far easier after the migration -- that's part of the point.
--Ethan McCutchen.....Mon May 10 15:40:08 -0700 2010
oh, right! we'll be able to use WQL to show all the cards editable by a particular role, etc. Waaay cool...
--John Abbe.....Mon May 10 16:13:11 -0700 2010
yes, though in some wagns you'll just want to go into the *create, *update cards, etc. Very quick summary view of the permissions of the whole site.
--Ethan McCutchen.....Mon May 10 16:24:35 -0700 2010
This will satisfy some of my urge for color coding cards (e.g., based on permissions), though that would still be good for that among other uses.
--John Abbe.....Mon May 10 18:27:06 -0700 2010
The number of tickets getting closed because they'll be handled by this ticket is yet another indication of how awesome this ticket -- and settings in general -- are. W00t!
--John Abbe.....Wed May 12 19:48:41 -0700 2010
On add Author role you suggested we'd handle the use cases for that via syntax. I'm struggling to imagine what you meant?
--John Abbe.....Mon Nov 22 09:51:56 -0800 2010
On *plusses and *stars:
Foo+*plusses would be the set of all cards Foo+ ? So that a *plusses setting on the _left part of a card is a setting on that card ?
Or it could be all cards with a plus, (or both '*plusses' is one set like *all, and +*plusses is a pattern). I guess *stars could work the same way, but just limit to tags beginning with * ?
Would we have a way of referring to the negation of these sets as well?
--Gerry (Not signed in).....Thu Dec 09 13:14:45 -0800 2010
*plusses is just all the plus cards. foo+*plusses already has another meaning. We need this set to be able to make sure all plus cards, by default, inherit from _left.
--Ethan McCutchen.....Thu Dec 09 13:38:58 -0800 2010
I want to comment on the id of a separate "owner" concept (somewhat related to add Author role). The notion there would be that a card would be set up so that a give permission (read, edit, delete) could be assigned to an owner. This would differ from the creator, in that the owner could change. This has been accompanied by the suggestion that there be an "owner_id" in the cards table.
With the system outlined above, we would be able to set up cards in patterned ways so the creator has a given permission, and we would be able to override that permission with a more narrow set that gives that permission to a different individual. So I don't think the distinction is in any given pattern of permissions that we might be able to represent. However, there may be an interface level argument for simplifying changing the owner versus changing the permission to point to a new person. If so, feel free to make it. I don't see it yet.
I do see an argument against simply adding an owner_id and then adding new interface to change it. This adds a whole lot of newness and uncardiness to support. There'd have to be custom interface, custom model and controller handling, custom permissions, custom WQL, etc.
Now, we could get around many of those if, say, we made a "+*owner" and just used owner_id as an optimization. If we decide to add the owner, I'd probably want to do something like this.
But it still seems like a lot of work for not a huge return. Can anyone make the case for the owner stuff?
--Ethan McCutchen.....Tue Dec 14 12:24:51 -0800 2010
I take it you are talking about adding _owner which is used like _creator. What about making *owner a setting, then there is no new interface needed. Values would be just like the *CRUD permission settings, but would be the other side of the permission validation (i.e. if any item in the *owner setting can Create(RUD) then Create(RUD) is allowd),
--Gerry Gleason.....Thu Feb 24 10:37:27 -0800 2011
I would think that would complicate the reader_key generation somewhat, no?
--Ethan McCutchen.....Thu Feb 24 11:06:22 -0800 2011
Ethan: John, I know you're going to say "Group" is too common of a name to grab. I resent that, because it's true. Let's talk.
I think this is the use I wanted to reserve "Group" for, as long as it's the canonical way to identify collections of, hrm, people. (The hrm is I guess that's the union of User cards and cards with accounts.) Wow, we may want a way to manage long lists of Groups even before that becomes critical for Cardtypes.
--John Abbe.....Thu Feb 24 11:22:10 -0800 2011
This is a pretty big chunk of coding already. Any reason not to push _owner off to a separate ticket?
The "interface level argument for simplifying" applies to all of the settings. improve interface for editing settings
--John Abbe.....Thu Feb 24 11:26:26 -0800 2011
so far I'm not looking for an owner solution -- I'm looking for evidence of need. Until the case is made, I'd say it's an Idea. yay for the interface ticket (prolly medium)
--Ethan McCutchen.....Thu Feb 24 11:29:16 -0800 2011
I don't understand the question about reader_key generation.
--Gerry Gleason.....Mon Feb 28 04:02:07 -0800 2011
The above solution is highly reliant on the reader_key -- it's how we make this thing something that can perform in WQL. We can't process much permission logic at query time -- the reader_key solution addresses that.
My key response to the *owner idea is that coming up with ways to represent permissions in cards is the easy part -- thinking through a workable implementation is the hard part. So for it to be a complete proposal, we'd need to digest all the implications.
It's quite possible that the hairiest part of implementation will be the reader_key updates (which is really more my concern than the generation, which would still be more or less the same), as it's essentially a database-level caching system, which always has the potential to become, well, hirsute.
Eg, when I change the owner of a Set, it's not as simple as updating the reader_keys for every card in the set -- we have to check each one to make sure it's not overridden somewhere by a narrower set. This may not be a dramatic jump in complexity, because we basically have to do the same thing for all the other permissions settings, but it obviously adds *some* new complexity.
Some of this may just be my confusion. Just to understand what you've written, when you say this:
"Values would be just like the *CRUD permission settings, but would be the other side of the permission validation (i.e. if any item in the *owner setting can Create(RUD) then Create(RUD) is allowd)"
...I don't think I follow. Can you give me an example of what you mean?
By the way, I'm digging into this now because the use case may have emerged now :)
--Ethan McCutchen.....Mon Feb 28 10:21:37 -0800 2011
Cool - what's the use case?
--John Abbe.....Thu Mar 03 10:43:57 -0800 2011
re initial permissions, we'll just need to do the default case on en. We've only ever used something other than that once (for rcc), and administrating permissions will be easy enough to change it dynamically now.
--Ethan McCutchen.....Thu Mar 03 11:37:41 -0800 2011
use case not totally clear yet. will post more if it gets clearer.
--Ethan McCutchen.....Thu Mar 03 11:54:43 -0800 2011
In the part you quoted, I was just saying that if we used a *owner setting, then that "Setting Values" would be just like the setting values you describe in this ticket for *create ..., A role, card with account or special values. Only it is used differently. With the CRUD settings, you are matching the available Roles/Users, etc. to the setting for the actions, with *owner, you are looking up the setting for another one of the available Roles. I.e. the other side of the permission check.
--Gerry Gleason.....Thu Mar 03 13:25:09 -0800 2011
don't get it. example?
--Ethan McCutchen.....Thu Mar 03 15:00:53 -0800 2011
I don't follow the changes you just made to the solution, but given the gigantic cut in text, it can't help but be simpler. (=good :-)
--John Abbe.....Thu Jun 16 02:32:55 -0700 2011