fixed, thanks.

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!

Excellent!

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!

This is on me now to either implement or reject.

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.

That's a tag, not a dated version... the current code is still Whups 1.0-CVS.

One more comment.  In my explanation of the changes, I said this:
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. :)

Per my comment on 01/28/07, the unified diff attached to this ticket 
is against whups 1.0-cvs.

Unified diff attached.
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.
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!

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.

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?

Another 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).

Ping?

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.

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.

Any update on the patch?

Great, thank you.
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 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. 
:)

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).

This patch is not against current CVS, and can you please make it a 
unified diff so it's easier to read? Thanks.

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.

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.

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).