add traits interface

+status

+priority

+tag

+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).

When you say a trait is "a child whose tag has a codename" - by "tag" you mean the right-most cardname, right?

right.

Agree re getting rid of *accountable, since permission to create +*account cards is likely to be pretty restricted.

I'm still not sure I get the whole point here, but let me try. Rules are a subset of traits, right?

Yes, a rule is a trait of a set. But any card can have

And we have a nice interface now for editing rules. And now you want to add a general way of making it easier to discover and edit other traits?

No, I want to make it easier to edit permissions related to traits. Who can create/read/update/delete accounts, roles, discussion cards, and rules themselves. And if we turn type and name into virtual traits, then we can configure it, for example, that George can edit a card's content but can't change its type.

Going through your examples:

1. Agree re getting rid of *accountable. As for permission to add/edit +*account cards, that's pointed to pretty well by Config, yes?

2. +*roles has a nice, discoverable checkbox interface you can get to from any user card in the menu - account - so what's the need? May be clear from above, but the point is to determine who can use that checkbox interface, and who can view the roles in the first place.

3. What's the problem here? People get to the discussion from the menu, or directly on the card if +discussion has been included. Again, it's who can CRUD the discussion card.

4. Agree that there's no discoverability to setting permissions on who can edit rules, but this seems like something we should just add to Config. Don't like the idea of adding more to Config -- seems to me it should be about half as long as it is now. But I don't know that this one is a real priority anyway.

So I'm not seeing the need here. Or is another way of stating it that you'd like a more general solution for getting at non-rule Traits besides adding them by hand to Config?

We're not primarly talking about general site-wide rules here. Config is not relevant. We're talking about editing rules that apply to a card's trait from the card. rules that apply to A+B from the context of A. Rules that apply to Gerry+*account from the context of Gerry. Determining who can edit the discussion on pythons from the context of the python page.

As I write this, I realize perhaps there is a better way. If you go to "discuss", you actually see the +discussion card and would have no trouble reaching its views from there. If you go to "account", however, you see the "account" view of the accounted card. But, perhaps, instead of seeing a special view of Gerry, you should see a view of Gerry+*account. Then you could get to its rules directly. Similarly, if you saw a view of the +*roles card, you could access its views. OK, ok, ok, this is good. I think we need to kill this idea :). Thank you!!!

Still need to explore the virtual traits idea...

(Side note - why is discussion getting a code name?)

That's an easy one: because it's mentioned in code (in the menu). Any card mentioned in code should be mentioned by codename, not by name. Otherwise it will break when you change its name. The high level principle is that you should be able to rename any card in Wagn without breaking things.

--John Abbe.....2013-05-08 23:02:19 +0000

ah right (re discussion codename)

I think I'm getting the issue here (sounds like it was more "add traits permission interface" ). The solution - use related for plus-*account? - adds a little noise, but is actually more consistent. So this solves the whole thing?

--John Abbe.....2013-05-09 09:01:30 +0000

Perhaps if I add back the origin of the idea. I wanted to experiment with a meta-currency module. I wanted to be able to add a plus card to a base card and thus give it additional capabilities. In the prototype that was a +*sol card. When such a "trait" was present, I would add an additional menu item (this was old menus, so it added a new top level menu, next to Edit, IIRC) called "Declare" and the sub-menu items would be different declarations that could be made (each having a form, which just used the multi-edit code).

In this context, I would be a Pack developer who wants to add menu options whenever my trait (codename :sol) is present.

--Gerry Gleason.....2013-05-09 15:31:59 +0000

The +*account usage is really very similar. I actually coded most of the work toward making the +*account cards themselves into a virtual thing with an module to implement it. That is, the current Rails model for User, is an "external trait", meaning that the model is external to Wagn (not a card). We got much of this in already, but the branch I went furthest with this on needs a bit of attention because of a lot of intervening work. A bit more work and we can make +*account a plugable module with the User model as the default (core) version of that.

--Gerry Gleason.....2013-05-09 15:37:13 +0000

Ah, so your original use case would be solved by make menus Wagneerable?

Nice re the account work - thanks!

--John Abbe.....2013-05-09 18:47:25 +0000

Right, Gerry, that was the origin of the traits concept. With this idea card I was looking for ways to make trait permissions more accessible to wagneers; you're talking about making it easier for pack developers (and eventually wagneers?) to add new traits. Perhaps we should start an add traits api idea?

John, I think the ticket may be move account and account_roles views to traits? ...or something?

--Ethan McCutchen.....2013-05-09 20:07:59 +0000

Now you lost me again. I thought your solution was to use related when people click on "account" in the menu?

--John Abbe.....2013-05-09 20:10:38 +0000

yeah, we're still talking about the same thing. related view is just a holder for a normal view (titled, by default) of a related card.

what is now the "account" view of X will now be a related view that holds a normal view of +*account

--Ethan McCutchen.....2013-05-09 20:29:51 +0000

I don't get how the name you gave describes that. Unless you're using "traits" to refer to this "related" view?

--John Abbe.....2013-05-09 21:05:40 +0000

I just meant that we should get rid of the weirdo views (account / account_roles) and create normal views on the trait cards (+*account, +*roles). maybe not great wording.

--Ethan McCutchen.....2013-05-10 01:56:20 +0000

Your wording confused me. I suggested "use related for plus-*account" but no need to get too bogged down in the wording...

You mentioned Wagneers adding traits - if part of the definition is that the tag has a codename, that seems impossible, or am I missing something?

--John Abbe.....2013-05-10 03:34:11 +0000

codename is stored in db, so not impossible, but not really what I meant. if you want to add a make menus Wagneerable ticket as you proposed (we actually cross-posted there; I wasn't protesting that name) that's fine, as it captures the key high-level value.

similarly, my other ticket name was to describe the work more than the effect. Only think I didn't like about your name was that it was *account only, whereas the work will involve *account and *roles.

--Ethan McCutchen.....2013-05-10 16:34:35 +0000

perhaps use related view for account and roles interface would be best?

--Ethan McCutchen.....2013-05-10 16:35:19 +0000

Yes, many things to tease apart here.

1) The primary focus of this ticket, moving some independent settings/permissions to being settings/permissions on a related (typically a 'trait' card as we have been calling it) card.

Is the remaining design work on this solution mainly about how to specify how/where these things show up in the UI? I think I need to dig into how the menus are now constructed now.

2) make menus Wagneerable is maybe a bigger goal, consistent with AWAP, but this is more about pack developers, so add traits api is probably more what we are talking about. I suspect that whatever is done to solve the main needs of this ticket, will enable developers to add trait related things to the menus. Maybe we just need to expand on the pack related idea cards to account for traits and menu mods.

To clarify on codenames for traits in packs, such a pack would be adding codenames as part of it's installation, so yes, packs will need to be able to create codenames and we'll have to have ways to deal with potential name collisions. Registering them would help, but I think we'll also need to be able to modify codenames on install to fix collisions.

--Gerry Gleason.....2013-05-11 13:19:34 +0000