1 2014-08-04T08:30:39 *** greg_f
2 2014-08-04T11:07:20 *** randomax
3 2014-08-04T12:37:23 *** arsh
4 2014-08-04T12:37:32 *** arsh
5 2014-08-04T12:54:49 *** skathpalia
6 2014-08-04T14:02:50 *** skathpalia
7 2014-08-04T14:17:22 *** skathpalia
8 2014-08-04T15:36:11 *** skathpalia
9 2014-08-04T15:37:31 <skathpalia> moin
10 2014-08-04T15:37:47 <skathpalia> ThomasWaldmann, Updated the cr https://codereview.appspot.com/113830043/
11 2014-08-04T15:38:26 <skathpalia> https://codereview.appspot.com/114210043/
12 2014-08-04T15:39:58 <skathpalia> Also Can I commit this https://codereview.appspot.com/121930043/ ??
13 2014-08-04T15:40:19 <skathpalia> and this also https://codereview.appspot.com/116940044/
14 2014-08-04T16:14:43 <ThomasWaldmann> moin
15 2014-08-04T16:17:47 <skathpalia> ThomasWaldmann, moin
16 2014-08-04T16:18:38 <skathpalia> Added some pending crs above
17 2014-08-04T16:36:08 * ThomasWaldmann still busy on #moin
18 2014-08-04T17:30:00 *** randomax
19 2014-08-04T17:32:45 *** skathpalia
20 2014-08-04T17:33:00 *** skathpalia
21 2014-08-04T17:35:31 <ThomasWaldmann> ok, now time for CR
22 2014-08-04T17:42:32 *** skathpalia
23 2014-08-04T17:42:49 *** skathpalia
24 2014-08-04T17:48:39 <ThomasWaldmann> skathpalia: as far as i could see, most stuff looks ok (didn't run the code, though), you still have to fix that ptime or mtime issue i already had pointed out before
25 2014-08-04T17:52:36 <skathpalia> ThomasWaldmann, what can be displayed if we don't have both mtime and ptime?
26 2014-08-04T17:56:06 <skathpalia> One thing can be done to make ptime and mtime as necessary field
27 2014-08-04T17:56:14 <ThomasWaldmann> there are 2 valid cases: item published, item not published
28 2014-08-04T17:56:30 <ThomasWaldmann> that depends on whether the time is already beyond ptime (or not)
29 2014-08-04T17:57:06 <ThomasWaldmann> mtime should be always there, as we always set it if a revision gets created (== something is created/modified)
30 2014-08-04T17:58:05 <ThomasWaldmann> if there is no ptime set, it means "immediately publish" (IIRC)
31 2014-08-04T17:59:18 <ThomasWaldmann> so i guess it is fine if you just drop the else branch
32 2014-08-04T17:59:32 <skathpalia> Ok will drop that else branch :)
33 2014-08-04T17:59:56 <ThomasWaldmann> maybe have a look at other places checking this and do it consistently
34 2014-08-04T18:00:34 <skathpalia> Ok
35 2014-08-04T18:01:10 <skathpalia> Also wanted to know how can the query to find ticket specific tags, for now I have used simple query method https://codereview.appspot.com/111410043/
36 2014-08-04T18:01:35 <skathpalia> *optimize the query
37 2014-08-04T18:03:14 <skathpalia> ThomasWaldmann, ^^
38 2014-08-04T18:03:35 * ThomasWaldmann looks
39 2014-08-04T18:10:42 <ThomasWaldmann> suggested a minor optimization there
40 2014-08-04T18:11:08 <ThomasWaldmann> looking now whether it can be done fundamentally better...
41 2014-08-04T18:17:18 *** greg_f
42 2014-08-04T18:19:35 <ThomasWaldmann> skathpalia: field_terms(fieldname) gives all values seen in that field
43 2014-08-04T18:19:56 <ThomasWaldmann> but that would not be limited to tags used in tickets, but all tags
44 2014-08-04T18:20:45 <skathpalia> Yeah currently this is used
45 2014-08-04T18:23:17 <ThomasWaldmann> so maybe the question is rather whether we see tags as a general covering-everything thing, so tags are same for tickets and everything else
46 2014-08-04T18:23:39 <ThomasWaldmann> or whether there are distinct kinds of tags, for tickets, for wiki, for blog
47 2014-08-04T18:24:36 <ThomasWaldmann> (and if it is the latter, whether we want distinct fields in the index)
48 2014-08-04T18:27:30 <skathpalia> I think the latter would be better and then we can change the index also according to it
49 2014-08-04T18:30:12 <skathpalia> I mean we can divide the tags part in index in 3 parts:- one for tickets, one for blogs and other for all other type of wikis
50 2014-08-04T18:32:00 * ThomasWaldmann isn't quite sure about that yet
51 2014-08-04T18:32:33 <ThomasWaldmann> of course it would make that "show me all tags that are used in tickets" easier
52 2014-08-04T18:33:26 <ThomasWaldmann> but also you can't just say "tag(s):sometag" in a query any more, but you'ld need to say "tickettag:sometag"
53 2014-08-04T18:37:03 <ThomasWaldmann> also, if you want to search for tag x just in tickets, you can always do "itemtype:ticket tag:x", but you are free to search for x everywhere by not restricting it to tickets
54 2014-08-04T18:38:36 <skathpalia> Yeah ...
55 2014-08-04T18:39:33 <skathpalia> Then I think we can make a function that returns ticket specific tags and we use that function in +tickets view and ticket show/modify view
56 2014-08-04T18:39:40 <skathpalia> What do you say on this?
57 2014-08-04T18:41:23 <ThomasWaldmann> guess you can do it like that for now. might be not super-efficient, but can be modified later.
58 2014-08-04T18:41:54 <skathpalia> Ok will do this for now and later we can look for some other method :)
59 2014-08-04T18:42:24 <skathpalia> btw I also updated the cr https://codereview.appspot.com/113830043/
60 2014-08-04T18:42:24 <ThomasWaldmann> there's also the concept of wiki farms and namespaces, so maybe tickets could just live in one of them, so the tags could be separated that way
61 2014-08-04T18:44:58 <ThomasWaldmann> btw, did you pull/merge from main repo?
62 2014-08-04T18:45:04 <skathpalia> Yeah
63 2014-08-04T18:57:08 *** dave_largo
64 2014-08-04T19:07:43 *** skathpalia
65 2014-08-04T21:11:14 *** dave_largo
66 2014-08-04T21:42:06 *** spyyy
67 2014-08-04T22:35:54 *** spyyy
68
