On Sun, Dec 16, 2012 at 2:50 AM, James Fournie <[email protected]>wrote:
> Hey there, > > Mike, can you elaborate on what you're talking about for the benefit of > Justin and anyone who doesn't know about this feature you speak of? Maybe > point to the relevant code bits? > > Sure thing. The first schema I'm thinking of are the older actor.usr_saved_search table. It's currently part of a stalled effort which was originally meant to store the URLs of search results but, by addressing the query_type constraint (in particular, turning the field into an enum and adding a "QP" value to said enum), could be extended to store Query Parser search strings, or even abstract QP objects (which are better for reconstituting a UI). There's also the actor.search_query, actior.search_filter_group and actor.search_filter_group_entry tables, which are used in the KPAC, and are available to the TPAC. Here I imagine one would make use of the actor.search_query table with another table providing ownership or usage information for automated UI building. Both sections of the schema mentioned have middle-layer code that makes use of them, primarily the TPAC and KPAC mod_perl code. > It sounds like what Justin did is a useful feature. I hate to see > someone willing and eager to contribute get shut down so quickly, and I'd > like to make it a bit easier for Justin to make a meaningful contribution. > > I agree. I don't want to shoot down the idea of staff-saved searches by any means, but I would also encourage discussion in a more interactive medium than the wiki. An email (or several, if it's a complex topic) containing the details would be much more effective, IMO, at pushing the idea forward. That said, by way of summary and comment, the sketch is for a client-local, workstation-wide store of saved searches. I didn't see any provision for import/export, and the searches would presumably be available to any user logging into the workstation. Some of those points are features, some are anti- or missing features, and some could be argued either way. However, the disadvantages to the local-storage route far outweigh the time savings of avoiding the investment it takes to implement server-side storage. For reference, the only things that we've intentionally kept client-local are those things that are necessarily tied to either the hardware, such as printer settings, or leverage local-only xulrunner features, such as certain types of UI persistence. The one other thing that I can recall OTTOMH that is nominally local-only is receipt template storage, but those are generally tied to a physical location, have an import/export mechanism and can be overridden from the server if desired, and even with those capabilities there is a general desire to move them into the database, I believe. Thanks, Justin and James, --miker > Justin, I'd just like to say thank you for making the effort to document > what you're doing -- it looks like you've put a lot of thought into > documenting this. I'm not quite clear as to if you've written the code yet > -- if not then please consider what Mike's said. If you have code, > generally it'd be helpful to publish a git branch and then someone else may > be interested in adapting what you have to the framework that Mike's > proposed. > > ~James > > > > > On Wed, Nov 14, 2012 at 5:46 PM, Mike Rylander <[email protected]>wrote: > >> It's not noted in your description, so I'm guessing "no" ... but it's >> worth asking to be sure. Is this based on the existing ability to >> create user saved searches, and if not, are there reasons why >> extending or enhancing that functionality wasn't possible? >> >> TIA, >> >> --miker >> >> On Wed, Nov 14, 2012 at 8:17 PM, Justin Douma >> <[email protected]> wrote: >> > I have submitted a pull request for the new feature Search Templates >> > >> > This is a feature Catalyst IT created for the King County Library System >> > that we all would like to make available to the community. Search >> Templates >> > will allow library staff to save commonly selected combinations of >> 'global >> > row values' and search filters. Templates can be created or edited by >> going >> > to Admin->Workstation Administration->Search Templates. Saved templates >> can >> > then be selected on the Advanced Search page and the template's >> selections >> > will populate on the screen. Search Templates can only be used from the >> > staff client and can be turned on or off, for the Advanced Search page, >> in >> > the config.tt2. >> > >> > Blueprint: >> https://blueprints.launchpad.net/evergreen/+spec/search-templates >> > >> > Wiki Proposal: >> > >> http://evergreen-ils.org/dokuwiki/doku.php?id=dev:proposal:search_templates >> > >> > Justin Douma >> > >> > Catalyst IT Services >> >> >> >> -- >> Mike Rylander >> | Director of Research and Development >> | Equinox Software, Inc. / Your Library's Guide to Open Source >> | phone: 1-877-OPEN-ILS (673-6457) >> | email: [email protected] >> | web: http://www.esilibrary.com >> > > -- Mike Rylander | Director of Research and Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
