NOTE: CWA = card with account
Will be doable with new account system
Not yet tracked (the tracking is generally much harder than the revealing). See references+tickets for item
Also see expose Image cards metadata, and similar could be done for Files (author, created/edited dates, etc.)
Also see expose deck metadata in cards
what else?
What to do when a card is taken out of the trash - reset +created and +created by or not? Ask the user what to do? (If so, pick a default?). Could try to be clever and reset date/creator if they edit anything, and not reset if they save it just as it came out of the trash. --John
Things John had previously mentioned wanting that aren't up there any more.
|cardname|+*creatable by (Pointer of Roles - card permissions...)
|cardname|+*readable by
|cardname|+*editable by
|cardname|+*deleteable by
|cardname|+*commentable by
With setting-ize permissions these will be settings: *create, *read, *update. Figuring out the current value won't be possible as a db query alone -- it requires ruby processing of the set classes. We might consider making a more general solution of something like <card>+<setting name>+*current to get the current value of any given setting.
*update refers to editing, right? So will there also be a *comment ? And *delete?
|Role|+*can create
|Role|+*can view
|Role|+*can edit
|Role|+*can delete
|Role|+*can comment
Would like to be able to see a list of all cards viewable or editable only by a particular role.
yeah, might want something like that eventually that goes the other way. My preference would be to punt on design until after we've played with the new permissions system some.
Okay.
|cardname|+*has account (Toggle on if it has account extension)
Not wild about this name, but this info is already queryable: {"extension_type":"User"}. (not something to publicize, given the coming extinction of old school extensions)
That offers a way to return a list of CWAs, but not a yes/no on a given card, which frankly there's no use case for at the moment, but when actions are Wagneerable (implement triggers) there will be.
Useful for testing at least, e.g. the recent trouble i had with a cardtype card that didn't actually have the extension. Maybe better to generalize as "+*has extension" which is a virtual search card returning nothing or *account, Cardtype, Role...
Also growing irrelevant
--John Abbe.....Mon Apr 27 11:23:03 -0700 2009
Would love "+*cardtype" for http://democracyinnovations.wagn.org/wagn/the_big_list to show for each item which of several different types it is.
--John Abbe.....Tue Feb 08 20:08:47 -0800 2011
I'm thinking we should go ahead and wagneer +*count cards -- {"found_by":"_", "return":"count"} -- and then whenever possible do the "number_of" cards using +*count. It often won't be the case with above cards because they're not sqlable. But I think I prefer the "count" naming convention to "number of"
--Ethan McCutchen.....Sat Feb 19 11:21:53 -0800 2011
did first part
Not seeing anything else that can be Wagneered yet with *count.
--John Abbe.....Mon Feb 21 00:33:35 -0800 2011
+*url (Phrase, canonical URL of card's page)
Ethan: this seems more like it should be a view to me. add url view
--John Abbe.....Sat Feb 19 17:14:35 -0800 2011
+*when created
+*when last edited
add when_created and when_last_edited views now, reimplement when created and when last edited as module later
--John Abbe.....Fri Feb 25 17:24:11 -0800 2011
+*last editor
+*last edited
+*creator
+*created
add WQL for account relationship w last edit and creation
--John Abbe.....Fri Feb 25 17:33:37 -0800 2011
How about a Toggle, on if the card is used in code:
+*used in code
--John Abbe.....Mon Apr 11 15:04:19 -0700 2011
Hmm, would it be more useful/informative just to have +*codename? That's basically what we mean, right?
--Ethan McCutchen.....Mon Apr 11 15:26:06 -0700 2011
Sounds great. Goes in the "not yet tracked" section?
--John Abbe.....Mon Apr 11 15:40:27 -0700 2011
I think all codenames will be tracked as of 1.9.
--Ethan McCutchen.....Thu Jun 14 15:14:20 +0000 2012
changed this to Idea, because the difficulty of items discussed ranges from trivial to behemoth, some names are poor, etc. but it would be nice to review this and pick out some short term todos.
--Ethan McCutchen.....2013-04-03 17:21:58 +0000
+discussed in support tickets
+relevant user stories