We really need to think about this more deeply. We don't really know the "owner" of a card, just the last user to create a revision for it. The similar semantics in file-system permissions (Unix/Posix model) is that the owner is the creator of the first revision, but the owner can be updated by root (WagnBot for us). Likewise, you would have a "group owner", which would probably be bound to Role cards in Wagn. If we need either/both of these, I think that cards actually need an additional attribute(s) for the owner/group. Then store the owner_id (and role_id) to each card (and to the revisions just as we contemplate now for types and names in the enhanced history).

 

Then we would need a whole set of permission rules for owner/group.

 

I suspect there is a better solution in creating virtual roles for owner/group. We can have multiple roles listed for permission rules, right? So maybe it is just like _left, add _owner or _role to the permission rules. Then owner is just like any other attribute tracked in revisions, we can cache it in the cards table if that makes things faster, or join it from the current revision in the revisions table.

---

Oh, another thought on this. Rather than hold extra state about who the owner is, add the owner or a role of the owner to the appropriate permission rules. In other words, use existing permission mechanisms, but automate adding owner rules using the event system. Mostly would be "after create" rules for Sets that want this.

 

What are the common use cases where the owner wouldn't otherwise be able to edit their own content? I'm guessing that a typical Wagn allows logged in users to update most content, but maybe not some specific categories like User profiles, blog entries (or any other "curated" content Wagneered into the sight), except in the case that the user created the content. You could even leave an "edit window" by removing the owner permission after a set period of time elapsed.

 

Basically, use the existing mechanisms plus some fairly standard event processing. Probably not something that Wagneers would want to change much, sort-of advanced Wagneering to set-up site policies and we could have some configurable stuff using events we release in the core, but you can't easily change it by Wagneering (config, not cards). There would be the ability to select common patterns on installation.

 

Maybe this is something we can change in the cards, but as we have discussed, it would not take effect until the Wagn is restarted. That way it doesn't have to be some cldstr feature that is in or not, but it is still beyond normal Wagneer controls.

---

We wouldn't need a separate set of wagneer-level rules. "owner" would just be a potential value for the existing rules. I do think we'd need an owner_id field (but not a separate role_id field. there's no reason owner_id couldn't be a role), but this would be an optimization so that the permission could be used on WQL queries. That's really the trickiest part of all this.

 

The typical use case that we don't support (but I get asked about all the time) is simple support for the case that someone can create a card that only they can edit. You can only do that now if you have permission to edit the permissions rules. Yes, you could achieve that with events.

 

What makes owners a bit more appealing is when you're transfering ownership. It's a pain to have to update the values on 3 or 4 permissions rules at once. Owner is basically providing a variable name to do this in one swoop.

 

Since, as you mention, there will soon be other ways to achieve the simple case, I'll knock down the priority until we know we want/need this.

---

Another common use case I'm aware of is to make most fields on Users only editable by that user. Is that covered by your "simple case"?

---

So, owner would be a Card model addition? Or would we do +*owner and reflect that in the owner_id for efficiency?

---

The latter, basically. I assume the canonical representation would be in a card, but anything that effects read permissions is going to involve some code/data optimization. (which is why it's complicated enough that the reward needs to be thought to be high before we tackle it)

---

or before I get interested in tackling it, at least :)