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.
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?
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.
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.
Ah, so your original use case would be solved by make menus Wagneerable?
Nice re the account work - thanks!
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?
Now you lost me again. I thought your solution was to use related when people click on "account" in the menu?
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
I don't get how the name you gave describes that. Unless you're using "traits" to refer to this "related" view?
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.
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?
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.
perhaps use related view for account and roles interface would be best?
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.