Fri, 10 Apr 2026 09:50:15 +0000 https://bugs.horde.org/ticket/4928 Combine "Tickets which are" and "Type" selects in Search form 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). Mon, 22 Jan 2007 17:58:03 +0000 https://bugs.horde.org/ticket/4928#t28845 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. Sat, 27 Jan 2007 23:52:25 +0000 https://bugs.horde.org/ticket/4928#t28961 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. Sun, 28 Jan 2007 05:11:35 +0000 https://bugs.horde.org/ticket/4928#t28962 This patch is not against current CVS, and can you please make it a unified diff so it's easier to read? Thanks. Sat, 03 Feb 2007 03:14:48 +0000 https://bugs.horde.org/ticket/4928#t29104 > 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). Sat, 03 Feb 2007 03:35:11 +0000 https://bugs.horde.org/ticket/4928#t29106 > 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. :) Sat, 03 Feb 2007 03:59:08 +0000 https://bugs.horde.org/ticket/4928#t29115 Any update on the patch? Fri, 13 Apr 2007 15:13:46 +0000 https://bugs.horde.org/ticket/4928#t31557 > 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. Fri, 13 Apr 2007 15:58:44 +0000 https://bugs.horde.org/ticket/4928#t31619 > 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. Mon, 16 Apr 2007 02:19:30 +0000 https://bugs.horde.org/ticket/4928#t31705 Ping? Mon, 30 Apr 2007 20:49:54 +0000 https://bugs.horde.org/ticket/4928#t32403 > 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). Tue, 01 May 2007 02:49:55 +0000 https://bugs.horde.org/ticket/4928#t32422 Another ping? Fri, 28 Dec 2007 23:19:30 +0000 https://bugs.horde.org/ticket/4928#t40527 > 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? Sun, 30 Dec 2007 00:29:44 +0000 https://bugs.horde.org/ticket/4928#t40556 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. Sun, 30 Dec 2007 01:00:17 +0000 https://bugs.horde.org/ticket/4928#t40563 >> 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! Sun, 30 Dec 2007 01:44:59 +0000 https://bugs.horde.org/ticket/4928#t40564 > 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. Sun, 30 Dec 2007 01:46:30 +0000 https://bugs.horde.org/ticket/4928#t40565 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. :) Sun, 30 Dec 2007 01:49:54 +0000 https://bugs.horde.org/ticket/4928#t40566 > 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. Sun, 30 Dec 2007 02:48:07 +0000 https://bugs.horde.org/ticket/4928#t40569 >> 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. Sun, 30 Dec 2007 03:20:32 +0000 https://bugs.horde.org/ticket/4928#t40570 This is on me now to either implement or reject. Mon, 14 Jan 2008 04:59:10 +0000 https://bugs.horde.org/ticket/4928#t41118 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! Tue, 19 Feb 2008 05:26:30 +0000 https://bugs.horde.org/ticket/4928#t42576 > 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! Tue, 19 Feb 2008 13:48:55 +0000 https://bugs.horde.org/ticket/4928#t42600 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! Fri, 22 Feb 2008 08:37:40 +0000 https://bugs.horde.org/ticket/4928#t42741 fixed, thanks. Sat, 23 Feb 2008 01:26:18 +0000 https://bugs.horde.org/ticket/4928#t42778