6.0.0-git
2019-04-25

[#4928] Combine "Tickets which are" and "Type" selects in Search form
Summary Combine "Tickets which are" and "Type" selects in Search form
Queue Whups
Type Enhancement
State Resolved
Priority 1. Low
Owners chuck (at) horde (dot) org
Requester php (at) ideacode (dot) com
Created 2007-01-22 (4476 days ago)
Due
Updated 2008-02-23 (4079 days ago)
Assigned 2008-02-22 (4080 days ago)
Resolved 2008-02-23 (4079 days ago)
Milestone
Patch No

History
2008-02-23 01:26:18 Chuck Hagenbuch Comment #24
State ⇒ Resolved
Reply to this comment
fixed, thanks.
2008-02-22 11:16:03 Jan Schneider State ⇒ Assigned
 
2008-02-22 08:37:40 tinu (at) humbapa (dot) ch Comment #23
New Attachment: Search.php.patch Download
Reply to this comment
the new Search form also shows types from queues who aren't visible 
(Request #4107).

the new code in whups/lib/Forms/Search.php seems to overwrite the 
$types array inside the SearchForm-methode. my small patch solves this 
(typo?).



thanks!
2008-02-19 13:48:55 php (at) ideacode (dot) com Comment #22 Reply to this comment
This turned out to be not as bad as I feared. I was able to remove a
bunch of the code, move some into the search form's getInfo() method,
etc., but pretty good. Thanks!
Excellent!
2008-02-19 05:26:30 Chuck Hagenbuch Comment #21
State ⇒ Resolved
Reply to this comment
This turned out to be not as bad as I feared. I was able to remove a 
bunch of the code, move some into the search form's getInfo() method, 
etc., but pretty good. Thanks!
2008-01-14 04:59:10 Chuck Hagenbuch Comment #20
Assigned to Chuck Hagenbuch
State ⇒ Assigned
Reply to this comment
This is on me now to either implement or reject.
2008-01-02 20:53:40 Chuck Hagenbuch Deleted Original Message
 
2007-12-30 03:20:32 php (at) ideacode (dot) com Comment #19 Reply to this comment
Per my comment on 01/28/07, the unified diff attached to this ticket
is against whups 1.0-cvs.
That's a tag, not a dated version... the current code is still Whups 1.0-CVS.
Well, unless there's some more precise way to tell from the files that 
were deposited when the download was made, I can only speculate: the 
whups directory access time is 2006-08-09 23:09:05, and our first 
recorded ticket was made on 11 Aug 2006.  So, it seems reasonable 
it'll be around those dates in August, 2006.
2007-12-30 02:48:07 Chuck Hagenbuch Comment #18 Reply to this comment
Per my comment on 01/28/07, the unified diff attached to this ticket
is against whups 1.0-cvs.
That's a tag, not a dated version... the current code is still Whups 1.0-CVS.
2007-12-30 01:49:54 php (at) ideacode (dot) com Comment #17 Reply to this comment
One more comment.  In my explanation of the changes, I said this:
In Whups Forms/Search.php, I changed the queue selection from
drop-down ("enum") to a multi-drop-down ("multi-enum"), and I added a
message declaring what would happen if you didn't select any of the
multi-enum values (this was for usability's sake).
Strictly speaking, this change is outside the scope of this ticket.   
In our use of Whups, it makes sense for us to be able to search across 
all (allowed) queues.  In general usage, however, this may not be 
wanted.  I'll let the "powers that be" decide if it's wanted. :)
2007-12-30 01:46:30 php (at) ideacode (dot) com Comment #16 Reply to this comment
Possible - I'll certainly take a look. Can you please make it a
unified diff, though? I find those much easier to read. Also, if you
can tell me what version/date of checkout the diff is against, I can
compare the original code from then with HEAD.
Per my comment on 01/28/07, the unified diff attached to this ticket 
is against whups 1.0-cvs.
2007-12-30 01:44:59 php (at) ideacode (dot) com Comment #15
New Attachment: issue4928.unified.diff Download
Reply to this comment
I will provide a unified diff.
Great, thank you.
Unified diff attached.
Before doing so, I'd like to finish the changes.  My question is: how
can I render a table of multienums in a single row?
You're going to need to write a custom form renderer. It doesn't have
to be fancy, just override creation of a separate table row for each
input. (I'll get into more detail if you need, but there are some
around in whups - queries - and other apps.)
I never figured out how to write the custom form renderer (owing to 
having essentially zero free time), so I didn't take this beyond the 
screen shot you see attached to this ticket.  I've also not 
bulletproofed this code, as I got it to the level of "good enough" for 
us.  It seems to work fine, though.
I wasn't able to entirely follow the diff since it wasn't against
HEAD, but yeah, that's likely fine. Feel free to add those unit
tests. :)
It's been a while since I've looked at this code, but let me give it 
an explanatory whirl.  I modified three files: 1 in Horde proper 
(Horde/Form.php) and 2 in Whups (search.php & Forms/Search.php).



In Horde, the change was simply to add a utility method named 
Horde_Form_Type::getValues() to recover the (presumably) private 
$_values member variable.  Call me OO-obsessive.



In Whups Forms/Search.php, I changed the queue selection from 
drop-down ("enum") to a multi-drop-down ("multi-enum"), and I added a 
message declaring what would happen if you didn't select any of the 
multi-enum values (this was for usability's sake).  I then needed to 
remove the "Tickets which are" and "Types" variables and replace them 
with a loop over all ticket types, adding multi-enum variables for 
each ticket type.



In Whups search.php, I made the biggest changes.  These were largely 
cleanup operations, to aid in my development as I waded through the 
code:

1. The code to determine the URL needed to re-run the query was moved 
in to a function named getSearchReplayURL().

2. The code to save a search (if logged in) was simplified by using a 
helper method called getNameForCriterion(): this method takes a 
criterion name (such as "queue", "summary", etc), inspects the 
submitted values, and then returns a human-understandable string 
describing the submitted values.  Owing to the changes mentioned in 
Ticket 4897, this may no longer be needed.

3. The code to "munge a query into acceptability" was moved into a 
method called mungeInfo().



These should be relatively easy to patch into HEAD.  Let me know if 
you need more details.  Thanks!
2007-12-30 01:00:17 Chuck Hagenbuch Comment #14 Reply to this comment
Possible - I'll certainly take a look. Can you please make it a 
unified diff, though? I find those much easier to read. Also, if you 
can tell me what version/date of checkout the diff is against, I can 
compare the original code from then with HEAD.
2007-12-30 00:29:44 php (at) ideacode (dot) com Comment #13 Reply to this comment
Another ping?
We have it implemented in our older version, but not in HEAD.  If I 
provided a context diff for our version, would that be enough for 
someone with more experience to apply it to HEAD?
2007-12-28 23:19:30 Chuck Hagenbuch Comment #12 Reply to this comment
Another ping?
2007-05-01 02:49:55 php (at) ideacode (dot) com Comment #11 Reply to this comment
Ping?
Alive, but haven't had time to address it (a bit of a curve: need to 
learn HEAD and then find an example I can massage).
2007-04-30 20:49:54 Chuck Hagenbuch Comment #10 Reply to this comment
Ping?
2007-04-16 02:19:30 Chuck Hagenbuch Comment #9 Reply to this comment
I took a stab at writing the custom form renderer, but no luck yet; 
any good docs
or poignant example out there?
Good docs on this, sadly. Not sure what would be poignant to you. 
Another idea would be to just implement a custom variable type 
instead, that rendered the three fields without starting another row - 
might be simpler.



If you want to skip that part of the patch for now it'd probably be 
easier for me to throw it together while committing it unfortunately. 
I'm currently working on rewriting Horde_Form and the new version will 
make this sort of thing much simpler (along with hopefully being 
documented), but that's not something for before Horde 4 apps.
2007-04-13 15:58:44 php (at) ideacode (dot) com Comment #8 Reply to this comment
Any update on the patch?
I took a stab at writing the custom form renderer, but no luck yet; 
any good docs or poignant example out there?



I also wanted to produce the patch against HEAD, so as to ease 
patching for you.  But, I haven't yet established an environment with 
that version.
2007-04-13 15:13:46 Chuck Hagenbuch Comment #7 Reply to this comment
Any update on the patch?
2007-02-03 03:59:08 Chuck Hagenbuch Comment #6 Reply to this comment
I will provide a unified diff.
Great, thank you.
Before doing so, I'd like to finish the changes.  My question is: how
can I render a table of multienums in a single row?
You're going to need to write a custom form renderer. It doesn't have 
to be fancy, just override creation of a separate table row for each 
input. (I'll get into more detail if you need, but there are some 
around in whups - queries - and other apps.)
Also, you will notice that I have refactored the code -- the
functional units as they stood were too broad for me to make surgical
changes and have any confidence that they worked (at least not
without substantial unit tests, which I couldn't find).
I wasn't able to entirely follow the diff since it wasn't against 
HEAD, but yeah, that's likely fine. Feel free to add those unit tests. 
:)
2007-02-03 03:35:11 php (at) ideacode (dot) com Comment #5
New Attachment: ss4928.jpg Download
Reply to this comment
This patch is not against current CVS, and can you please make it a
unified diff so it's easier to read? Thanks.
I will provide a unified diff.



Before doing so, I'd like to finish the changes.  My question is: how 
can I render a table of multienums in a single row?  In the attached 
screenshot, you can see that the 4 ticket types we have (Bug, 
Enhancement, Question, and Task) are each in their own row.  I would 
prefer to render these multienums horizontally (perhaps in a grid if 
the number of types exceeds a threshold), but I couldn't figure out 
how to do that without breaching the abstraction offered by 
Horde_Form.  Thoughts?



Also, you will notice that I have refactored the code -- the 
functional units as they stood were too broad for me to make surgical 
changes and have any confidence that they worked (at least not without 
substantial unit tests, which I couldn't find).
2007-02-03 03:14:48 Chuck Hagenbuch Comment #4
State ⇒ Feedback
Reply to this comment
This patch is not against current CVS, and can you please make it a 
unified diff so it's easier to read? Thanks.
2007-01-28 05:11:35 php (at) ideacode (dot) com Comment #3
New Attachment: issue4928.patch
Reply to this comment
Attached is a preliminary patch (against whups 1.0-cvs) for this 
ticket.  I could not figure out how to get the Horde_Form class to 
render a table of multienums (or more generally how to define a 
structured layout for a set of controls), so I simply list each type 
on its own row with its states as a multi-enum.  This is not ideal -- 
if someone can point me to how to structure controls, I'll make the 
changes.



I also noticed that the lib/Forms/Search.php file looks to be in 
Windows line ending mode, though the other changed files appear to be 
in Unix line end mode.  This might cause problems if running patch 
directly with this patch file.



Please review and let me know any comments/suggestions you have and 
also if you need more details to merge it against the latest CVS.
2007-01-27 23:52:25 php (at) ideacode (dot) com Comment #2 Reply to this comment
Under the aegis of this ticket, I would also like to make queue a 
multi-select.  This seems to be straightforward: simply changing the 
variable type in lib/Forms/Search.php:SearchForm() from enum to 
multi-enum.
2007-01-22 18:15:39 Chuck Hagenbuch Summary ⇒ Combine "Tickets which are" and "Type" selects in Search form
State ⇒ Accepted
 
2007-01-22 17:58:03 php (at) ideacode (dot) com Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ Combine "Tickets which are" and "Type" selects in QuickSearch
Queue ⇒ Whups
Reply to this comment
The "Tickets which are" select has two, related problems.  First, the 
ticket states shown are the Whups internal categories, which are not 
directly exposed to the user elsewhere (unless your own states happen 
to map 1:1 to those names). Second, you cannot make fine-grained 
distinctions between the categorizations when you have multiple 
"Assigned" states (eg states "Implement" and "Verify" are both 
"Assigned").



The functionality of type and "tickets which are" can be achieved by 
combining both into a table of multi-selects, one column for each 
type.  For example:



Bug                Enhancement     Task

---------------- | ------------------- | ------------ ....

Reported     | Requested       |  .....

Open            | Open

Fix                 | Implement

Verify            | Verify

Deploy         | Deploy

Resolved     | Finished



With this construct, you can select multiple type and states in a 
single motion.  As an extension, clicking on the ticket type header 
would select/deselect all the included states (or there could be an 
explicit select/deselect all link).

Saved Queries