Ticket+recent inclusion changes
my first reaction is that this should probably only affect relative inclusions... Otherwise we might really drown recent changes with edits to a commonly transcluded card.
how do we know if an inclusion is relative? it would need to be recorded in the reference. (currently is not)
--Lewis Hoffman.....Fri Jul 10 11:12:52 -0700 2009
convo w/ Ethan, we can do just cards included by trunk. this will be the same as relative in most cases but doesn't require new tracking. FTW!
--Lewis Hoffman.....Tue Jul 28 09:42:23 -0700 2009
This is done for notifications. Bailing on recent changes for now.
--Lewis Hoffman.....Tue Aug 04 12:50:32 -0700 2009
Cool, it works!
At least one issue with it -- the email tells me who last changed the including card and its last-changed date, rather than that giving info for the included card that actually changed.
--John Abbe.....Wed Aug 05 08:10:40 -0700 2009
And, should i ticket doing this for RC? And is the intent then to bump the date as described in +solution, or...?
--John Abbe.....Wed Aug 05 08:10:55 -0700 2009
For multi-edit, suggest changing:
This update included the following changes: edited defusion+visuals edited defusion+list
To:
This update included the following changes:
edited defusion+visuals
edited defusion+list
--John Abbe.....Wed Aug 05 08:17:29 -0700 2009
(Note to self: Make sure to check references to this card when splitting the ticket; most probably refer to Recent Changes.)
--John Abbe.....Fri Aug 21 13:27:02 -0700 2009
is the email still giving incorrect info? If so we should make a ticket for that.
As for the RC, I think this is difficult enough that we'll probably only get to it when there is a charge for seriously cleaning up search results. not sure it's worth ticketing until then.
--Ethan McCutchen.....Mon Oct 18 16:00:11 -0700 2010
Emails have the new format suggested here, but are still giving the wrong editor. (The date was removed, which is fine.)
Would like to add a note about RC somewhere, but not clear enough about what you mean by "seriously cleaning up search results" to now if there's a likely ticket or idea on Search+tickets for item or CQL+tickets for item
--John Abbe.....Sun Feb 13 23:26:11 -0800 2011
Er, my tagging assumed that the "in progress" meant this was targetted for 1.11?
--John Abbe.....2013-03-21 23:53:21 +0000
nah, I think this has been "in progress" since 2009. resetting.
--Ethan McCutchen.....2013-03-22 03:14:43 +0000
Note, we do want certain plus cards to show up in recent in some cases (eg analysis cards on wikirate.org)
This should really be "field descendants", not includers.
I basically just got :in working, but it works on types now, which is the single biggest issue we've faced.
--Ethan McCutchen.....Wed Mar 18 18:15:33 -0700 2009
(in only works with properties)
--John Abbe.....Mon Mar 23 11:02:56 -0700 2009
Has more been done on this? I.e., do i need to test other uses of in, or just bang on some weird cases around using it with types?
--John Abbe.....Sun Apr 05 19:01:57 -0700 2009
See http://sandwagn.wagn.org/wagn/WQL_testing
--John Abbe.....Thu Apr 16 14:55:15 -0700 2009
"in" is an operator. you can't have two operators in any one expression. and "in" is the *only* operator that takes multiple values.
so you can do name=>[in,A,B], type=>[in,A,B], or content=>[in,A,B] (which is the same as just in=>[A,B]), but you can't do eq=>[in,A,B] or =>[in,A,B].
All of the errors are with searches attempting to combine multiple operators in a single statement (out of spec), except for the plus card ones, which is designed but beyond the scope of this ticket (this is only for properties; plus is a relationship).
--Ethan McCutchen.....Thu Apr 16 21:22:47 -0700 2009
There's syntax in CQL+Design that supports multiple operators:
OPERATOR => [:in, VALUE1, VALUE2, ...]
eg. :eq => [:in, 'open', 'in progress', 'coded']
also, the "Full property syntax" section (of CQL+Design) looks like http://sandwagn.wagn.org/wagn/multiple_values_in_property_and_operator_1 should return Lewis Hoffman *and* all cards with "John" in the name. I gather now that neither of these were implemented.
(In the future could we have a design section that only specifies the bits that have actually been implemented, or if not, use the language from whatever design to specify what's been implemented?) In this case, sounds like what was implemented was just "Short Property Syntax", up to "Note there's no need for", is that right?
Close, and ticket/idea implement in with operators, support full property syntax and support search on multiple values per relationship? (or maybe one Idea that we Ticket/split later?)
--John Abbe.....Fri Apr 17 17:48:46 -0700 2009
Oh, you're totally right on the operator front. I should have reviewed those designs before that comment. Yes, what you're saying about what has actually been done is right.
As for what to do with this ticket, I guess my inclination for the moment would be just to make sure the docs are ok and give it a more generic name. If we're clear that type is working, I think the piece that made it "high" priority can be put to rest. Medium or low is probably ok now, no?
--Ethan McCutchen.....Fri Apr 17 19:38:59 -0700 2009
Docs updated; after talking with Ethan, left the name but removed 0.13 and added a ticket for what's done - Support multiple values per property.
Is what's left of this a Connectipedia-requested thing?
--John Abbe.....Tue Apr 21 12:41:42 -0700 2009
I need to update docs, names, etc, but basically: all *relationships* now support multiple values.