add traits interface
Idea
+issues
We've been tossing around the word "traits" for a while. This is an attempt to harmonize/advance those ideas that could address:
- Wagneer noise in editor space surrounding type changes
- simplifying account permissions (getting rid of *accountable setting)
- simplifying comments (getting rid of *comment setting)
In the wagn code, there is already the concept of a trait card that is closely related to "child". For example, John+*account is a "trait" of John, and any rule is a "trait" of a set. Really, I think you could define a trait (at least in its current code usage) as "a child whose tag has a codename".
Here's the key emerging trend: rules (especially permissions) that apply to traits are meaningful to wagneers but inconvenient to access.
That's probably inscrutable to most. So, some examples:
- We are moving towards having all account data in cards, and as part of that trend, any "card with an account" (most often a User card) also has a +*account card. So, if "Lewis" has an account, there must be a "+*account" card. (Or, more to the point, to have an account is to have a *account trait). In order to add an *account to an existing card, you have to have permission to create that +*account card. But there's no easy interface to that create permission; you really have to know what you're doing. (eg, you have to know to go to *account+*right, or User+*account+*type plus right, or whatever)
- Similarly, the +*roles trait is where we store which roles a given user has. So the permissions for the +*roles cards are very meaningful to administrators but, again, you can't easily navigate to them.
- the "discussion" doesn't yet have a codename, so +discussion cards aren't technically traits yet, but they're going to as soon as we have migrations
- though the recursiveness makes it a bit harder to wrap your head around, the same pattern applies to the question of who can edit rules.
In summary, the issue is that while configuration on Wagn is generally getting much easier, there is a clear pattern of shortcomings that should be solveable in a harmonious way though some interface design.
+solution
Presumably the solution will be reachable via the menu, probably via new items, almost certainly through the "advanced" tab. Before proposing anything concrete, I want to survey the kinds of things I hope the solution might accomplish. (note, we'll probably end up breaking this up into separate tickets, but it's worth exploring the commonalities here).
- I would like to do this so well that we are able to get rid of some settings. For example:
- we currently have an "accountable" setting that supposedly determines which cards can have accounts. In truth, to create a new card with an account (or, in proposed new lingo, an "accounted card") you need three things: (1) permission to create the card, (2) permission to create the +*account card, and (3) yes on the accountable setting. I ask you: aren't the first two enough?? If the +*account setting is easy, then I would really think so. (note that there is a little trickiness to work out in the whole Account Request to User process)
- similarly, perhaps there should be a +*comment (or some such) trait, and that create permissions on that trait amount to what +*comment (the setitng) means now.
- We should explore the idea of a type trait. Since +*type is taken, I'll use the silly working name *tipe to mean that (will soon propose to rename set classes and free up *type). *tipe will simultaneously expose cardtype as a card and help cleanup the menu for non-Wagneers by making it easier to restrict type change permissions in nuanced ways. Changing types is a complicated thing, when you consider that it somewhat like destroying a card of the old type and creating a new one. But I don't think we've nailed that, and I suspect a +*tipe trait might be helpful in improving things. (needs design).
+discussed in support tickets
+relevant user stories