[VUFIND-477] Search Leading wildcards is not supported Created: 28/Nov/11 Updated: 07/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 1.2 Type: Reporter: Resolution: Labels: Improvement Aniss Hasna Unresolved Search Attachments: Wishlist Priority: Assignee: Votes: Major Unassigned 0 leading_wildcards.patch Description I have try many ways to make Vufind support search with leading wildcards for some keyword like "*pod" search should found "ipod" or "*ve" found "love", "give" ... for example But still not luck and i found the following link that maybe the opportunity for my problem will solve the keyword in Asian language like Japanese, Chinese, Thai ... which use less space for a sentence unlike English. For example sentence "ABCDEFGHIJK LMNOPQ" it should found this title if i use keyword "*FG" http://wiki.apache.org/lucenejava/LuceneFAQ#What_wildcard_search_support_is_available_from_Lucene.3F Please make it possible search with leading wildcards. Thanks Comments Comment by Demian Katz [ 05/Dec/11 ] In order to enable leading wildcards in VuFind, you need to do two things: 1.) Add the solr.ReversedWildcardFilterFactory filter to the text and textProper field types in solr/biblio/conf/schema.xml 2.) Disable the check in web/sys/Solr.php which detects and removes leading wildcards The attached patch shows how to do this against the current trunk, but it should be easily adaptable to earlier versions of VuFind as well (though it requires Solr 1.4 or later). I'm not going to make this part of the trunk by default since it causes a significant increase to index size for a feature that most people do not use... but if you feel it should be a core feature, please vote/comment here and the decision can be reconsidered. [VUFIND-467] Use Xincludes to separate local Solr configuration for easier management/upgrades Created: 25/Oct/11 Updated: 25/Oct/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description We should investigate whether Xincludes can be used to help separate local configurations from VuFind-packaged defaults now that we have upgraded to Solr 3.4 (apparently the Xinclude functionality is stronger in 3.x than it was in 1.4). [VUFIND-461] xsl transformation from mabxml to marcxml Created: 12/Oct/11 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Import Tools None Type: Reporter: Resolution: Labels: New Feature Priority: Thomas Schwaerzler Assignee: Unresolved Votes: mab2, mabxml, marcxml, transform Attachments: Wishlist Major Unassigned 1 aleph-x-mab2marcxml-uibk.xsl Description this xsl stylesheet tries to transform mab as it is coming from aleph x server to marcxml. it just takes the most important fields and translates them to marc trying to comply with the "Konkordanz MAB2 - MARC 21" ( see: http://www.dnb.de/DE/Standardisierung/Formate/MARC21/marc21_node.html) of DNB (German National Library) Comments Comment by Thomas Schwaerzler [ 31/Oct/11 ] for me it works best with my aleph-x-harvester: http://sourceforge.net/p/alephxharvester/home/Home/ [VUFIND-383] Using Oracle Database Created: 16/Feb/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Installation 1.0.1 Type: Reporter: Resolution: Labels: Environment: Improvement Fanliyong Unresolved extensibility Windows 2003 server Updated: 17/Feb/11 Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description I want to use Oracle database instead of MySQL in Vufind ,how can i do that? Comments Comment by Demian Katz [ 17/Feb/11 ] Thanks to the resolution of VUFIND-336, the VuFind code should be Oracle-compatible starting with release 1.1. Just use an "oci8://" connection string instead of "mysql://" in web/conf/config.ini. The only piece that is missing is an oracle.sql database creation script to match the existing mysql.sql and postgres.sql scripts. This should be fairly straightforward to create by adapting one of the existing scripts. If anyone has done this work and is willing to share it, I will add it to the trunk and close out this ticket. [VUFIND-332] Normalize LCCNs/ISBNs/call numbers with University of Michigan's custom Solr filters Created: 27/Sep/10 Updated: 13/Dec/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Major Unassigned 2 Description We should investigate the possibility of using some of University of Michigan's custom Solr filters in the VuFind trunk: http://github.com/billdueber/lib.umich.edu-solr-stuff The LCCN filter is almost certainly of value, and the ISBN filter looks likely to be helpful (though we should ensure it doesn't have unwanted side effects, as there are many ISBNdependent functions in the system). The call number normalizer is less developed but might still have value as an optional feature. Comments Comment by Eoghan Ó Carragáin [ 14/Jun/13 ] The custom Solr Filters have recently been updated and moved to a new github repo: https://github.com/billdueber/solr-libstdnum-normalize? Comment by Demian Katz [ 13/Dec/13 ] See also VUFIND-657. [VUFIND-319] The Innovative driver returns invalid(?) results when there is no bibitems table in the Millennium WebOPAC Created: 07/Sep/10 Updated: 27/Sep/10 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver 1.0 Type: Reporter: Resolution: Labels: Environment: Bug Major Priority: Julia Bauder Unassigned Assignee: Unresolved 0 Votes: None Innovative Millennium Release 2009B; Ubuntu 10.04 Wishlist Description When using the Innovative driver, on the /Search/Results page, if any record on that page does not have a bibItems table in the Millennium WebOPAC, the status for that item and for every item below it on the page will display as "Loading..." forever. There is often not a bibItems table when there are no physical holdings associated with a record, such as for online-only resources. The AJAX response for records without bibitems tables looks like this: <AJAXResponse> <item id=".b14595552"> <availability>false</availability> <location/> <reserve/> <callnumber/> </item> </AJAXResponse> Locally, I've implemented a quick-and-dirty fix by adding some code to the end of the foreach loop in getStatus($id) in Innovative.php to assign records with no bibItems table and a URL in an 856 the location and call number "Online Resource": if ($ret[$count-2]['status'] == NULL && $count > 1 && stripos($result, 'URLforCRL') > -1) { $ret[$count-2]['id'] = $id; $ret[$count-2]['number'] = 1; $ret[$count-2]['location'] = "Online Resource"; $ret[$count-2]['reserve'] = 'N'; $ret[$count-2]['availability'] = 1; $ret[$count-2]['callnumber'] = "Online Resource"; } We had previously modified our Millennium WebOPAC display to assign the id "URLforCRL" to the div that wraps URLs in 856 fields (this allowed us to grab that URL for a script running in the classic Millennium WebOPAC). I'm not sure if there's a way to do this that doesn't depend on modifying the Millennium WebOPAC templates to assign an id there. This only fixes the problems for records with no bibitems table (so, no physical holdings) and with a URL in an 856. If there were to be records with no bibitems table and no 856, the problem would still occur. [VUFIND-768] Added placeHold functionality to NewGenLib driver Created: 19/Mar/13 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver 1.3 Type: Reporter: Resolution: Labels: Improvement Joachim Langenbach Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Major Unassigned 0 vufind-ngl-place-hold.patch Description The patch added a placeHold function to the NewGenLib driver to place holds for items. It therefore also adds a getConfig function. Also the needed functions to cancel holds are provided, but currently they do not work for me. May be someone has an idea. In both functions there are some tasks masked with TODO, which are not completely solved right now. But may be the NewGenLib team is able to solve them quickly, as they know there database structure very well. Comments Comment by Demian Katz [ 19/Mar/13 ] I have forwarded information on the ticket to the team. Thanks for sharing, and good luck with the remaining details! Comment by Siddartha [ 22/Mar/13 ] Hi, The place hold functionality in NGL is categorized into 2 1. If all the copies of a title are checked out then user can place a hold. This is called as Reservations in NGL. When any user places a reservation a queue number is provided to the user. The queue number gets incremented for every user placing a reservation on this title. Whenever any copy of this title is checked into the library, the user with the least queue number is intimated to check out this copy. 2. If anyone copy of the title is available in the library. Then NGL does not allow reservations since a copy(ies) is/are available in the library. In this case NGL allows "Request for Check out". Unlike reservations where a reservation is placed on a title, "Request for check out" is allowed on a Piece Designation (Accession number/Barcode). If the understanding about the place hold functionality is clear from NGL perspective and can be applied to VuFind, we will recommend logic for development of driver for place hold Comment by Demian Katz [ 22/Mar/13 ] This makes sense and should be compatible with VuFind. Since VuFind effectively treats these two categories as a single concept, it is simply a matter of writing the driver so that when it receives a hold request, it figures out whether it needs to apply a reservation or a request for check out. Similarly, when returning information about outstanding holds, it should provide a merged list of both types of requests, and allow them to be cancelled seamlessly. If a user only wishes to allow one type or the other, or if they wish to maintain NGL's distinction in the VuFind interface, it should be relatively simple to achieve this through configuration and minor template customization. Comment by Siddartha [ 25/Mar/13 ] If all the copies of the title are checked out, then the database table into which the entry must be made is cir_reservation If atleast one copy of the title is available in the library then for an available copy an entry must be made in request_checkout [VUFIND-756] Perform Unicode normalization in SolrMarc indexer Created: 06/Mar/13 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Import Tools None Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved None Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description Letters with diacritics or some composed glyphs can be encoded in different but equivalent ways, namely in composition form and in decomposition form. Example: The german umlaut `ü' can be encoded as the single character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC), or as LATIN SMALL LETTER U (U+0075) followed by COMBINING DIAERESIS (U+0308). It is not uncommon that MARC records contain decomposed characters. When displayed the rendering of these glyphs depends on the e.g. browser's capabilities to approximate the combination. This looks ulgy e.g. the diaresis are not rendered directly above the `u' but with a noticable offset to the right. If a combined character has an equivalent non-combined character, Unicode normalization can create this character by normalizating into `Normal Form C' (NFC). Althoug this normalization can be done at the PHP side by ext/intl (normalizer_normalize(STRING)) it seems very useful to perform this normalization at index time. Comments Comment by Demian Katz [ 06/Mar/13 ] I'm sure there was some discussion about this issue on the solrmarc-tech list a year or two ago -it's probably worth bringing it up there to see what the status is. It's possible that there is already a solution that simply needs to be turned on by a configuration setting. Comment by David Maus [ 06/Mar/13 ] import.properties marc.unicode_normalize = C should do the trick. Allowed values according to MarcTranslatedReader.java: KC = NFKC KD = NFKD C = NFC D = NFD Comment by Demian Katz [ 07/Mar/13 ] Thanks for finding the options; definitely seems that we should consider making this a default setting. Perhaps a topic for the next dev call; in the meantime, I'll send a note to solrmarc-tech and see if others are already using this. Comment by David Maus [ 08/Mar/13 ] I commited a patch for import.properties with the option commented-out and some explanation about it's values. ACK: I make NFC the default (or NFKC?) or highly recommend using this option. Comment by Demian Katz [ 08/Mar/13 ] I've updated the example in the SolrMarc docs to match: http://code.google.com/p/solrmarc/wiki/ConfigProperties [VUFIND-757] Make authentication plugins compatible with Zend/AuthenticationService Created: 06/Mar/13 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved None Issue Links: incorporate is incorporated by Wishlist Priority: Assignee: Votes: VUFIND674 Major Unassigned 0 Redesign of VF2 application structure In Progress Description The Zend Framework provides a authentication service[1]. The VuFind authentication infrastructure should be compatibile with Zend's AuthenticationService. This allows for a future reuse of authentication plugins in or from other ZF based applications. The Zend AuthenticationService would also introduce the concept of Identities that can be persistet in the session and hold information about the authenticated user. If the identity holds all information necessary to retrieve user data from the persistence layer then serializing the user object in the session would not be necessary. [1] http://framework.zend.com/manual/2.1/en/modules/zend.authentication.intro.html Comments Comment by Demian Katz [ 07/Mar/13 ] I think that adapting the current authentication plugins to comply with the AuthenticationService is relatively straightforward, but it introduces some awkwardness to the code. Here's a proposed approach that would work with minimal code changes, but which has some side effects that I don't like: 1.) Revise \VuFind\Auth\Manager to use \Zend\Authentication\AuthenticationService for authentication and identity persistence. 2.) Revise \VuFind\Auth\AbstractBase and its children to comply with \Zend\Authentication\Adapter\AdapterInterface. We would need to add a setRequest() method to pass in the request since it can't be sent directly to authenticate(), and we would probably want to add a getUser() method so that the fully-populated User object could be retrieved from the authentication manager, rather than having to reload it based on the identity. The things that make me somewhat uncomfortable about this: - Since authentication adapters come from a plugin manager, we can't inject the request through the constructor; injecting through a setter is functional but inelegant. - The current authentication modules do a lot of work in terms of actually creating identities in the database as well as authenticating them; I'm not sure if this is appropriate in the ZF2 model, but if it isn't, I don't see a sensible way to decouple things, since identity creation is dependent on the data pulled in from the authentication source. - Putting a getUser() method on the authentication adapters is important for efficiency (why write a row to the database and immediately read it back if you don't have to), but feels inelegant -- we rely on \Zend\Authentication\AuthenticationService to change the state of the adapter, then go directly to the adapter to pull out information. Do you think it's worth making these sacrifices, or do you have an idea of how to do this more elegantly? Comment by Demian Katz [ 29/May/13 ] The sleep/wakeup logic for storing a full user object in the session was getting really ugly when trying to support multiple database systems, so I've simplified the code to only store the user ID and then retrieve the object from the database on demand: https://github.com/vufind-org/vufind/commit/bdb0971a68d40841e29b828ebdbd4cce38be2262 Hopefully this commit is a step toward making integration with Zend\Auth slightly simpler.... [VUFIND-691] Anonymous tags Created: 05/Oct/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch, Record None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 07/May/13 Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description It might be useful to add a configuration option to allow tags to be left without creating a user account or logging in. [VUFIND-690] Anonymous comments Created: 05/Oct/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 07/May/13 Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description It might be useful to add a configuration option to allow users to leave anonymous comments. [VUFIND-654] Perform health check of SOLR shards Created: 13/Sep/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved None Attachments: Updated: 25/Apr/14 Wishlist Priority: Assignee: Votes: Shard error handling 2.patch Major Unassigned 0 Shard error handling.patch Description Initial patch provided by Ronan McHugh, moved here from VUFIND-316: "The attached patch introduces a method into Solr to enable graceful handling of offline indices. Before Solr conducts a search, it pings all shards and only adds them to the sharding list if they are healthy. Otherwise, they will not be searched. This prevents users from being presented with a big ugly error screen when once index is offline." Totally makes sense, esp. in a multi-index scenario. Comments Comment by Demian Katz [ 13/Sep/12 ] Ronan McHugh's comment, moved here from VUFIND-316: Thanks David. From my correspondence with Oliver there are still a few outstanding issues with the patch. I will try to come back to it in the next week or so, but if anyone wants to go ahead with making the improvements, they are very welcome. Quoting Oliver: Issues: 1) I have found another thing, that might cause problems with your patch: we are using an external index from our library union, on which we have no writing access. We can ping it from our Solr host, where we have our local shards, which are combined with the union index. But currently we cannot ping it from our Vufind host. So it fails to add the central index to our shards if I use your patch. This is probably an uncommon situation, but I think we should take into consideration that ping may be denied to the Vufind host, even if the shard is running and could send valid results. So it might be a good idea to make this ping check configurable in config.ini. 2) I tried your patch, but it did not work for me. I added a fictive shard to config.ini and used it, but the error message was still coming up. I guess the problem is that you have not put your isIndexHealthy() method call into an if condition. + //check health of solr index before adding to shards + try { + $this->_isIndexHealthy($configArray['IndexShards'][$current]); + $shards[$current] = $configArray['IndexShards'][$current]; +} After changing the third line of the code above into + if ($this->_isIndexHealthy($configArray['IndexShards'][$current])) the patch worked for me as expected. 3) Add caching to improve performance. 4) UPDATE - Just noticed that the line: PEAR::setErrorHandling(PEAR_ERROR_CALLBACK, 'handlePEARError'); is causing problems with the sitemap generator. Comment by David Maus [ 13/Sep/12 ] Issue 1: I don't think of this problem as uncommon. There are three things a SOLR ping request checks: (a) the remote host is reachable via network (b) the host accepts HTTP request (c) SOLR is running Even if you can't check (c) for the union index you can check (a) and (b), and simply assume that if (a) and (b) are true, the shard is up and running. You could perfom a HTTP HEAD request, don't follow the redirect and ignore the response body. If the HEAD does not timeout and (maybe) does not return a 5xx error you assume (c). Comment by Ronan McHugh (Inactive) [ 13/Sep/12 ] Here is an updated version, somewhat sooner than expected with issues 1) and 2) and 4) fixed. Note that for Issue 1 I have used Oliver's solution rather than David's since I wasn't sure how to test David's. Since we most likely won't be going down this route, I won't be doing any more development on this patch. Hope it's useful and thanks for the help and comments! [VUFIND-570] Build shared index of open content Created: 02/May/12 Updated: 07/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Task Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Major Unassigned 4 Description There has been some discussion of building a shared VuFind index that could be searched via sharding and/or replicated to local servers in order to provide search access to open access content (for example, some of the data documented at the wiki page here: http://vufind.org/wiki/open_data_sources ). Obviously, there are some significant obstacles: 1.) Someone would have to maintain the hardware to run the index. 2.) Someone would have to maintain the software to harvest data and keep the index current. 3.) Because VuFind's Solr version is upgraded with most releases, compatibility over time may become a challenge. There is also a possible alternative/complement to the "shared index" approach -- creating a downloadable archive of harvested content so that it can be downloaded and indexed by VuFind users without having to repeat expensive OAI-PMH harvest operations. In cases where this is not in violation of any licenses, Demian may be able to host some content on vufind.org. The purpose of this ticket is to track conversation about this idea. If you have suggestions about how to achieve the goal or are willing to volunteer time or infrastructure, please comment here and/or update the wiki page linked above. Comments Comment by Filipe M S Bento [ 02/May/12 ] Hi! Just a quick note that perhaps, and for the time being, we should refer to this as Open Archives (metadata records, mainly from Open Access sources). Although Open Data (datasets, raw or treated data obtained from research or gathered by public agencies / with public founding, not metadata about it) is becoming a reality quite present and here to stay; in Europe we have http://www.openaire.eu/ and in the States, http://www.Data.gov for instance). Regarding the archives themselves, to have an idea of the size of the files for bulk download (upon that is not in violation of any licenses, like mentioned by Demian and talked yesterday in the Developers Call, http://vufind.org/wiki/developers_call:minutes20120501): 1.7G May 2 03:41 pubmed_pmc_fm_harvest_2012-04-28.tar > 2.2 million records (original download amounts to 11GB+, single XMLs > tar is a gziped file; besides, it took several days to harvest, as an error of "malformed response" keeps breaking down the process > injecting the last valid resumption token into harvest_oai.php and restart the process does the trick) 1.8G Dec 26 14:14 DOAJart_20110822.tar > 784 thousand records MeSH authority records are ready to download in bulk mode from NLM's site > converted from .bin to .mrc = 160MB (will post other backups that I have in an external drive, not with me right now) Filipe Comment by Filipe M S Bento [ 04/May/12 ] Added NDLTD: Networked Digital Library of Theses and Dissertations into the wiki page (http://vufind.org/wiki/open_data_sources). Stay tuned for more (to be added soon). Comment by Filipe M S Bento [ 29/May/12 ] Hello all! A special request: please state which sources you know of (that implement OIA-PMH, that have records that can be bulk downloaded or websites that have a sitemap.xml -- although others should be possible to be added, crawling them and generating a sitemap.xml via specific software ort services like http://www.xml-sitemaps.com) and would like to be analyzed and possible XSLT files generated to import their records into VuFind. Thanks! Filipe Comment by Filipe M S Bento [ 03/Sep/12 ] HI! Added "InTech Open (e-Books) InTech is a pioneer and world's largest multidisciplinary open access publisher of books covering the fields of Science, Technology and Medicine. Since 2004, InTech has collaborated with more than 70 000 authors and published 1827 books and 12 journals with the aim of providing free online access to high-quality research and helping leading academics to make their work visible and accessible to diverse new audiences around the world.” and "Extra: Set Up Change Tracking (optional) -- All sources" (source: http://vufind.org/wiki/importing_records:how_to_index_eprints_with_vufind) into the wiki page (http://vufind.org/wiki/open_data_sources). Thanks, Filipe [VUFIND-966] Eliminate serviceManager calls in controllers Created: 18/Mar/14 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Architecture None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Major Demian Katz 0 Description It would be nice to make dependencies more explicit and eliminate $this->getServiceLocator() calls in the controllers. For performance, we should consider using Lazy Services in at least some cases. See: http://framework.zend.com/manual/2.2/en/modules/zend.service-manager.lazy-services.html [VUFIND-889] Investigate CSL (Citation Style Language) integration Created: 16/Sep/13 Updated: 16/Sep/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Major Unassigned 1 Description We should investigate whether we can incorporate a CSL (Citation Style Language) parser for more generic citation support. See: http://citationstyles.org/developers/ [VUFIND-845] Exclude newspapers by default in Summon Created: 11/Jul/13 Updated: 11/Jul/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Summon 2.1 Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Major Unassigned 0 include-newspapers.patch Description At Villanova, we exclude newspapers by default and include a checkbox to optionally enable them. The attached patch shows the listener we use to achieve this effect as well as an example of how to wire it up. I'm not sure that there's sufficient justification for making this a standard VuFind feature, but hopefully the example patch will be useful for someone. [VUFIND-828] Unimarc import support Created: 24/Jun/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Import Tools None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Attachments: Updated: 25/Jun/13 Wishlist Priority: Assignee: Votes: Major Unassigned 0 uni.marc.properties Description VuFind's default configuration is designed to import MARC21 data; some libraries use Unimarc instead, which has a completely different layout. It would be helpful for VuFind to support Unimarc in some fashion. It is possible that this is best achieved by converting Unimarc to MARC21 prior to importing, but the attached uni.marc.properties (courtesy of Daniel Bourrion) provides some work-inprogress mappings that may help with a direct import. Note that as of this writing, the file is a few years old, and some small adjustments may be necessary. Comments Comment by Joe Atzberger [ 25/Jun/13 ] May be useful to reference the Koha community, probably the largest FOSS group supporting both MARC21 and UNIMARC via internal marc framework mappings. [VUFIND-825] VisFacet - Visualized Facets Cloud Created: 16/Jun/13 Updated: 27/Feb/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface 1.1 Type: Reporter: Resolution: Labels: Environment: New Feature Major Priority: Evgeniy Mishustin Unassigned Assignee: Unresolved 1 Votes: cloud, feature, visualization Tested with all modern browsers(also mobile), IE>9 (canvas tag support). See the full installation instructions in README.txt within archive. Attachments: Wishlist VisFaset.tar.gz cloud.png Description The ViSFacet package was developed, tested and contributed by Evgeny Mishustin as part of his final project towards his bachelor degree in software engineering at the Jerusalem College of Engineering (JCE). This project offers a visualized display of a faceted search to be displayed within the catalog's search results in VuFind. This facet is optional; it includes the Suggested Topics metadata and presents it in a graph view with the connections between the records' Subject Headings as well as the Region and Era subject's subdivision. The ViSFacet project was developed with the successful cooperation between the Jerusalem College of Engineering (JCE) and the Library Authority at the Hebrew University of Jerusalem. From the Hebrew University of Jerusalem Library Authority, Dalia Mendelsson provided the specifications for this project which was tested and successfully implemented at the Hebrew University Library Catalog (http://hufind.huji.ac.il) by Eli Hayun Evgeny Mishustin and Dr. Miriam Allalouf worked on this project from the Jerusalem College of Engineering (JCE). Comments Comment by Evgeniy Mishustin [ 01/Jul/13 ] The last version of VisFacet can be seen in work at http://hufind.huji.ac.il - The Hebrew University of Jerusalem library catalogue Comment by Filipe M S Bento [ 27/Feb/14 ] For reference, please find attached Evgene screenshot of a previous version. [VUFIND-123] Suggested Resources and Searches (recommender system) Created: 07/Oct/09 Updated: 19/Nov/09 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description Create a system for recommending specific resources based on search terms. This exists in a skeletal form in the Villanova implementation of VuFind but should be made more generic and incorporated into the trunk at some point. Comments Comment by Demian Katz [ 08/Oct/09 ] More detail on the current Villanova system: This is currently implemented as part of the Web module only, which is accessed on our system through a search in "Library Website" rather than "Catalog." We have simply created a "Web/bestbets.tpl" template which is pulled in at the top of Web/home.tpl and which displays an extra box of content based on certain hard-coded search terms. Here's an example of this in action -- a search for hours shows an extra box with our library hours: https://library.villanova.edu/Find/Web/Search?lookfor=hours&type=&search=website&submit=Find To be useful as part of the trunk, it would be better to have a generic way of defining and managing search terms and displayed content so that users don't have to manually edit if statements in a template file to make this work. Comment by Greg Pendlebury [ 14/Oct/09 ] USQ is looking at something in this vein. We currently have subject guides which recommend databases to users. These will be exanded to include public lists and saved searches from VuFind. The ability to inject them at the top of search results for specific keywords seems like an excellent delivery mechanism. Comment by Till Kinstler [ 15/Oct/09 ] There is something similar in "Elib Bremen" (http://suche3.suub.uni-bremen.de/indexEN.html). If you search eg. "information retrieval" you have database recommendations in the right column. They have assigned their databases to subjects in their local classification system ("Bremer Systematik"). Then they calculate best matching classes in that classification system for user entered search terms based on classification of the matching metadata records. For "information retrieval" that's "Informatik" (Computer science) and "Buch- und Bibliothekswesen" (book and library science). Then they print the databases assigned to those classes in that box on the right. They offer that "query classification service" as a web service where you may send query terms and get the classification codes back. Another next gen catalog project here in Germany uses that service: http://beluga.sub.uni-hamburg.de/list?searchtext=krise&submit=Suchen (the database recommendations are in the grey box in the result list). Though, the results you get from that service are based on the local holdings at Bremen, so they may not fit other library collections. Something like that shouldn't be too hard in Solr, I think. If someone is interested in the details of this feature (eg. the exact maths behind it), feel free to contact me, I may refer you to the guys at Bremen. [VUFIND-120] Grouping of similiar items by edition - FRBR Created: 07/Oct/09 Updated: 06/Mar/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record, Search None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Major Unassigned 1 Description We should give some thought to how the FRBR model fits with VuFind. Comments Comment by Demian Katz [ 23/Mar/10 ] The current xISSN/xISBN WorldCat API calls are a helpful start. Can we do more? Comment by Demian Katz [ 30/Apr/10 ] It's worth looking at the XC metadata services toolkit -- perhaps their schema can inform our design if we introduce FRBR features. This is particularly important if we eventually create a connector to harvest data from the MST into VuFind! Comment by Demian Katz [ 28/Sep/10 ] It is now possible to harvest records from the MST using OAI-PMH (see comment on VUFIND-236). This is a step in the right direction, though obviously the bigger challenge remains developing an index tool for XC schema records and, if necessary, adjusting VuFind's schema to accommodate them. Comment by Demian Katz [ 06/Mar/12 ] VuFind 1.3 upgraded to Solr 3.5, which includes field collapsing features; this may be the simplest technical underpinning for a FRBR implementation, though making use of it would require significant index-time work to come up with normalized Solr fields to use for grouping. Perhaps this is where the XC MST can fit in. [VUFIND-844] update jquerymobile to latest version Created: 11/Jul/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Mobile Interface None Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Updated: 30/Jun/14 Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description The jquerymobile theme is using a release candidate of the library, which is now past version 1.3; we should look into upgrading if we plan to retain this theme. Comments Comment by Tom Misilo [ 14/Aug/13 ] Working on seeing if I can get this done. I am getting the following error after replacing the css/images/js and updating theme.config.php* (I said module.config.php should have been theme.config.php) 2013-08-14T16:53:18-04:00 CRIT (2): Zend\View\HelperPluginManager::get was unable to fetch or create an instance for searchbox Looks like it has something to do with search/searchbox.phtml Comment by Demian Katz [ 15/Aug/13 ] I don't see why changing the libraries would cause this problem to appear -- the framework is unable to load the searchbox view helper, but that's a server-side issue, and I would only expect changing the libraries to cause client-side problems. The most likely explanation I can think of is that the module.config.php configuration file has a typo in it or has otherwise been corrupted. You might want to give that another look. Feel free to share it if you're not seeing an obvious problem. Comment by Tom Misilo [ 15/Aug/13 ] Here is what I have so far: https://github.com/vufind-org/vufind/pull/19 Comment by Tom Misilo [ 15/Aug/13 ] Example: https://staging1.lib.fit.edu/?ui=mobile (Using the above code) Original jquerymobile: https://staging1.lib.fit.edu/?ui=theme1 Comment by Demian Katz [ 15/Aug/13 ] I can't reproduce the error on my test server -- I checked out master and merged in your changes, and the upgrade seemed to work (I didn't test exhaustively, so there may be isolated problems, but pages continued to render and styles changes visibly after pulling the new code). No searchbox errors. You might want to double-check if your problem server has some unrelated changes that are not part of your PR -- maybe try a clean branch of master as a basis. [VUFIND-12] Create RPM package Created: 15/Oct/08 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Installation None Type: Reporter: Resolution: Labels: Task Andrew Nagy Unresolved None Updated: 23/Jul/14 Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description It would be nice to have an RPM package to complement the existing DEB package (see VUFIND-288) to help with easy installation. See also VUFIND-116 for Windows-based installer notes. Comments Comment by Wayne Graham [ 20/Oct/08 ] There's an issue with generating the RPM. VUFind uses PHP 5.2.x and there aren't RPMs for most systems out there for this version in the repositories out there for RHEL and CentOS. You still need to build PHP from sources for this, but the test in the RPM SPEC for this will fail since it's not in the RPM database. These are the systems I know of that come with PHP 5.2.x Fedora Core 9 OpenSuse 10.3 These come with 5.1.x RHEL 5 RHEL 4 CentOS 5 CentOS 4 OpenSuse 10.2 We can handle this a couple of ways: - Downgrade the 5.2.x requirement, and just tell folks they need that version (could be confusing since not everyone would read this). - Don't provide an RPM Comment by Demian Katz [ 23/Jul/14 ] Some resources that might be helpful: PHP Deployment with RPM: http://www.eschrade.com/page/deployiment-rpmyum-whateveryour-uses-4c2393be/ How to create an RPM package: https://fedoraproject.org/wiki/How_to_create_an_RPM_package [VUFIND-180] Better native support for consortia Created: 02/Dec/09 Updated: 17/Oct/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch, User Interface None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Attachments: Issue Links: Wishlist Priority: Assignee: Votes: autocomplete_library.patch incorporate incorporates VUFIND580 incorporates VUFIND594 incorporates VUFIND418 Major Unassigned 3 library_selection.patch Consortium Support for Reserves Index Multiple backends (ILS drivers) support Allow specifying configuration source... Open Resolved Resolved Description VuFind is currently in use by several library consortia, but they rely on local modifications. We should try to get some consortium-oriented functionality into the base code so that it requires less work to get VuFind up and running in a consortial environment. Some example features: - Ability to filter to a single library or show all libraries' holdings (perhaps a new generic faceting mechanism could be added that inserts a drop-down list into the UI and remembers the setting of the drop-down across all pages). - Ability to show holdings differently depending on currently selected home library. - Ability to associate a home library with a user account. - Ability to take multiple libraries (and possibly multiple ILS's) into account when placing holds. Please feel free to comment on this ticket with ideas for additional features. When we start implementing this, we should open additional subsidiary tickets so we can track each feature separately. Comments Comment by Demian Katz [ 26/Mar/10 ] Based on vufind-tech conversations, a proposed algorithm for determining the current user's home library. Note untested code and probably needs some extra details added to validate values; however, it should demonstrate th function getHomeLibrary() { // Is home library already determined in the session? (This may be a cached value from // the logic below, or it may have been set by the user via a UI control). If so, send it back: if (isset($_SESSION['homeLibrary'])) { return $_SESSION['homeLibrary'] ; // Home library may be specified via GET/POST or cookie -- all show up in $_REQUEST; // this allows flexibility in how different sites set up location-specific instances of VuFind. // You can set persistent cookies on machines at particular locations, or you can create // custom search forms or links from certain places. } else if (isset($_REQUEST['homeLibrary'])) { $_SESSION['homeLibrary'] = $_REQUEST['homeLibrary']; // If setting did not come from a cookie, we should store one so the setting will remain // in $_REQUEST even if $_SESSION gets cleared (for example, by a user logging out) // and the GET/POST parameter is no longer present. if (!isset($_COOKIE['homeLibrary'])) { setcookie('homeLibrary', $_SESSION['homeLibrary']); } // If no home library was found in the session or the request, default to all available libraries: } else { $_SESSION['homeLibrary'] = 'All Libraries'; return $_SESSION['homeLibrary']; } } Notes: 1.) It would be theoretically possible to add IP detection and mapping between the $_REQUEST case and the de wanted to allow home library to be determined by IP range. However, since there is no current demand for such left out of the prototype code above. 2.) There was some discussion of using a user's home library (as defined by ILS) to determine their setting after logged in. However, it could be very confusing for users if logging in caused their search results to suddenly cha different location-specific filtering). If we want logging in to affect the home library setting, it would only really some kind of "opt-in" setting, and that seems of marginal value at best. We're omitting the whole possibility for n Comment by Till Kinstler [ 01/May/10 ] More ideas: - individual themes for consortium member libraries, so libraries may create/configure their own user interface - ranking based on "home library": boosting of locally held (or even "available) items (the bq parameter of the di one way to do that) - integration of ILL, but we'll need to investigate what can be done here because there seem to be many different and ILL protocols out in the wild. Maybe ILL drivers like the ILS drivers? Comment by Mark Noble [ 02/Jun/10 ] Our implementation of VuFind for the Marmot Library Network has made good progress in implementing a grea support for consortia. Our consortium consists of public libraries, academics, and schools so we should be a wor Our implementation includes: Detection of library system based on a subdomain of the opac. I.e. aspen.opac.marmot.org sets up the opac for th district. This has some custom code as well as a library table which stores parameters for each system. Themes based on library system - when a subdomain is used, we optionally override the logos and add a custom page. Individual templates can also be overridden, but that feature doesn't have many users yet. Facets based on library system - when a subdomain is used, we optionally override the default facet file for VuF Detection of individual branch by IP address. We have an ip_lookup table that defines the IP address(es) that bel branch and custom code to correlate this to an entry in a location table that defines parameters for each branch. Restriction of holdings to a library system or branch. To do this, we use settings in the library and location tables default filters to the search which can't be removed by the user, and we use some of the scoping functionality bui Millennium to restrict the holdings which are shown (this could also be done by filtering the holdings list). Sorting of holdings by branch. We sort holdings based on the physical branch a user is in, the user's home branch locations, and other locations. This involves some custom coding which currently resides in our driver but could generic. We will be looking into some of the relevancy ranking ideas in an upcoming sprint. We would be happy to share any or all of this code with the VuFind community. Comment by Markus Fischer [ 17/May/11 ] We use an IP based location switcher at http://bibnet.org/vufind IP based detection in our case is very useful. We use it for individual print availability and for online availability german EZB, which affects automatically over 560 libraries without doing anything but transmitting the requesti The code is very simple. We took it straight from the language selecter. The code is documented here: http://journal.code4lib.org/articles/4438 Comment by Phil Fenstermacher [ 22/Jun/11 ] One major downside to using $_SESSION variable for libraries is that persistent URLs for search results can bre library A and send a search results page to someone at library B then they could see different content on that pag session. To keep the persistent URLs something URL based is likely better, likely using the setevn option. Comment by Demian Katz [ 23/Jun/11 ] Good point. Of course, it's okay to store the value in the session so that it persists across searches as long as it is in URLs; a solution similar to that used for VUFIND-357 might be appropriate. Comment by Demian Katz [ 27/Jun/11 ] I am attaching a patch (courtesy of Joe Thornton and the Upper Hudson Library System) which adds a library se using the "building" field in a hidden filter in the search object. This does not address the persistent URL issue d but it might be a useful starting point for others. If anyone has time to adapt the patch to take the URL issue into share! Comment by Benjamin Mosior [ 04/Apr/12 ] The Keystone Library Network has implemented rudimentary support for consortia but would really like to see s implemented for multi-ILS accommodation, institutionally-themed interfaces, cross-institutional searching, per-i authentication mechanisms, etc. For campus detection, we implemented a method for grabbing the user's library either from a variable (campus=universitynumberone) or by IP detection. I think a domain-based solution would be better. Our current implementation is at http://vufind.klnpa.org/vufind/ We have a few part-time developers who can work on this issue for the project. Should we report progress here, or would it be better to open another JIRA ticket for each component? Comment by Demian Katz [ 12/Apr/12 ] It's probably easier to keep track of components if we assign each a separate ticket. We can link issues together, component can become a sub-issue of this one. Comment by Benjamin Mosior [ 18/Apr/12 ] Sounds good. We're working on an implementation proposal for consortia in VuFind 2. We'll bring that general community, refine the points based on the feedback, and then split up the issues from there. Comment by Alan Rykhus [ 20/Apr/12 ] I've expanded on the current library patch. One thing I noticed is that the autocomplete would return snippets tha to the selected library. I also applied the $_COOKIE['location'] code to initBrowseScreen. I've attached the upda Solr.php. Comment by Benjamin Mosior [ 14/May/12 ] We've been looking into getting a well-established method for a consortial implementation in place. We'd like to discussion and take a look at what needs to be done to make this a possibility. Here's our first look (thanks to Demian for the help): https://docs.google.com/document/d/1R6zhj1JgTCzwP_1zwYk5BNnlkPCexqWhoxf944jeGjA/edit#bookmark= Comment by Demian Katz [ 17/Oct/14 ] Some new consortial functionality (currently implemented only in the XCNCIP2 driver) has been added here: https://github.com/vufind-org/vufind/pull/166 [VUFIND-933] Overdrive Integration Created: 06/Nov/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver, Record 2.2 Type: Reporter: Resolution: Labels: Improvement Joe Atzberger Unresolved overdrive Updated: 25/Apr/14 Wishlist Priority: Assignee: Votes: Major Unassigned 1 Description Overdrive APIs integration for ebook retrieval and holds. There are actually many endpoints potentially in use: https://developer.overdrive.com/apis This supplants part of the ILS Driver functionality (mainly place holds and availability checking). It requires OAuth for user account verification and downloading. Not certain how that fits w/ VuFind architecture. Comments Comment by Demian Katz [ 07/Nov/13 ] I guess there are two ways to approach this in terms of the ILS-equivalent functionality; I haven't looked at the API docs, so perhaps only one of these options is actually possible: 1.) Load MARC records for Overdrive into the main index. Create an Overdrive ILS driver. Use the MultiBackend ILS driver to allow Overdrive to coexist with the main ILS. 2.) Implement an entire module for Overdrive, retrieving search results directly from an Overdrive-provided API. Build an Overdrive driver that behaves similar to the ILS drivers but has its own more specialized API. Regarding the OAuth piece, there's no current precedent in VuFind, but this is a problem that we're likely going to need to solve for other APIs in the future, so it wouldn't hurt to sort it out now. OAuth is something I'm aware of in the abstract but haven't had to deal with yet, so I don't have specific thoughts on how to move forward... but I believe that Mark Noble has already implemented Overdrive API support in his custom VuFind 1.x fork, so perhaps if you could get hold of his approach there, it would serve as inspiration for the 2.x solution. Comment by Joe Atzberger [ 07/Nov/13 ] I am thinking (1) is preferable, since it is the only approach where VuFind controls relevance. Also, for our clients at least, they already have OverDrive MARC records in their ILS. Another option extending (1) might be (3) spider/fetch metadata from OverDrive to load into index using their metadata API. There may be financial incentive for this if MARC records represent additional cost at purchase time. OAuth will be used two ways. Initially, the library (system) account will use it to authenticate and get a token that needs to be used for subsequent requests (availability, search). Secondarily, the patron will use it to authenticate and get a token for subsequent patron-data and download requests. Performance and security will depend on VuFind's proper caching of both types of tokens. I am guessing a module/VuFind/src/VuFind/Auth/Oauth.php will need to be created. Do you think user tokens should go in a separate mysql table (oath_target, user_id, token, expire_date) or an additional row in user, maybe user.overdrive_token? The latter is quicker but the former is more extensible for other OAuth targets in the future. Comment by Demian Katz [ 07/Nov/13 ] Yes, I think (1) makes a lot of sense if practical. If we go that route, then some things to think about: Does it really make sense to create a full Overdrive ILS driver and deal with the complexity of MultiBackend (which requires special ID prefixing, etc.), or is there perhaps a different solution that can be achieved by creating a custom record driver for Overdrive records that uses custom templates and more Overdrive-specific mechanisms. For example, you could configure the Overdrive record driver to display a different holdings tab (say, holdingsoverdrive.phtml) in place of the standard ILS driver one -- I suspect that would be fairly easy. More complicated would be building out a custom AJAX status mechanism -- that would definitely be less expensive to achieve by shoehorning something into the existing ILS mechanism... obviously further cost/benefit analysis would have to be done on both approaches. Regarding Oauth, I don't think module/VuFind/src/VuFind/Auth/Oauth.php would necessarily be the right place for that -- the VuFind\Auth namespace is for modules that can be used for authentication of VuFind users. A VuFind Oauth login module might be useful in and of itself, but my understanding of this scenario is that you have a logged-in VuFind user (authenticated by whatever mechanism is in use), and you want to attach an Oauth permission to that account. In this case, I think it might make sense to build a VuFind\Oauth namespace (which might be a thin wrapper around an existing library -- I assume they exist) and handle that independently of VuFind's own authentication layer. I'd definitely like to see a separate mysql table for this rather than an additional row in user -- I think that will not only allow more flexible use of multiple Oauth-dependent APIs, but it may also be valuable for cleanup, etc. Comment by Joe Atzberger [ 07/Nov/13 ] Looks like https://github.com/fkooman/php-oauth-client is recommended by http://oauth.net/2/ Comment by Demian Katz [ 07/Nov/13 ] That library appears to be Composer-aware, so hopefully that should make integration simple. Comment by Joe Atzberger [ 07/Nov/13 ] Ah, OK, I get the distinction with the /Auth/ directory. As for the system token, it probably goes into the filecache? (To avoid the hack of creating a reserved-id-superuser-user in the user table.) Comment by Joe Atzberger [ 07/Nov/13 ] Or, conveniently, it looks like fkooman's client includes a PDO storage layer for tokens: https://github.com/fkooman/php-oauth-client/blob/master/schema/db.sql Not the prettiest (dates as integers), but if it works, I might be inclined to go with it. Comment by Demian Katz [ 07/Nov/13 ] It might get ugly trying to make two different database wrappers coexist peacefully, but it's worth investigating. Comment by Joe Atzberger [ 11/Nov/13 ] OK, I'm not sure how well it maps for other OAuth cases, but the fkooman client seems to hardcode some expectations that don't apply for Overdrive's implementation. Rolling my own right now with regular Zend HTTP client. Comment by Demian Katz [ 11/Nov/13 ] Too bad. For future reference, it also appears that there is a native ZF oauth module (though you have to include it as a separate dependency -- it's not part of the core framework): http://stackoverflow.com/questions/12942503/oauth-in-zend-framework-2 Comment by Joe Atzberger [ 11/Nov/13 ] Yeah, the "Documentation is forthcoming" note on a repo that is 7 months stale is not encouraging. Got what I need so far from HttpServiceAwareInterface and the file cache (for system token). Now the trickier patron token thing... [VUFIND-924] Use Command Pattern in search system Created: 25/Oct/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved None Issue Links: incorporate is incorporated by Updated: 16/Feb/15 Wishlist Priority: Assignee: Votes: VUFIND674 Major David Maus 0 Redesign of VF2 application structure In Progress Description Limitations of the current implementation In order to initiate a backend operation via the search system, the operation in question must be known to the search system service. The service resolves the backend name and delegates the call; thus it must know not only the requested operation but also its formal parameters. The Command Pattern [1] provides a solution to this by encapsulating the call to the backend method in a Command that is invoked by the search service. Using the command pattern executing a operation works as follows: 1. The caller creates a Command object that provides the name of the target backend 2. The caller passes the command to the service's invoke() method 3. The service resolves the backend name to a backend instance 4. The service triggers the .pre event with command and backend instance 5. The service executes the command 6. The service triggers the .post event with command and backend instance #+BEGIN_SRC php namespace VuFindSearch; class Service { // ... /** * Invoke command. * * @param Command\CommandInterface $command * @return void */ public function invoke (Command\CommandInterface $command) { $backend = $this->resolve($command->getTargetBackendName()); $this->triggerPre($command, $backend); try { $command->execute($backend); } catch (BackendException $error) { $this->triggerError($command, $backend, $error); throw $error; } $this->triggerPost($command, $backend); } } #+END_SRC The caller can check if the command was executed by calling the command's isExecuted() method and retrieve the result by calling the command's getResult() method. A command SHOULD throw a LogicException if getResult() is called before the command is executed. #+BEGIN_SRC php namespace VuFindSearch\Command interface CommandInterface { /** * Return name of target backend. * * @return string */ public function getTargetBackendName (); /** * Execute command on backend. * * @param BackendInterface $backend * @return mixed */ public function execute (BackendInterface $backend); /** * Was the command executed? * * @return boolean */ public function isExecuted (); /** * Return result of executed operation. * * @throws LogicException Command was not yet executed * * @return mixed */ public function getResult (); /** * Return search parameters. * * @return ParamBag */ public function getSearchParameters (); } #+END_SRC Listeners One implication of the command pattern is, that Listeners need to check the command class to decide whether they should activate or not. This is not a problem per-se: The search service provides interfaces for common operations (search, retrieve, retrieveBatch etc.) that listeners can check for. [1] http://en.wikipedia.org/wiki/Command_pattern Comments Comment by Demian Katz [ 25/Oct/13 ] This makes sense to me. Taking a quick inventory of the code, these are the main areas where it seems to make sense to apply this feature: 1.) The \VuFind\Solr\Writer class should use it (though I'd be in favor of keeping the Writer class as a friendlier wrapper around the Command code, and to minimize disruption of the code base). 2.) The \VuFind\Controller\AlphabrowseController and \VuFind\Controller\CollectionsController should use it for alphabrowse functionality; maybe another thin wrapper (\VuFind\Solr\AlphaBrowser) could be written to reduce redundancy between these controllers and again wrap the Command code. 3.) The \VuFind\Sitemap class would need to be adjusted to use the Command code (or, again, a wrapper, if deemed appropriate). Does this sound reasonable, and am I forgetting anything? Comment by David Maus [ 28/Oct/13 ] Sounds reasonable. The beauty of the command pattern is that in most cases you only have to replace a call to the backend by new Command() && execute() && getResult(). Then there also are the listeners: They need to instanceOf the provided interfaces. [VUFIND-674] Redesign of VF2 application structure Created: 23/Sep/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: In Progress VuFind Architecture None Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved None Attachments: components.png connector.png Issue Links: incorporate incorporates VUFIND673 incorporates VUFIND757 incorporates VUFIND924 incorporates VUFIND521 incorporates VUFIND713 Updated: 16/Feb/15 Wishlist Priority: Assignee: Votes: search.png Major David Maus 0 search.png solr- Implement Resolved Service\Search\Solr\Manager Make authentication plugins Open compatibl... Use Command Pattern in search system Open Control ILS driver through Solr index Resolved VF2 Search component Resolved Description VuFind 2.0 Roadmap Software Development Roadmap Plug-in Architecture & Related Enhancements 1. Establish a global plug-in architecture for VuFind, describe and document the code model, and review and re-factor current code for comprehensive adoption of the plug-in framework. 2. Implement a standard model for multi-library, multi-ILS VuFind environments (e.g. consortiums), built around modular connectors and supporting a broader set of ILS transactions as defined in the ILS-DI framework. Comments Comment by David Maus [ 23/Sep/12 ] Sketch of how a search could be performed on the new search model. Comment by David Maus [ 23/Sep/12 ] Detailed view of a search using a SOLR Connector. Comment by David Maus [ 23/Sep/12 ] VF components. Cross-hierarchy dependencies are marked in red or^H^Hand orange. Comment by Filipe M S Bento [ 23/Sep/12 ] David, hello, again! Congratulations and many thanks for the UML diagrams (especially for the Sequence Diagrams): it surely makes getting into VuFind 2.0 learning curve much smooth, coming from VuFind 1.x. Also many thanks for the source software to code such UML diagrams http://plantuml.sourceforge.net/, going to use and abuse it especially in Sequence Diagrams, but above all, Use Case Diagrams (http://plantuml.sourceforge.net/usecase.html). Been using Mind Mapping software (build Mind Maps of the conceptual system or parts of it), but standard UML is much better as it is more universally understood (although not so rich at a visual level as some Mind Maps could be – example of our conceptual Discovery, Access, Evaluation and Sharing service, made with MindJet, back in June 2009: https://www.dropbox.com/s/5o6bwt36x7vzthc/Anexo%203%20-%20rotate.pdf?m -- please choose "Download" --> 100% safe PDF file!). Many thanks, Filipe Comment by David Maus [ 24/Sep/12 ] Refined search model with boxed layers. Observations: 1/ Structural analogy to current classes CONFIG => PARAMS SETTINGS => OPTIONS RecordProvider => RESULTS QUERY is currently stuffed in CONFIG. 2/ SearchManager is not so much a manager but the entry point to a internal search service. We could aim to provide the VF2 search service as a standalone module. This could cover Roadmap, Plug-in Architecture & Related Enhancements, drop-in integration with Drupal based websites. It's unfortunate that as it seems no one really looked into the Roadmap since it was adopted back in 2010. Comment by David Maus [ 17/May/13 ] Fix version 2.1: The search system is done. This issue servers as anchor for major design changes in upcoming version: Params/Options/Results + Recommendations (Facets), maybe ZF2 authentication layer. [VUFIND-1043] WorldCat Discovery API integration Created: 12/Nov/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind WorldCat None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Issue Links: incorporate incorporates VUFIND1051 incorporates VUFIND1052 incorporates VUFIND1055 incorporates VUFIND1086 incorporates VUFIND1087 incorporates VUFIND1045 incorporates VUFIND1046 incorporates VUFIND1047 incorporates VUFIND1048 incorporates VUFIND1049 incorporates VUFIND1050 incorporates VUFIND1053 incorporates VUFIND1054 Updated: 24/Aug/15 Wishlist Priority: Assignee: Votes: Major Karen Coombs 0 WorldCat Discovery API - Limit result... WorldCat Discovery API - Limit result... WorldCat Discovery API Harvestable ... WorldCat Discovery API - Add better e... WorldCat Discovery API - Additional c... WorldCat Discovery API - Perform a ba... Perform an advanced search Open WorldCat Discovery API - View Search ... WorldCat Discovery API - View Full re... WorldCat Discovery API - Sort Search ... WorldCat Discovery API - Refine searc... WorldCat Discovery API - User friendl... WorldCat Discovery API - User friendl... Resolved Open Open Open Open Resolved Resolved Resolved Resolved Resolved Resolved Resolved incorporates VUFIND1056 incorporates VUFIND1057 incorporates VUFIND1058 incorporates VUFIND1122 WorldCat Discovery API - Library Hold... WorldCat Discovery API - Change outpu... WorldCat Discovery API - Access Token... WorldCat Discovery API - Add a config... Resolved Resolved Resolved Open Description This top-level ticket tracks all issues that must be resolved in order to get a baseline WorldCat Discovery implementation completed. [VUFIND-753] Index language codes in addition to/instead of language labels Created: 03/Mar/13 Updated: 26/Aug/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Import Tools None Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved i18n,, lod Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description The SOLR indexer currently translates the language codes in the MARC record into english labels at index-time. Indexing the language codes as language codes would make reusing existing data for localized language labels easier. http://www.lexvo.org/page/iso639-3/grc The lexvo project provides a dump of their knowledge base as RDF/XML which can be easily transformed into a format for localization in the frontend. Comments Comment by Demian Katz [ 04/Mar/13 ] This makes a lot of sense. Just two concerns to think about: 1.) When indexing data from multiple sources, you may encounter different language codes. Currently there are maps that convert various abbreviations to the same set of English terms; if we switch to indexing codes, we'll have to change some of the maps to transform codes into other codes. 2.) If there are any situations where facets need to be sorted alphabetically, this could cause some problems -- but of course, in a multi-lingual environment, that is already a problem. Comment by Demian Katz [ 26/Aug/15 ] See also some further discussion here: https://github.com/vufind-org/vufind/pull/413 [VUFIND-952] omit an Arabic prefix when searching Created: 02/Feb/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 1.4 Type: Reporter: Resolution: Labels: Improvement Arizona Unresolved Search Updated: 15/Oct/15 Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description We are using Vufind to search Arabic content. In Arabic we have “??” which is a prefix that is equal to “the” in English. But unfortunately it is not a separate word, it is a prefix that it attached to the beginning of words. Examples: ???? ?????? book thebook we need to omit this prefix when searching, so Vufind can retrieve both form of the word wither the word has this prefix or not. We added this prefix “??” to the stop list, but it didn’t work., I think it is due to fact that it is a prefix not a separate word. We also tried using synonym list and add each Arabic letter twice, one time alone and second time with this prefix, but it didn’t work due to the same reason (I think). Any suggestion would by highly appreciated. Comments Comment by Demian Katz [ 10/Feb/14 ] This wiki page suggests that Solr has some Arabic-specific analyzers/tokenizers available: http://wiki.apache.org/solr/LanguageAnalysis#Arabic Switching your schema to use these instead of the defaults may be helpful. Let me know if you need more specifics. I'd also recommend posting on the solr-user list if you need additional assistance -- I suspect there are others there with experience using Solr for Arabic content, and they may be able to help you better than I can. http://lucene.apache.org/solr/discussion.html Also, what data source are you using? If MARC, I would expect that prefixes are already being correctly stripped for sorting purposes, but if you're using XML indexing, you may also need to adjust the "stripArticles" routine in the XSLT support functions to support Arabic properly. I can provide more details if you need them. Comment by Massoud AlShareef [ 15/Oct/15 ] Hello, You can try Arabic VuFind at http://arkoha.maktabat-online.net/vufind2/ to test how we managed to handle Arabic Prefixes (‫ )قباوس‬and Suffixes (‫ )قجاول‬in all shapes and forms, including Lam Alif handling. We will be happy to work with Arabic libraries or portals, either directly or via local vendors, anywhere in the world, who plan to install Arabic VuFind Discovery Portal at all levels. We can provide our services in installation, configuration, customization, Arabization, and technical support. Please contact Massoud AlShareef at the following contacts: email: [email protected] Cel: 00966 505 307 267 Thanks, Massoud AlShareef, GM KnowledgeWare Technologies [VUFIND-652] Solr's MoreLikeThis does not support sharding Created: 13/Sep/12 Updated: 21/Dec/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Reopened VuFind Search 1.3, 2.0beta Type: Reporter: Resolution: Labels: Bug David Maus Unresolved None Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description SOLR does currently not support sharding in the MLT handler. <https://issues.apache.org/jira/browse/SOLR-788> Comments Comment by David Maus [ 21/Sep/12 ] https://issues.apache.org/jira/browse/SOLR-788 SOLR does not support sharding of MLT. Won't fix unless SOLR-788 is resolved. Comment by Demian Katz [ 19/Jun/13 ] SOLR-788 is resolved as of Solr 4.1, so this functionality should now be achievable. Comment by Demian Katz [ 21/Dec/15 ] Apparently there are some ongoing problems with this in Solr 4.x, but by switching to the new MLT query parser ( https://issues.apache.org/jira/browse/SOLR-6248 ) in Solr 5, and using a new enough version of Solr 5 to account for bug fixes ( https://issues.apache.org/jira/browse/SOLR-7143 ), we should finally be able to get this going after VuFind's master is upgraded to the Solr 5 line. [VUFIND-935] Extended Dismax has problems with certain operators Created: 15/Nov/13 Updated: 02/Mar/16 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 2.2 Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Major Unassigned 0 Description Starting with VuFind 2.2, Extended Dismax is supported. However, it is turned off by default because the handler has trouble with - and NOT operators (applying these operators does not exclude terms as requested but instead turns the whole query into an OR query, unless you explicitly inject AND's between all of the non-excluded terms). For example, a query like: apples oranges NOT bananas will fail, but: apples AND oranges NOT bananas should work. We have two options: 1.) Add code to VuFind to parse queries and make them work properly with Extended Dismax by injecting ANDs. 2.) Wait for the Solr community to resolve this ticket: https://issues.apache.org/jira/browse/SOLR-2649 Until this is sorted out, we should not make edismax the default search handler... but after that, we can consider it. Comments Comment by Demian Katz [ 09/Apr/15 ] Another interesting side effect of this problem: it causes bad search results if a user copies and pastes a subject heading with a -- separator in it. For example, a search for: Dime Novels -- Specimens will yield different results from a search for: Dime Novels Specimens (Again, same reason: OR is injected inappropriately). Comment by Demian Katz [ 21/Apr/15 ] Clarification on the nature of the underlying problem, courtesy of Greg Pendlebury: The edismax handler ALWAYS uses OR as the default operator, and then expects the 'mm' parameter to take effect, which is why a lot of libraries using it set 'mm' to 100% (or very high) to achieve an AND-like (or near to) effect. The linked ticket (SOLR-2649) is relevant simply because the presence of the NOT(-) operator then causes 'mm' to be ignored. The NLA is running our production Solr using the most recent patch in that ticket, which makes edismax respect the 'Qop' parameter and set the default operator to AND instead, so we are covered in both cases. Comment by Demian Katz [ 01/Mar/16 ] As of Solr 5.5.0, the above-described problems appear to be resolved. However, with this release, the OR operator does not appear to work correctly, as OR queries appear to always return zero results. (Update: Greg Pendlebury suggests that this probably has something to do with mm behavior; if mm=100%, an OR query will return no results because all optional clauses will not be matched. Further research is required). Comment by Demian Katz [ 02/Mar/16 ] Here's a commit that seems to get everything working properly: https://github.com/vufind-org/vufind/commit/f5f40e126c8e2720355a430f7734e84670990ad4 (Note that this commit is in the solr5 branch; whatever eventually gets merged to master will probably have a different commit ID). Setting mm to 0% (in combination with the existing default q.op=AND) appears to make edismax behave as desired, whether or not explicit Boolean operators are provided. However, setting mm to 0% across the board causes problems with the legacy dismax handler. Thus, code had to be added to detect which handler is in play and choose an appropriate default. (Though the default mm can be overridden with explicit mm rules in searchspecs.yaml as needed). I think this puts us in a position where edismax may be a viable default search handler, as at least in my preliminary tests, it seems to correctly support all operators without requiring any of the crazy "fail back to Lucene syntax" logic currently used by VuFind's default dismax support. This means that search results are at least as accurate as the old way, and in some cases more accurate (since you get true dismax, rather than the crude approximation we implemented using Lucene syntax). Obviously more testing is needed, but this seems to be a good step forward! [VUFIND-527] include bound-with information in the holdings template Created: 09/Mar/12 Updated: 04/Mar/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record 2.0alpha Type: Reporter: Resolution: Labels: Improvement Laura Hild Unresolved None Attachments: boundin-holdings-template.patch template.patch Wishlist Priority: Assignee: Votes: Minor Unassigned 1 boundwith-holdings- Description I suspect calling VF_Search_Solr_Results::getRecord() directly is insufficiently generic, but remediable. The documentation on driver-writing would also need to be updated, as this adds an optional key to the item array, but I'm not sure where that is. Comments Comment by Demian Katz [ 12/Mar/12 ] Do you also have a driver-specific patch to demonstrate the other end of this functionality? Is it appropriate to only have one ID in 'bound_with'? Might there be a case where several things are bound together? Would an array be better? Right now, the ILS-specific functionality is pretty tightly bound to the Solr index, so using VF_Search_Solr_Results::getRecord() in the template is probably not a terrible thing... though another possible approach would be to load the record drivers within the ILS driver itself rather than in the view, which might offer more flexibility (or, on the other hand, might be a clunkier way of handling things). As of this writing, there isn't any driver documentation for the 2.0 code yet (documentation remains incomplete until we get closer to release time, since code isn't totally stable yet); if this gets committed to trunk, we should make a note of it in documentation at that time. Comment by Laura Hild [ 12/Mar/12 ] > Do you also have a driver-specific patch to demonstrate the other end of this functionality? I have a driver. > Is it appropriate to only have one ID in 'bound_with'? Might there be a case where several things are bound together? Oh, sure. A quick check appears to indicate that this is true for the majority of our bound-withs. Nine other titles, for example, are bound in "Copper deposits of the Appalachian states". This implementation is surely biased by my lack of experience with ILSes other than Unicorn, in which bound-withs have a parent-children relationship, and whose OPAC concerns itself only with telling you the parent. See, for example, https://catalog.swem.wm.edu/Record/2908897, and select "view this record in the classic catalog" to see Unicorn. I suspect Unicorn does this, since, from the standpoint of trying to physically find what you found in the catalog, displaying all ten titles is a distraction, as * the callnumber comes from the parent, * the parent is usually the first in the binding, and * displaying one is sufficient to tell you you're looking for a bound-with. Now that I'm looking at it again, I see that Unicorn's OPAC says "bound in"; perhaps that is better terminology. Comment by Demian Katz [ 12/Mar/12 ] Thanks for the clarification -- and yes, bound-in probably makes this more clear than boundwith. Comment by Laura Hild [ 12/Mar/12 ] Updated patch; array key is now 'bound_in', the link text is Solr's title_full, produced by a function added to the record driver, getFullTitle(), whose comment should be reconciled with getTitle()'s. Comment by Demian Katz [ 12/Mar/12 ] Would it make sense to call your new record driver method getExtendedTitle, with a comment along the lines of "get full title plus extended information like author note, volume, section, etc."? Comment by Laura Hild [ 12/Mar/12 ] Should the Solr field be renamed? Comment by Demian Katz [ 13/Mar/12 ] Ahh, you make a good point there. I'm reluctant to rename Solr fields since it makes migration to new versions more of a headache. We might have to live with an inconsistency here. Comment by Jeremy Evans [ 03/Mar/14 ] We have a similar issue. our records used to be in Unicorn but we are now using Koha & the boundwiths exported from Unicorn are linked in Koha using the analytics. When the child records display in Vufind we want the location, availability status & call number of the parent to display, not that of the child record probably using a bound in : label & also a hyperlink to the parent. (a new tab on the parent records to show child records bound in that volume would also be useful) in the 773 field for the child records the parent barcode is in $o and the parent control number is in $w. which can be seen the in staff view of the records in vufind. Comment by Demian Katz [ 04/Mar/14 ] It will take some thought to come up with a suitable generic solution -- it seems that you and Steven have related (and possibly complementary) but slightly different needs. In the meantime, it might be worth starting out with a local solution to get some ideas. What VuFind version are you using? Have you tried to implement something yet? I have a few ideas, but I'll wait for more context before I go into too much detail. Very briefly: it may be possible with some ILS driver work to make "bound-in" items automatically reflect the status of their containing record. The rest can probably be achieved through template customization, though there may be trade-offs between doing some things at run time vs. at index time. It may also be helpful to turn on show_full_status in the [Item_Status] section of config.ini to allow more flexible customization of holdings display. Comment by Jeremy Evans [ 04/Mar/14 ] Thanks. We are running 1.4 on our live server but we will be doing the config for 2.2 on our test server shortly (in conjunction with a Koha upgrade) so we will look to try various options with 2.2. on the test server once we have the current functionality replicated. All of the child records have the marc leader $7 set to 'a' (monograph component part) in Koha so they should be identifiable. Comment by Demian Katz [ 04/Mar/14 ] Being able to detect child record status also opens up the possibility of creating a custom record driver for "contained" records that exhibits different behavior from the standard one -- just a matter of setting the recordtype field conditionally based on the leader during importing. I'm not sure if this is necessary or not, but it's good to know the option exists. When you get closer to implementing this, let me know if you need more assistance -- feel free to email me off-ticket if that's preferable for brainstorming purposes. [VUFIND-520] Allow users to disable autocomplete Created: 01/Mar/12 Updated: 13/Dec/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Issue Links: incorporate is incorporated by VUFIND-637 User preferences' / profile page Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Some users appreciate autocomplete; others find it annoying. Perhaps we should add a mechanism where a user can turn off autocomplete, either based on account or a cookie. Comments Comment by Eric Lease Morgan [ 01/Mar/12 ] I believe the autocorrect feature should be configurable. --ELM Open [VUFIND-511] Content Cafe reviews and summaries added to detailed display Created: 20/Feb/12 Updated: 07/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: Improvement Bill McClendon Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description ContenCafe book coves work fine. HOwever, though I se mention of reviews and summaries, I see no additions that support getting them as with the Syndetics and Guardian reviews, etc. Have they been done and just not contributed? Have they NOT been done? Comments Comment by Demian Katz [ 21/Feb/12 ] As far as I know, they have not been done. I don't have access to Content Cafe to do them myself. However, if somebody is able to do the work, I'll be happy to get it into the trunk (and provide support as needed). Comment by Bill McClendon [ 15/Mar/12 ] Demian, Fair enough. I'll see what I can do. [VUFIND-510] Email notices from MyResearch area Created: 20/Feb/12 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Issue Links: incorporate is incorporated by VUFIND-637 User preferences' / profile page Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Open Description It would be useful to have the ability to email users notices of their actions (holds/renewals/etc.) in the MyResearch area. Some people like to get confirmations in their inbox of things they have done. Adding this feature requires a few things: 1.) Add a config setting to globally enable/disable notices. 2.) Add an area of MyResearch where users can individually opt out of notices (perhaps in a granular way -- i.e. I want holds notices but not renewals). 3.) Add logic to obtain the user's email address if it cannot be automatically determined by the authentication mechanism (i.e. DB-based authentication guarantees a valid email address, but ILS-based authentication does not). 4.) Related to #3, we may want to improve the ability of some of the existing authentication mechanisms to pass email information back to VuFind. [VUFIND-512] Configurable call number display on holdings tab Created: 22/Feb/12 Updated: 23/Feb/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Minor Unassigned 0 holdings.tpl Description Currently, for each location on the holdings tab, we show the first listed call number as part of the heading of that location's information. For libraries where all items in a location have the same call number, this is fine, but in institutions where call numbers may be different, it may be preferable to show a call number on each individual item. We should probably make this a configurable option in the [Record] section of config.ini. The attached holdings.tpl shows how Luis Diaz implemented individual call number display in the classic theme. [VUFIND-500] Better RDF Export Created: 23/Jan/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 09/May/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description VuFind's current RDF export does not provide meaningful data. Perhaps we should investigate hooking up MIT's SIMILE for a more useful transformation: http://simile.mit.edu/wiki/MARC/MODS_RDFizer I tried simply taking the XSLT from the project and running it in VuFind, but unfortunately it doesn't work -- presumably it's using XSLT2, which is not supported by PHP's XSLT processor. If we go the SIMILE route, we'll most likely have to either shell out to the command line tool or wait until PHP supports XSLT2 (which doesn't seem likely in the immediate future). [VUFIND-496] Autocomplete using EdgeNGramFilterFactory Created: 17/Jan/12 Updated: 26/Sep/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 1.2, 1.3 Type: Reporter: Resolution: Labels: Improvement Vaclav Rosecky Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Minor Unassigned 1 autocomplete.tar.gz Description Attached is a patch for Autocomplete in vufind using EdgeNGramFilterFactory (http://vufind.org/wiki/autocomplete). It uses separate solr core for autocomplete. Installation: 1) edit web/conf/autocomplete_index.ini and specify MARC files to index 2) add this two lines to web/conf/searches.ini: [SolrEdgeAutocomplete] core = autocomplete 3) run util/autocomplete.php 4) configure solr autocomplete handler in web/conf/searches.ini (use SolrEdgeAutocomplete for Title, JournalTitle, Author and Subject search): [Autocomplete_Types] Title = "SolrEdgeAutocomplete:title,author,author_title" JournalTitle = "SolrEdgeAutocomplete:title" Author = "SolrEdgeAutocomplete:author" Subject = "SolrEdgeAutocomplete:subject" CallNumber = "SolrCNAutocomplete" ISN = "SolrAutocomplete:ISN:isbn,issn" tag = "TagAutocomplete" Comments Comment by Eoghan Ó Carragáin [ 18/Jan/12 ] Hi Vaclav, Does the EdgeNGramFilterFactory approach have a performance gain (or other benefit) over the existing VuFind autocomplete implementation? Cheers, Eoghan Comment by Vaclav Rosecky [ 24/Jan/12 ] Yes, advantages are: 1) better performance (EdgeNGramFilterFactory is optimized for wild card queries) 2) better relavancy in our case 3) wild card queries (query "bec sam" is expanded to "bec* sam*") You can test it on our vufind installation (https://vufind.mzk.cz/). [VUFIND-487] Export MARC records from Solr Created: 20/Dec/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind CLI Tools None Type: Reporter: Resolution: Labels: New Feature Oliver Goldschmidt Unresolved None Attachments: Updated: 25/Apr/14 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 solrdump.php Description Here is a script, that should export all MARC records from a Vufind Solr index. It takes the fullrecord fields and stores the content as MarcXML. Perhaps this script can help anyone. Comments Comment by Demian Katz [ 23/Jan/12 ] Mark Triggs' MARCgrep tool might also be of interest: https://github.com/marktriggs/marcgrep It adds search capabilities to the export process, though since it's written in Clojure it requires more work to get up and running than the attached PHP script. [VUFIND-474] Call Number / Location Map Created: 10/Nov/11 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: New Feature Luke O'Sullivan Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Minor Unassigned 0 vufindCallMap.patch Description This patch allows system administrators to define information which will help guide users to resource holdings. Currently only available for the BluePrint Theme. Admistrators can use the Admin Feature to define libraries, locations, callnumbers (LOC only at present) and exceptions (to general callnumber rules). Holdings can be matched by Title, Code, PHP Regular Expression or Callnumber range. Information displayed includes: Library Level Title, Description, Address, Email, Telephone, Website, Google Map Location and Custom Map Location Level Title, Description, Website and Custom Map Call number Level Title, Description, Website and Custom Map Callnumber Exception Level Title, Description, Website and Custom Map Custom Maps should be uploaded to /web/images/maps prior to saving / updating each "level" The Get Holdings method of your driver should include a "library" identifier field - A title, code or string value which can be ascertained via PHP regular expression. [VUFIND-473] Statistics other than 'most popular' Created: 01/Nov/11 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Statistics 1.3 Type: Reporter: Resolution: Labels: Improvement Graham Seaman Unresolved None Issue Links: incorporate incorporates VUFIND-378 Track clicks on "more" expansion in f... Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Open Description Reporting on the 'most popular' searches is useful for a web site, not so much for catalogues where the statistics are for the search itself, not the most heavily used items. Repeated identical searches in a catalogue probably show failure, not success. Need to report on things like: - Search results where user does not follow any link - All distinct searches from [time period] - Facet usage per user (do some users never use them?) - Average number of searches per session etc. Some of these will probably need js to do. [VUFIND-464] Improved format determination (content type vs. media type) Created: 18/Oct/11 Updated: 07/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Import Tools None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Now that VuFind has been updated to SolrMarc 2.3.1, we have access to David Walker's mix-in indexing routines for content and media types. We should use these to rewrite the existing getFormat() indexing method for better results, and we should also add new facet fields to optionally allow separate evaluation of content vs. media. Comments Comment by Demian Katz [ 20/Jul/12 ] Some more detailed discussion of the issue: http://vufind-tech.2307425.n4.nabble.com/idle-thoughts-on-solrmarc-2-3-and-getFormats-td4025899.html Details on how the mixin architecture works: http://www.google.com/url?sa=t&rct=j&q=walker%20mixin%20format%20solrmarc&source=web&cd=1&ved development%2FuP-cdvs7SbQ%2FAbPEcFDVcD0J&ei=oUAJUIi0IYLg0QGHscmGBA&usg=AFQjCNHgHW Comment by Demian Katz [ 23/Jul/12 ] Some aspects of the current default format determination that are less than ideal (courtesy of Ellen R. Caplan): --Displaying the icon for accompanying material instead of the main material. Example: a book with an accompa --Not going beyond using the 007/01 when a particular value may represent more than one type of material. Fort LP). This could be fixed by looking the positions for dimensions or speed. --Mixed Materials format. I think this format is coded as Kit which is not correct, at least according to MARC 21 [VUFIND-443] Make Public List searchable / displayable in the results list (without being logged in) Created: 23/Aug/11 Updated: 13/Nov/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch, Search Wishlist Type: Reporter: Resolution: Labels: Environment: Improvement Filipe M S Bento Unresolved community, lists no specific environment Attachments: Wishlist Priority: Assignee: Votes: Minor Unassigned 2 publist.patch Description As it is, lists marked as Public can only be found (accessed) by someone who knows their URL (e.g., /MyResearch/MyList/123), there is no way to search or browse them as with the other "social" entries, user contributed tags to records. So it is hereby proposed that lists (public) also get their way into the search box and also that in the results set (list) not only they are shown when a user has that record saved in one of them (public or private, as it is now), but also in anonymous searchs (lists marked as public, only). As an addiction displaying the list details and contents (records), could also display its owner / creator, as long as the user has agreed to his/her info being displayed (name) publicly, when creating the list, and in a step further, accessing his/her name would display his/her public lists. Please vote on this ticket if you consider it's worth implementing. Thanks! Comments Comment by Filipe M S Bento [ 23/Aug/11 ] "get their way into the search box" > perhaps not in main one, but in Advanced Search or in AlphaBrowse. PS: prior to posting this ticket I've searched for previous related entries (found none); please do apologize if somehow duplicates a previous ticket. Filipe Comment by Demian Katz [ 24/Aug/11 ] It might be worth implementing a recommendation module that displays lists related to the current search... as well as a full-fledged VuFind module for browsing lists in other ways. Comment by Filipe M S Bento [ 25/Aug/11 ] Right on the spot, that's really a great idea (as always), Demian! Thanks! Comment by Demian Katz [ 19/Jul/12 ] The attached publist.patch file is a proof of concept from Filipe showing how public lists could be exposed through the existing browse module. Comment by Demian Katz [ 20/Jul/12 ] I just corrected a small typo in the patch. Also, for future reference, here are some alternate translations of the new language file line (again, courtesy of Filipe): web/lang/pt.ini ++++ PubList = Listas Públicas web/lang/de.ini ++++ PubList = Öffentliche Liste web/lang/fr.ini ++++ PubList = Liste publique Comment by Filipe M S Bento [ 20/Jul/12 ] Well, to be fair, courtesy of Google Translator, but with triple check (translating back to English) and perform some searches on the web to se if they were ok… hope so, if not, “natives” of those languages please do correct the terms. Sorry but JIRA cannot accept Chinese characters… have that translated too (Chinese are great market players right now in Portugal … we shall always have Macau as the perfect bridge between two culture so different and yet came out something so beautiful out of it (well, now it’s Las Vegas of the orient, nevertheless… http://en.wikipedia.org/wiki/Macau > “first and last European colony in China” … in fact it was never considered a colony per si, but a land of common interest for both sides, Hong Kong was a much different complicated process -- we even offer a new grant airport that it was inaugurated, if not in mistake, when the handover to China was done, amongst other important infrastrures – gambling taxes paid them all – and China carried on and now it’s even more of a reference for having a good time – many people come from China mainland just for the Macau’s attractions / tourism… ah… and the law there still remains with some Portuguese basics… one of the most light in the world – too light for my taste, if I may say so… and the same happens in East Timor). Sorry about all these non VuFind related facts. Comment by mschwendener [ 12/Nov/13 ] Not what you propose, but an impressive way to show the user lists marked as public: http://catalogue.nla.gov.au/Help/Lists?sort=sort_date_desc. I especially like the link to the RSS feeds to keep me updated of new items added to an existing list or new public lists added. Comment by Demian Katz [ 13/Nov/13 ] That is definitely a useful model, though ideally it would be nice if lists were searchable as well as browsable. Maybe there is a way to search them, but I didn't see it. I could imagine some plug-ins related to this: a recommendation module for searches that pops up list titles/descriptions that match the current search, as well as a related record module that shows "lists containing this item." [VUFIND-428] Problems with wildcards inside phrases Created: 02/Aug/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Updated: 15/Nov/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description When users perform a search that is not supported by Dismax (i.e. with wildcards), VuFind does an old-style Lucene query where it builds lots of weighted clauses to try to get the best results at the top of the list. One of the strategies is to create a phrase search with a very high weight so exact phrase matches show up first. This is done even if there is just one word in the query, resulting in something like: "te?t"^1000 OR te?t^100 (vastly simplified to make the example more clear) The problem is that wildcards do not work inside phrases... so "te?t" gets tokenized into "te t". Because the phrase gets the highest weight, results with "te" get weighted higher in the list than results that actually match te?t. There are several possible fixes for this problem: 1.) Don't double-quote single words. That won't solve the whole problem, but it will get rid of some edge cases. 2.) Implement support for Extended Dismax - once we upgrade to Solr 3.x (see VUFIND-260), we'll have access to eDismax, which supports wildcards... and thus we eliminate the need for the old Lucene code in a wider range of cases. 3.) Install the handler that can process wildcards inside phrases (see https://issues.apache.org/jira/browse/SOLR-1604 ). Add code to make sure that the phrases in the Lucene queries we construct are handled by this new parser. (Disadvantage: as of this writing, this handler is still not a standard Solr feature -- probably best not to rely on an unsupported patch). Actually, it wouldn't necessarily be a bad idea to do all three of these things, since they're somewhat complementary to each other, though each makes improvements on its own. Comments Comment by Demian Katz [ 29/Aug/13 ] Fix #1 is implemented here: https://github.com/vufind-org/vufind/commit/f943a0e971c8f26f27b4d0b51e4fedc5635cf7b0 This will be in place for release 2.2. Obviously it is only a partial solution, but it does solve the "te?t" case. Comment by Demian Katz [ 15/Nov/13 ] Fix #2 is partially available as of 2.2 as well -- edismax can now be turned on as an option, but because of VUFIND-935 it is off by default. [VUFIND-385] Incorporate Mendeley API results in VuFind Created: 23/Feb/11 Updated: 14/Jun/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search, Summon None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Minor Unassigned 1 mendeley.patch Description The Mendeley API ( http://dev.mendeley.com ) can be used to find information about citations and related articles. This seems useful for enhancing Summon results (i.e. offering a "Similar Items" section on the record view). The attached patch is a very simple proof-of-concept implementation; this can probably be expanded to enhance other parts of VuFind as well. Comments Comment by Demian Katz [ 14/Jun/11 ] For future reference -- a line for the pt.ini file: View Mendeley Record = "Ver registo Mendeley" [VUFIND-379] Investigate EasyBib integration Created: 02/Feb/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Updated: 02/Feb/11 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description The free EasyBib citation management system has an API: http://www.easybib.com/developer/citation-api-documentation This should be fairly straightforward to integrate as a new export option (similar to RefWorks), and it might also be useful as an alternative/expansion to the existing "Cite This" functionality. It could be particularly helpful in adding citation functionality to the Summon module (see VUFIND-192). [VUFIND-378] Track clicks on "more" expansion in facets Created: 01/Feb/11 Updated: 01/Nov/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Statistics, User Interface None Type: Reporter: Resolution: Labels: Improvement William Denton Unresolved None Issue Links: incorporate is incorporated by VUFIND-473 Statistics other than 'most popular' Open Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description When there are too many results in one facet to fit, there is a "more" link that when clicked expands that facet listing to show the rest of the results. How many people click on "more"? It would be nice to have VuFind register how many clicks "more" (and "less") get, so people can track usage. Knowing how facet listings are use will help improve the user interface. Perhaps some facets are expanded more than others. Who knows? We would with this feature! Comments Comment by Demian Katz [ 02/Feb/11 ] Every theme includes a moreFacets() function used to expand the facet list -- it would be relatively straightforward to add an AJAX call here to log clicks either to a MySQL table or the Solr statistics index. The only tricky part is making it configurable -- it would be nice to be able to turn the logging on or off via config.ini, but passing that value all the way through to the Javascript might get convoluted. Perhaps this is better left as a local modification for now... but if somebody wants to share a patch for this ticket, that's certainly the best place to start! [VUFIND-331] Additional list permissions Created: 23/Sep/10 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 23/Sep/10 Wishlist Priority: Assignee: Votes: Minor Unassigned 2 Description Right now, we have two list permissions: private (only owner can view/edit) and public (owner can view/edit, others can only view). It might be useful to add at least one more level: public and editable by all. [VUFIND-330] Track and display list creation/edit dates Created: 23/Sep/10 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 23/Sep/10 Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description It would be useful to know when lists were created and last updated. It might make sense to have a user preference to control whether or not this information is displayed for a particular list. [VUFIND-329] Next/previous browsing for user lists Created: 23/Sep/10 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 23/Sep/10 Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description Now that we have "next/previous" links for search results (see VUFIND-25), it would be useful to have similar functionality for user-generated lists. [VUFIND-326] Comment spam filtering with Akismet Created: 21/Sep/10 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Updated: 09/Mar/12 Wishlist Priority: Assignee: Votes: Minor Kun Lin 1 Description It may be worth investigating integration of the Akismet API for comment spam filtering (see http://akismet.com/). Comments Comment by Kun Lin [ 21/Sep/10 ] http://www.achingbrain.net/stuff/php/akismet In this webpage, there are solutions that are very easy to compile into Vufind. It is a PHP5 class. You just need to get the code "require_once" and have those information submitted as described on that webpage. I think no more than one hour programing. Comment by Demian Katz [ 22/Sep/10 ] Yes, it looks pretty straightforward. A few ideas that might be worth keeping in mind when integrating this: 1.) Since this requires a WordPress API key to function, we'll have to add a new section to config.ini. Maybe something like this: ; This section is used for spam filtering. Filtering is off by default, but you can use Akismet to ; filter comments by uncommenting the comments line and filling in a valid WordPress API key. [Filters] ;comments = Akismet:WordPressAPIKey It's probably a good idea to design the architecture so that it is easy to plug in other options outside of Akismet. 2.) It might be worth figuring out what happens if the Akismet API is down for some reason. How should we respond to outages? Will we just accept all comments, or do we need to build some kind of queue? 3.) What do we do with rejected comments? Should we store them somewhere for administrative review so that false positives can be allowed by an administrator and sent to the "submitHam()" method? Comment by Kun Lin [ 22/Sep/10 ] Hi, I think it is truth that we need to figure out a way to do Plug-In. I even think of can we borrow Plug-in Structures of something else such as Wordpress or Drupal. Or maybe we could rebuilt the Interface to Drupal or Wordpress, so that make it even easier to do plug-in. For the second concern, I think we need a separate page in /Admin to list all the comments and tags there. All the comments will be listed on that page, but of course, SPAM and normal will be in the separate list. In case Akismet API goes down, all the comments will be stored there on that Admin page and waiting for the API to back up. Or librarians can manually approve or disapprove those. Since SPAM also listed on that page, in case false positive, librarian can override the result on that webpage. I think to do all these, it might take about three or four hours maximum. Comment by Demian Katz [ 22/Sep/10 ] Your ideas sound good to me. I have just added you to the "developers" group in JIRA, so if you have time to work on this and want to assign the issue to yourself, you are now able to do so. Regarding your thoughts on plug-in architectures, this is definitely something we should discuss in more detail -- it's probably worth starting a new thread on vufind-tech to work through some of the possibilities. Comment by Demian Katz [ 09/Mar/12 ] See also VUFIND-526. [VUFIND-295] Perform VuFind searches in response to Z39.50 protocol requests Created: 27/Jul/10 Updated: 24/Sep/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Reopened VuFind Search None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 2 Description Add the ability for VuFind to respond to Z39.50 search requests. Comments Comment by Demian Katz [ 18/May/11 ] For future reference: Z39.50 specification - http://www.loc.gov/z3950/agency/document.html Existing Z39.50 software - http://www.loc.gov/z3950/agency/resources/software.html Comment by Filipe M S Bento [ 18/May/11 ] :: EDIT :: Comment moved to the proper entry, http://vufind.org/jira/browse/VUFIND-122 (consume, not provided z39.50 services) Comment by David Maus [ 23/Sep/12 ] I would call this a Won't Fix: AFAIK z39.50 is not based on HTTP transport. In order to support z39.50 /requests/ we would have to implement an entire z39.50 server -- in PHP. No way. Comment by Filipe M S Bento [ 23/Sep/12 ] David, hi! Yes, native Z39.50 would require a gateway (but there are plenty out there) to do the S&R and then we would need to parse the results. But, that is gone by now: please refer to http://vufind.org/jira/browse/VUFIND-122 (mentioned above): Z39.50 via a SRU/SRW service like, lets say, using PazPar2 "passe par tout" (French). Thanks, Filipe EDIT: for the record Christopher Hallberg (V.Univ) and Mohan Pradhan (HealthNet Nepal) are already working in implementing a Pazpar2 module for VuFind 2.0 (ZF2), as mentioned by Demian in this e-mail: from: Demian Katz [email protected] via lists.sourceforge.net sender-time: Sent at 1:24 PM (UTC). Current time there: 12:30 PM. to: Hugo Agud <[email protected]>, vufind-tech <[email protected]> cc: Christopher Hallberg <[email protected]>, "[email protected]" <[email protected]> date: Fri, Sep 21, 2012 at 1:24 PM subject: Re: [VuFind-Tech] Developing Vufind: Sponsoring Comment by David Maus [ 24/Sep/12 ] Hi Filipe, Okay, so I call it a won't fix, superseded by VUFIND-122. Comment by David Maus [ 24/Sep/12 ] Superseded by VUFIND-122 Comment by Demian Katz [ 24/Sep/12 ] There is a lot of confusion between this ticket and VUFIND-122. They are not intended to track equivalent functionality. This ticket is about VuFind being able to respond to Z39.50 requests. (PROVIDER functionality). VUFIND-122 is about VuFind being able to present results retrieved from a Pazpar2 system. (CONSUMER functionality, which may or may not be using Z39.50 somewhere under the hood; Pazpar2 is a generic federated searching environment). As a result, I am reopening this ticket. There may still be a need for a VuFind system to respond to Z39.50 requests. I understand that this is a non-trivial task; that is why this is on the wishlist rather than assigned to a particular version. I also don't advocate attempting to write a Z39.50 server in PHP -- if this problem really needs to be solved, it may need to be done by writing connectors for an existing third-party system. Perhaps what we need is not new VuFind code but rather a recipe for combining existing tools. In any case, until some kind of solution is devised, I'm going to leave this open for tracking comments on the problem. I am also renaming both tickets in an effort at improving clarity. Comment by Filipe M S Bento [ 24/Sep/12 ] Demian, David, hi! Yes, I knew that once, the diference between these two tickects but totally forgot about so that’s why I linked both. Yes, I remember this one was about providing z39.50 support (make available VuFind index to be searched via external clients using z39.50 protocol). This would be great for a lot of purposes, mainly to use within our official (UA) reference manager software, Thomson Reuters’ EndNote, to perform queries in our local VuFind (or others) within it, and retrieve the desired records, as the other integrated local sources, besides the OPAC, do not offer such capability (DSpace and OJS – but they do allow export to Endnote). Making a simple google search, https://www.google.pt/search?q=z39.50+solr, one finds at the first entry, although from 2008, a possible way to do it; I mean it’s better to connect the service to SOLR than to a VuFind layer over it, right? Thanks and sorry, but I totally forgotten about the purpose and difference of these two tickets; their new name make much easier to identify their purpose. Filipe EDIT: and I see that I've placed that difference in my comment above, dated 18/May/11 3:05 PM... :| Thank you, Demian, for your above average (to say the least) memory! :) Comment by Filipe M S Bento [ 24/Sep/12 ] Looking at http://k-int.blogspot.pt/2008/05/exposing-solr-services-as-z3950-server.html it seems something I can actually do... just a question of remembering the Z39.50 mapping / attributes, consult its documentation. Btw Z39.50 has an ISO norm that is ISO23950 (see the resemblances? “Z” > “2”, but I believe ISO stopped at the 1998 version of it and LOC carried on developing it into the most current one, Z39.50:2003 --- althought there is also a NISO version, that I believe is the same: http://www.niso.org/standards/resources/Z39.50_Resources (the link in LOC’s page gives a 404, not available anymore). The question is just one: time and commitments made that have to honor… :| Filipe Comment by Demian Katz [ 24/Sep/12 ] Thanks, Filipe! A couple of thoughts: 1.) I wouldn't want you to waste time on this if nobody actually needs it. For now, I think this is more of a theoretical need than an actual one. If anybody really needs this, it would be helpful if they could post here and explain their use case. If nobody posts a use case, I would recommend using your time on other projects for the moment. 2.) Routing Z39.50 requests directly to VuFind's Solr index certainly sounds like an easy approach... but then you lose the benefits of VuFind's intermediate processing (record drivers, etc.). It's probably good enough for many use cases, but it may be lacking in others. Again, without a real-life use case, it's hard to comment on the best solution. And, just for the record, one possible future real-life use case: a number of libraries are going to be switching over to a new open source ILS called Kuali OLE in the next year or two. OLE does not include a user interface -- tools like VuFind will be recommended to serve as the front end. It is unclear at this point if OLE will also have Z39.50 support. If it does not, there may be a demand for support through VuFind. If it does, this may be a non-issue. [VUFIND-266] Show total author counts in code relying on author facets. Created: 04/May/10 Updated: 04/May/10 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Author None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description The fix for VUFIND-127 required us to remove total author counts from the AuthorFacets recommendations module and the Author/Search action, since Solr currently does not offer an easy mechanism for getting the total count of items in a facet list. It would be nice to eventually restore this information without bringing back the corresponding speed/memory issues. See VUFIND-127 for some useful notes. [VUFIND-240] Provide a KStemmer option for less aggressive stemming. Created: 01/Mar/10 Updated: 26/Oct/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description The default stemmer packaged with the Solr distribution used by VuFind is rather aggressive. The KStemmer is sometimes a better alternative, but it is not included with the distribution due to licensing issues. This may pose problems for including it with VuFind as well, but we should keep an eye on the situation to see if it changes and write some documentation in the Wiki in the meantime to help users add KStemmer if they want it. See notes here: http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters/Kstem Comments Comment by Demian Katz [ 26/Oct/11 ] Starting with Solr 3.3, KStemFilterFactory is included as part of the core Solr distribution. This means that, as of VuFind 1.3, it is available in VuFind with no additional configuration necessary. Whether we want to change the default settings of VuFind is subject to debate, but this is now easy to enable as a local customization by simply editing Solr's schema.xml file and replacing solr.SnowballPorterFilterFactory with solr.KStemFilterFactory. [VUFIND-755] Show the patron, which hold the item if checked out Created: 05/Mar/13 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface 1.3 Type: Reporter: Resolution: Labels: Environment: Improvement Joachim Langenbach Unresolved None Ubuntu with NGL 3 Attachments: Wishlist Priority: Assignee: Votes: Minor Unassigned 0 vufind-ngl-patron.patch Description Updated the blueprint RecordDrivers/Index/holdings.tpl to display the patron, which holds the item, if not available. Also updated the NewGenLib.php Driver, to provide the patron field in returned array from getHoldings(). It is only shown, if defined. The driver only adds the patron field to the holding results, if the config option at NewGenLib.ini show_hold_patron is set to true (default = false) and the user is logged in. Otherwise it is not added and therefore not shown. Maybe it should be moved to the vufind config and queried at the template. This feature is useful for small libraries, where the user can easily communicate with each others. Comments Comment by Joachim Langenbach [ 05/Mar/13 ] The NewGenLib.php part is based on the changes described at VUFIND-754 Comment by Demian Katz [ 05/Mar/13 ] Thanks for sharing this. Since many libraries are concerned about patron privacy, I don't expect to make this a standard feature of VuFind, but it is useful to have this patch available for those who might need it. If there is enough interest, I can spend a little time making it a configurable optional feature -- please vote if you are interested. [VUFIND-746] Support highlighting snippets on full-text fields Created: 14/Feb/13 Updated: 06/Aug/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 2.0beta Type: Reporter: Resolution: Labels: Environment: Improvement Eoghan Ó Carragáin Unresolved highlighting, All Wishlist Priority: Assignee: Votes: Minor Eoghan Ó Carragáin 0 Description As discussed in VUFIND-304, there isn't currently an easy way to support highlight snippets from full-text fields. This ticket is to track discussion & possible solutions. Solr's highlighting requires the field to be stored which causes the following issues: 1) Solr doesn't have a way to exclude a field from the Solr response. It only allows you to specify all the fields you want, or default to getting them all (i.e. *). Vufind doesn't currently specify fields, so all stored fields are returned. With full-text fields returned, decoding the solr response can cause PHP to run out of memory. This is the main blockage to support full-text highlighting in Vufind at present. 2) Storing full-text fields will increase the index size 3) Highlighting long text fields in Solr can impact on performance Possible approaches: 1) The SOLR-3191 ticket tracks a request to allow fields to be excluded from the fl parameter. There is some discussion but no patch yet (please vote it up ;)). This would definitely be the best solution once it makes it into Solr. As Demian says in VUFIND-304, we could hard-code the fl value or perhaps make it a configurable array in one of the ini files. Perhaps overriding fl arrays in different contexts will be easier with the search module refactor in Vufind 2.0? 2) As noted in VUFIND-559, Solr 4.1 stored field compression results in a 30% - 40% reduction in stored field size in the index 3) Since Solr 3.1, the highlighting component has supported the hl.useFastVectorHighlighter parameter which improves highlighting performance for fields which have the following options set in their schema.xml definitions: termVectors=on, termPositions=on and termOffsets=on. This may be useful for non-fulltext fields like title too. Comments Comment by David Maus [ 15/Feb/13 ] > Perhaps overriding fl arrays in different contexts will be easier with the search module refactor in Vufind 2.0? The refactored SOLR Connector class provides a method to modify query invariants, i.e. parameters that are use Connector::getQueryInvariants() Connector::setQueryInvariants() Connector::addQueryInvariant() I pushed https://github.com/vufind-org/vufind/commit/3b82de51a840152202af1697631b746de628795a that mak Comment by Eoghan Ó Carragáin [ 15/Feb/13 ] Great. Thanks, David! Any thoughts on the best way to decide which fields to request in different contexts? For example, for the main r recommendation module we don't need any fields returned (only facet values). Should the fl array be hardcoded hardcoding values may be a problem as the schema is extended. Comment by David Maus [ 15/Feb/13 ] > Any thoughts on the best way to decide which fields to request in different contexts? Not yet. I think the question should be rephrased as: What defines a context that requires a change in the returned Could this context be the matching route or a part of the URL path component? E.g. `Search/Home' vs. `Search/R Comment by Eoghan Ó Carragáin [ 15/Feb/13 ] Yeah, something based on the path/route is probably the most useful way to distinguish different "contexts". Sea AJAX/JSON_Vis.php and AJAX//JSON_GoogleMap.php could have their own fl values too. It still sounds like it could get complicated and/or messy but I really haven't looked at the 2.x code yet, so maybe Comment by Demian Katz [ 15/Feb/13 ] If SOLR-3191 gets implemented, that's really the best solution: we never want to retrieve the fulltext field in any I can't think of any solution involving a whitelist that doesn't get ugly -- not only is it very complicated to figure major obstacle to customization and growth. Using a previously-unused field or adding a new custom field will f likely volume of new support requests) outweighs the value of full text highlighting for me. (Not that I fail to see seems too high). Comment by Eoghan Ó Carragáin [ 15/Feb/13 ] One option might be to do the whitelisting as part of the requestHandler setup in solrconfig.ini, i.e. add default fl fulltext (and maybe spelling). It still would need to be kept in sync with changes to schema.xml, but it may be si easier to document both on the wiki and in comments: "Note: when add or removing stored fields from schema.x already do this for the More Like This Handler. In any case, hopefully SOLR-3191 will solve this eventually. Comment by Demian Katz [ 15/Feb/13 ] That might help... but it's not ideal. My biggest concern is that this approach completely cancels out the benefits anything without hacking Solr configurations, and then that becomes an upgrade headache, etc. So essentially it' I suppose this could become a recommended best practice, though -- if we post a patch here showing how to imp here when they ask about full text highlighting and they could apply the patch, fully understanding the conseque I just don't see this becoming a standard feature until SOLR-3191 is resolved. Comment by Eoghan Ó Carragáin [ 15/Feb/13 ] Everyone get voting on SOLR-3191 then ;) Yes, this ticket should serve as a starting point for anyone who really needs this feature before then. If I experim Comment by Demian Katz [ 15/Feb/13 ] Definitely. And here's the link for everyone's convenience: https://issues.apache.org/jira/browse/SOLR-3191 My vote is in. Comment by Eoghan Ó Carragáin [ 16/Feb/13 ] Solr 4.x actually helps here too because of the addition of fl wildcard matching with SOLR-2444: Step 1) Add this to the "dismax" and "standard" request handlers in solrconfig.xml: <str name="fl">a*,b*,c*,d*,e*,first_indexed,format,fullrecord,g*,h*,i*,l*,o*,p*,r*,s*,t*,u*,*_date,*_date_mv,*_isn, This returns all fields defined as stored in the default Vufind schema.xml as well as any dynamic fields which fo field names start with an "f", we have to explicitly enumerate the other stored fields that start with an "f" that we to exclude spelling and spellingShingle, especially if using fulltext fields to build the spelling index. This would returned. I also omitted "m*" since the only stored field starting with "m" is marc_error which we don't need to d Step 2) Ensure Vufind isn't overriding the fl parameter. In Vufind 1.x this was just a case of commenting out "$o /web/sys/SearchObject/Solr.php. I'm not sure of the equivalents in the VF 2.x code Once we have a working Solr 4.x Vufind, I think this approach might be simple enough to include in trunk befor non-dynamic fields which start with "f" or a letter not already in the list above (I suppose we could include the e things more straight-forward for anyone who needs this feature. Comment by Eoghan Ó Carragáin [ 16/Feb/13 ] There is also a creative approach discussed: http://lucene.472066.n3.nabble.com/fl-wildcards-tt496113.html#a49 Do a lookup of the solr /luke request handler to get a complete list of fields in the index & use this to build the fl when is the request made to /luke (at Vufind startup?), where is the fl array cached & how does the SearchObjec Comment by Demian Katz [ 16/Feb/13 ] Yeah, the /luke idea has come up before, and seems like too much overhead. But your wildcard approach is a go catch everything with an underscore in it? Comment by Eoghan Ó Carragáin [ 16/Feb/13 ] quite possibly. I'll try it out Comment by Eoghan Ó Carragáin [ 16/Feb/13 ] Yes that works. The only problem is that it will also bring back fulltext_unstemmed which is probably the fulltex <str name="fl">a*,b*,c*,d*,e*,first_indexed,format,fullrecord,g*,h*,i*,l*,o*,p*,r*,s*,t*,u*,*_date*,*_isn*,*_str Comment by Demian Katz [ 17/Feb/13 ] Actually, I don't think you would want to highlight on fulltext_unstemmed. Highlighting uses the stored values, fulltext field: this would still show the full unstemmed words, but it would also highlight matches based on stem where you found a match but no snippet appeared. Comment by Eoghan Ó Carragáin [ 17/Feb/13 ] Right, ok. Then this should cover it: <str name="fl">a*,b*,c*,d*,e*,first_indexed,format,fullrecord,g*,h*,i*,l*,o*,p*,r*,s*,t*,u*,*_*</str> Or this if we want to exclude the spelling fields: <str name="fl">a*,b*,c*,d*,e*,first_indexed,format,fullrecord,g*,h*,i*,l*,o*,p*,r*,series,series2,t*,u*,*_*</str> [VUFIND-745] Investigate whether Vufind's spellcheck can be simplified by new Solr 4.0 features Created: 11/Feb/13 Updated: 17/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Environment: Improvement Priority: Eoghan Ó Carragáin Assignee: Unresolved Votes: Search,, SearchObject, Spellcheck,, Spelling All Wishlist Minor Eoghan Ó Carragáin 0 Description Solr 4.0 has some new spellcheck features which may allow us to simplify Vufind code and configuration: === WordBreakSolrSpellChecker === "A parallel implementation, WordBreakSolrSpellChecker offers suggestions by combining adjacent query terms and/or breaking terms into multiple words. It can detect spelling errors resulting from misplaced whitespace without the use of shingle-based dictionaries and providess collation support for word-break errors, including cases where the user has a mix of single-word spelling errors and word-break errors in the same query. The spellchecker can be configured with a traditional checker (ie: DirectSolrSpellChecker). The results are combined and collations can contain a mix of corrections from both spellcheckers." This may allow the SearchObject code to be simplified by combining the existing "basicSpelling" and shingle spellcheck, & by eliminating the second call to Solr. === DirectSolrSpellChecker === "The DirectSolrSpellChecker uses terms from the Solr index without building a parallel index like the IndexBasedSpellChecker. It is considered experimental and still in development, but is being used widely. This spell checker has the benefit of not having to be built regularly, meaning that the terms are always up-to-date with terms in the index." This would eliminate the need to build spell indexes More information here: http://lucidworks.lucidimagination.com/display/solr/Spell+Checking http://wiki.apache.org/solr/SpellCheckComponent Comments Comment by Eoghan Ó Carragáin [ 11/Feb/13 ] linked VUFIND-745 to VUFIND-559 Comment by Demian Katz [ 15/Feb/13 ] The WordBreakSolrSpellChecker sounds very promising. It would be interesting to come up with some example queries and compare results between WordBreakSolrSpellChecker and the existing VuFind approach. Has anyone tried this yet? I'm less enthusiastic about the DirectSolrSpellChecker; while this offers convenience by eliminating the need for a separate spelling index, it also has some significant limitations (for example, I believe that it won't suggest any terms that don't match the first letter of the search query, so things like c/k errors or transposed-first-two-letters errors won't yield good suggestions). Comment by Eoghan Ó Carragáin [ 19/Feb/13 ] I'll try to do some comparisons between WordBreakSolrSpellChecker and the existing VF approach. I agree, this is the more promising of the two. Re DirectSolrSpellChecker, do you have a link that discusses the limitations etc. I couldn't find anything. As you say, the separate spelling index isn't a big inconvenience. Comment by Demian Katz [ 19/Feb/13 ] Thanks for investigating this. I couldn't find a link discussing DirectSolrSpellChecker limitations -- I heard about them in a presentation at Code4Lib. However, a bit of googling did reveal this code snippet from the spell checker: /** * Sets the minimal number of initial characters (default: 1) * that must match exactly. * <p> * This can improve both performance and accuracy of results, * as misspellings are commonly not the first character. */ public void setMinPrefix(int minPrefix) { this.minPrefix = minPrefix; } This implies that, at least by default, the first character must match; I'm not sure if there is a way to set this to zero or if 1 is the minimum value. Comment by Demian Katz [ 19/Feb/13 ] Courtesy of Erik Hatcher, here is some more detail on the DirectSolrSpellChecker limitations: https://issues.apache.org/jira/browse/LUCENE-4500 [VUFIND-736] Improve security of non-SSL password submissions Created: 11/Jan/13 Updated: 11/Jan/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description We should evaluate the possibility of using a more secure password submission mechanism in AJAX-capable browsers in case of non-SSL connections (for example, see http://ajaxpatterns.org/Direct_Login ). VuFind does not currently use AJAX for all password submissions. Some passwords are currently submitted by a standard HTTP POST operation. However, this POST is not very secure unless it is combined with an SSL connection. The AJAX hash submission design pattern is one way of making a non-SSL password submission more secure. It may or may not be appropriate for use in VuFind (one big downside is the fact that it requires Javascript in order to function). The main question is whether it's worth adding support for a JS-based security enhancement or if it's better to simply state that VuFind should run behind SSL as a best practice. Feel free to weigh in on the issue here. This topic was originally part of the VUFIND-340 ticket (which now refers only to password storage issues); it has been split off for clarity. [VUFIND-726] Enhance Alphabetical Browse to work for consortia Created: 11/Dec/12 Updated: 01/Aug/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Browse None Type: Reporter: Resolution: Labels: Improvement Alan Rykhus Unresolved None Attachments: Issue Links: Wishlist Results.php Priority: Assignee: Votes: Minor Unassigned 1 alphabetical_browse_20130215.tgz incorporate incorporates VUFIND-863 extra columns in alphabrowse Resolved Description I'm updating the alphabetical browse to work for consortium. Currently the browse list is for every record in the Solr database. In a consortium setting, the individual libraries want to only see the entries fro the records that belong to their library. To add this functionality I've added a field to the sqlite database that contains any entries from the building field in the Solr database. In my case, these are the codes for the libraries and sublibraries in the consortium. I also create a default entry with a string value of 'null' for each record. This is so you can browse the entire database. Comments Comment by Alan Rykhus [ 11/Dec/12 ] I have most of the work for this done. To implement I've had to modify: 1. sys/Solr.php 2. interface/themes/classic/AlphaBrowse/home.tpl 3. services/AlphaBrowse/Results.php 4. Pretty much all of the java code at https://github.com/marktriggs/nla-browse-handler To build the database I am only using an enhanced version of the StoredFieldLeech class. When getting the list of headings I also need to get the building field from the database. While I am using the building field, the field is passed as a BUILDFIELD parameter, so you could use a different field fro the schema to populate the building field. The sqlite database was easy to build, retrieving the results is a different story. I could no longer just jump ahead x number of entries. To accomplish the jumping around, I include the first or last entry in the current browse list to seed into the database. This means that the first or last entry is duplicated in the next list. I have this working for all of the databases but the title browse. The problem there is that the heading and key entries are different, so the seed doesn't work. I also plan on adding a title field to the call number browse entries. I see no value in only displaying the call numbers. Comment by Demian Katz [ 12/Dec/12 ] Have you talked to Mark about your Java changes yet? He might have some useful feedback on your implementation and outstanding issues... and it's also worth talking to him about getting this stuff into the official Git repo if it can be introduced as an extra option without breaking the standard default behavior. Comment by Ere Maijala [ 30/Jan/13 ] Would it make sense to do the filtering in the Solr plugin instead of trying to handle it in VuFind? Filtering the list at the source would remove the need for the special jump handling. Comment by Alan Rykhus [ 30/Jan/13 ] The problem with filtering things later is how many results do you have to return from the sqlite db? The sqlite db is pre-sorted on the browse field. The special jump handling is not really a problem with the additional column in the db. I just get the next x number of entries that match the new column. I have this working for our consortial site and I installed it yesterday in a nonconsortial site. In the non-consortial site the additional column has the same value for every entry, null. The only major difference is that I use the StoredFieldLeech class in all instances to build the db. I have talked to Mark. He's willing to store the new code in his GIT repo. I will attach a tarball to this ticket shortly. I will then set things up so he can grab the new code. The one thing I have left to do is to normalize the seed string that is passed in for callnumber browses. This will be done in the php code. Comment by Demian Katz [ 15/Feb/13 ] Uploading customizations courtesy of Alan Rykhus (alphabetical_browse_20130215.tgz). Comment by Mark Triggs [ 28/Apr/13 ] Hi all, I've merged Alan's changes into a branch here: https://github.com/marktriggs/nla-browse-handler/tree/consortial_browse From my point of view, these changes can become 'master' whenever you're ready to make the corresponding changes on the PHP side. Just say the world and I'll hit the button :) Comment by Demian Katz [ 06/May/13 ] Do the changes break the existing PHP code? Is it possible to set this up so that the new functionality can go into the browse handler first, and then support be added to PHP later? Otherwise I fear we'll end up with even more confusion around people compiling handlers and then running into incompatibilities with various versions of VuFind. I'm also curious about the new building and bLimit parameters of the browse handler. Is bLimit hard-coded to make use of the building field in Solr? If so, would it be better/safer/more flexible to implement a generic fq parameter in the handler and let VuFind construct the specific filter query necessary? Finally, it seems like there are several different things going on here: call number normalization, filtering by location and displaying extra fields (and perhaps some other things as well). Some of these appear to be MnPals-specific (like the use of $_COOKIE['location']) while others are more generic. I wonder if this can be broken up into a few individual patches to make the version history cleaner and porting forward to 2.0 simpler. Unfortunately, I don't have time to tackle all of that right now, but if anybody is able to help digest this into bite-sized chunks, that would help me get everything committed faster. Comment by Ere Maijala [ 07/May/13 ] As far as I can see, it will break existing PHP code. My version (https://github.com/KDKAlli/nla-browse-handler/tree/solr4) of this is more generic in that it allows any field to be used as a filter and doesn't require a building mapping in config, but it's not quite compatible with the old PHP code. If you guys think it would be useful, I can try to find time to add support for the existing PHP code and Solr 3, but if you want to go with Alan's version, I'm ok with that. Comment by Alan Rykhus [ 07/May/13 ] Hello, Will the new java code break existing PHP code? My first response was yes, but after thinking for a while, I don't think so. The actual sqlite3 database still has the same basic structure. I will take a look at it a little deeper. As for the location cookie, that is some special code I use to limit results to specific library. If you look at the code, you will see that if the cookie does not exist, and the code tests for that, it will not pass in a value and you will get your normal results. It is based on a patch that is around somewhere. Using a cookie is not really my favorite way to keep track of the selected library. Demian, you are right in that I did add call number normalization and displaying extra fields. I'm not sure I would want to make smaller patches, that would mean rewriting the code 3 times just to get the patches. As well as the PHP code, It effects the java code and the import process. I had added a couple of more comments, but I will look at Ere's code first before adding any more comments. al Comment by Demian Katz [ 07/May/13 ] Thanks for looking into the compatibility -- it will be helpful to hear what you find. Regarding the location cookie, I think that originates in a patch on VUFIND-180. I agree that it's not a great solution; in VuFind 2.0 land, it seems like the trend is going to be URL-based location filtering (e.g. each location gets its own subdomain and corresponding configuration). I agree that it's more work to create a whole bunch of different patches -- but since this is all going to have to be ported to 2.0, it would be easier to do that one feature at a time and commit them separately. If somebody has time to do that work, it would be great to get it as separate independent patches (perhaps a patch-series). If it eventually comes down to me to do it, that's the approach I'll take. If there are any other specific details in there I should know about, please let me know. Comment by Alan Rykhus [ 09/Jul/13 ] Attached find the PHP code that includes a function to normalize LCC call number input. al [VUFIND-727] Requests page under MyResearch combining Ariel Document Delivery, VoyagerILL, and INN-REACH data Created: 12/Dec/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch 2.0beta Type: Reporter: Resolution: Labels: Environment: New Feature Ken Herold Unresolved None Ubuntu 12.04 LTS Attachments: Wishlist Priority: Assignee: Votes: Minor Unassigned 0 JIRA_requests.phtml Description Example of working code creating patron-specfic, real-time tables of Ariel Document Delivery (live PDFs, including RapidILL); patron hold requests and loans from an III INN-REACH direct consorial borrowing (DCB) site; and locally-served VoyagerILL data existing in its Cliodata.mdb file. The working model used mount.cifs to make the Ariel filesystem available and that Ariel site and Perl code is obviously a prerequisite. The MS Access database file is similarly made available using mount.cifs and is queried directly using the mdb-tools code in 0.6beta (http://sourceforge.net/projects/mdbtools/) Other ILL systems may be accessible using this method. Comments Comment by Demian Katz [ 12/Dec/12 ] Thanks for sharing this! I don't think this is likely to become a standard VuFind feature because of the unusual dependencies, etc., but it's great to have this code as a reference for people who want to implement something similar locally. [VUFIND-704] Ability to have Public Comments be Reviewed before they are made publicly viewable Created: 31/Oct/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch 1.2, 1.3 Type: Reporter: Resolution: Labels: Environment: New Feature Priority: Bill McClendon Assignee: Unresolved Votes: None LINUX - Public library setting Wishlist Minor Unassigned 0 Description It would be a good idea to have a Public comment structure with a designated owner account (in either VuFind or an Admin interface) that allows for review and approval/denial of comments made for "Public" display before they are displayed to all VuFind patrons WITHOUT the loss of the ability to place publicly visible comments. Too many chances for patrons to leave inappropriate comments visible by young patrons as well as students leaving inappropriate comments about staff, professors, etc. Comments Comment by Demian Katz [ 01/Nov/12 ] This ticket could make a good companion to VUFIND-688: in addition to having the option to configure comments "on" or "off," it would also be useful to have an "approval" mode where one or more users could be designated with the ability to approve or delete pending comments for display. Also slightly related is VUFIND-326, which suggests adding spam filtering support for comments (which might save approvers some work). Additionally, there is a separate open source package which you may find useful -- VuFind Manager reportedly allows comment management, though I have never tried it myself: http://www.evolveplus.com.au/download-vufind-manager This might help you out until something is built in to VuFind itself -- it may be a while before anybody finds time to implement this (though I'm always happy to look at patches if somebody has time to work on something). [VUFIND-705] Update Europeana Recommendation Module to API version 2.0 Created: 01/Nov/12 Updated: 20/Dec/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record, Search Wishlist Type: Reporter: Resolution: Labels: Environment: Improvement Priority: Eoghan Ó Carragáin Assignee: Unresolved Votes: api, europeana, recommendation All Issue Links: incorporate incorporates VUFIND444 Wishlist Minor Unassigned 0 Europeana search results recommendation Resolved Description Port existing code to the new version. Also investigate if the new version might offer new functionality, for example: -- Are common library identifiers (LCCN, ISBN, OCLC) indexed and accessible through the API's lucene syntax option? This would allow us to use the API more like the current Google Books, Hathi Trust, and Open Library previews -- Can the new API's "Record Profile" be used to create a record page recommendation for Vufind? -- The new api has a much richer response (e.g. it returns facet counts). It might be possible to build a pretty full-featured Europeana module like the Vufind Summon module. ### Links ### Console: http://preview.europeana.eu/portal2/api/console.html Documentation: http://preview.europeana.eu/portal2/api-documentation.html Forum: https://groups.google.com/forum/?pli=1#!forum/europeanaapi Comments Comment by Eoghan Ó Carragáin [ 01/Nov/12 ] Europeana metadata & previews are now under CC0 licence, so I think the API will be avaible to all Vufind users, not just Europeana partners. Registration here: http://preview.europeana.eu/portal2/api/registration.html Comment by Demian Katz [ 01/Nov/12 ] There are a lot of interesting possibilities here, and it may be worth breaking this into subtickets once we start actually working on it. In the meantime, just one question: are there any reports on how long the 1.0 API will stay around? Is there any urgency to this, or is it purely an enhancement? Comment by Eoghan Ó Carragáin [ 01/Nov/12 ] Sub-tickets sounds like a good idea. I'm not sure re the 1.0 API. I'll find out. Comment by Filipe M S Bento [ 01/Nov/12 ] "so I think the API will be avaible to all Vufind users, not just Europeana partners." Thanks for that confirmation, Eoghan (or at least believe). From the mail received I also got that idea, but was not sure... UPDATE: confirmed > received both the API and Private key. Will test them soon. Another extra link > More about the Europeana API services - http://pro.europeana.eu/api Filipe Comment by Eoghan Ó Carragáin [ 02/Nov/12 ] Re support for 1.0 API, the old syntax will be supported in the new version. So the existing code should work for new, non Europeana partners, with a modification to the base url. See https://groups.google.com/d/topic/europeanaapi/Hjk1s5W9x4o/discussion Comment by Eoghan Ó Carragáin [ 05/Nov/12 ] I posted a question re support for OCLC/ISBN/LCCN here: https://groups.google.com/d/topic/europeanaapi/q9Wcvm2MhVU/discussion If data-providers, e.g. libraries, include OCLC/ISBN/LCCN when they map their metadata to the Europeana Data Model, it is indexed and searchable under the proxy_dc_identifier tag (see forum post for an example). This would allow for look-ups like Google Books, Hathi Trust, Open Library, etc. However, this may not be that reliable if data-providers aren't normalising prefixes and identifiers in a consistent way. Comment by Eoghan Ó Carragáin [ 12/Dec/12 ] Europeana have announced that the new API is now live. It would be good if an non-Europeana member could register for a key & test that the existing version 1 recommendation module works out of the box with the 2.0 api. We could then update the base url in vufind trunk if necessary. Comment by Demian Katz [ 20/Dec/12 ] I just tried registering for a key, but it does not appear to work with the 1.0 API. See: http://api.europeana.eu/api/opensearch.rss?searchTerms=test&wskey=xxx (I replaced my API key with xxx in the link above, but the results are the same). [VUFIND-698] More flexible LDAP configuration Created: 16/Oct/12 Updated: 16/Oct/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Sometimes particular LDAP environments require extra configuration parameters. For example, if it is necessary to disable reference chasing, it would be necessary to add code like this to the LDAP process: @ldap_set_option($ldapConnection, LDAP_OPT_PROTOCOL_VERSION, 3); @ldap_set_option($ldapConnection, LDAP_OPT_REFERRALS,0); While a simple solution to this problem would be to add a specific reference chasing option to the [LDAP] section of config.ini, it might be more useful to add a more generic means of configuration -- i.e. an array of LDAP options. The practicality of this idea may depend on the ability to convert constant names loaded from a configuration file into their corresponding values. If that is not possible, this may not be a practical suggestion, but it's worth investigating. [VUFIND-692] Disqus integration for VuFind Created: 05/Oct/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Attachments: Updated: 09/May/13 Wishlist Disqus.png Priority: Assignee: Votes: Minor Unassigned 0 disqus_trunk.patch Description This patch, courtesy of Ronan McHugh, adds basic Disqus support to VuFind. It was moved here from VUFIND-534. Comments Comment by Demian Katz [ 05/Oct/12 ] Loading screen shot originally provided by Ronan McHugh on VUFIND-534. Comment by Demian Katz [ 05/Oct/12 ] I think a few enhancements might be nice before we commit this: 1.) The template should set the disqus_identifier variable so that discussions are independent of specific URLs. I would recommend using the format "resource source, pipe, record ID" -- for example, "VuFind|12345." This way, when we port this forward to VuFind 2.0, we can easily generate unique IDs to allow discussions in all the modules (Solr, which uses "VuFind" as its source ID, plus Summon, WorldCat, etc.). 2.) It would be useful to have a configuration option to set the disqus_developer variable in the template so that the service can be tested on private test servers. 3.) It would be useful to add SSL support (possibly as a configuration option, or possibly just as the default behavior) so that Disqus doesn't cause browser security warnings by loading insecure resources on a secure page. As of this writing, this may be difficult -- it sounds like there are some SSL-related problems as Disqus transitions from "classic" to "2012." Hopefully that will be fixed soon if it is not already working properly. Some useful resources: Javascript configuration variables reference: http://help.disqus.com/customer/portal/articles/472098-javascript-configuration-variables Notes on SSL problems: http://stackoverflow.com/questions/10004213/how-do-i-force-disqus-to-use-https-on-allrequests http://www.quora.com/Disqus/When-will-Disqus-support-HTTPS-SSL I think that solving issue #1 is a necessity in order to push this into the trunk. Issues #2 and #3 would be nice but aren't absolutely crucial -- I would be willing to defer solving those until the port to 2.0. If somebody has time to submit a revised patch, that would be great; otherwise, I'll take care of this myself when time permits. Comment by Ronan McHugh (Inactive) [ 05/Oct/12 ] Thanks for the feedback. I'll have a look at this in the near future. [VUFIND-675] Retrieve related records / info from Microsoft Academic Search, using MAS API Created: 23/Sep/12 Updated: 26/Sep/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search Wishlist Type: Reporter: Resolution: Labels: Improvement Filipe M S Bento Unresolved external_search_api Issue Links: incorporate incorporates VUFIND-121 Microsoft Research Pane SOAP Service Open Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description It accepts SOAP/JSON requests/responses. Limited to 100 results per query. Full documentation: http://academic.research.microsoft.com/about/Microsoft%20Academic%20Search%20API%20User%20Manual "Overview The Microsoft Academic Search (MAS) API is designed to allow developers to build applications by leveraging the data and functions of MAS. There are seven primary objects in MAS, including publication, author, conference, journal, organization, keyword and domain. The API enables applications to - Send a free text query to retrieve relevant objects - Get the detail information of a given object - Explore the relationships between objects To send a request to MAS API, both JSON and SOAP protocol are supported." How to apply for an MAS AppID: http://social.microsoft.com/Forums/is/mas/thread/9a23b2d6-6599-4853-acf5-c1692a64365e MAS frontpage (public): http://academic.research.microsoft.com/ Thanks, Filipe Comments Comment by Filipe M S Bento [ 23/Sep/12 ] VUFIND-121 ticket: I believe it's the same service, right, Demian? (VUFIND-121 dates back to 2009). Filipe [VUFIND-662] OAuth / OpenID complementary login with a single click Created: 17/Sep/12 Updated: 01/Nov/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch Wishlist Type: Reporter: Resolution: Labels: New Feature Priority: Filipe M S Bento Assignee: Unresolved Votes: OAuth, OpenId, login, social Attachments: Wishlist Minor Unassigned 0 Imagem102.png Description The idea: simplify as much as possible the login process by offering “one click” alternatives, recurring to OAuth 2.0 providers: users would click on a certain service where they are authenticated (an image with a link to that service) and upon that remote service JSON response, VuFind would validate the present session for associated local user, reading this value from a new “OAuthLogins” (lets say) new MySQL table that has the relation “local_user” – “oauth_provider, oauth_uid, username, email” (etc., possible data sent by those services) and do, lets say (part II): $interface->assign('user', $local_user); being $local_user the value read from that table, if found a corresponding record. If no line matching “oauth_provider, oauth_uid, username, email” (whatever data OAuth 2.0 provider sends), the user should be prompted to enter his/her local credentials so to do an insert of a line associating the $user interface active value with the OAuth 2.0 data received). This could be an new entry “/MyResearch/Favorites” > “Your Account” > “Fast social login sources” that could have a list of providers [images with links to activate them if not active], “Active” (or not), “Revoke access” and associated “e-mail”. The associated e-mail is an important part, as we could offer the chance of VuFind using that email as the default one to be used by VuFind to send whatever e-mails users request, as not always the one in the OPAC is the preferred or even updated one. Of course, users will have always the chance of inputting their login and password (in coexistence with as many social login providers [OAuth 2.0 providers] they have active]). But just the fact that they wouldn’t have to insert the password (even over SSL), over and over again, is a reduction in what it’s always a security issue. Of course, part II, this could be offered in systems that offer [MultiAuth] in config.ini ("ILS,DB", for instances); in this case, we would really need to ensure that the user goes through a couple of confirmation messages confirming that he/she does not have an ILS account in order to create a new one with the data provided by that service; not only for an ILS account but also for other OAuth 2.0 services, in order to have all of these associated with the same login. In all of these cases, if they have already an account in VuFind (ILS or DB), we would need to ask them to enter it first, before activating this new OAuth 2.0 provider. E-mail could be used to associate accounts, but we have no guaranties that users use the same e-mail in their social nertwork services profile… Well, you’ve seen it working a thousand times before (and for sure use it in some services as well), so I am stopping here (the new fact we bring, is the association with an existing local account, so a separate table to store the several entries a user might have, all of them pointing to the same $user at VuFind). So: possible base solutions that could be adapted to VuFind framework (anyone?): Facebook: A possible “how-to”: http://www.9lessons.info/2011/02/login-with-facebook-and-twitter.html Update to the previous post: http://www.9lessons.info/2011/09/update-login-with-facebookand-twitter.html (Twitter is similar, just doesn’t return user’s e-mail) Response: (oauth_provider, oauth_uid, username, email) values ("facebook","<OAuth_ID, eg: 1576437403","<NAME>","<E-MAIL>") Google: A possible “how-to”: http://www.9lessons.info/2011/07/login-with-google-account.html Response: (oauth_provider, email, username) value ("Google","<E-MAIL>","<NAME>") I must confess that I never really understood deeply the way VuFind does login the user, I mean where it reads the values from MySQL, because in web/services/MyResearch/MyResearch.php what I find is (only) the connection to the Catalog… if (UserAccount::processCatalogLogin( $_POST['cat_username'], $_POST['cat_password'] )) (…) but I’m sure for the most of you, it is a “piece of cake” and it sure would bring a great, great value (and make it modern as well) to VuFind, in my humble opinion. Well, enough said, you got the idea by now: one clik > you’re in (no need to enter an username, no need to enter a password, no unnecessary login data traveling around in the network). Comments Comment by Filipe M S Bento [ 17/Sep/12 ] VUFIND-534 Social Media Enhancements: Because of several references to OpenId in comments from Ronan McHugh and Demian's. Comment by Filipe M S Bento [ 17/Sep/12 ] VUFIND-522 Allow user-chosen authentication method Description: In some scenarios, multiple authentication options are available and the user needs to choose which one to use (i.e. log in with institutional credentials or log in with Facebook). We should create a configurable authentication module to meet this need. Comment by Filipe M S Bento [ 17/Sep/12 ] From my Elgg (http://elgg.org/) test / dev install (stalled for quite a while). [VUFIND-653] Implement sharding support for alphabeticBrowse() Created: 13/Sep/12 Updated: 28/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Subissue of VUFIND-316 Does au.gov.nla.solr.handler.BrowseRequestHandler support sharding? Comments Comment by Demian Katz [ 13/Sep/12 ] There are two pieces to the alphabetic browsing: 1.) The indexing tools which pull data out of Solr. I'm not sure how these handle sharding currently (probably they do not acknowledge the option, but I haven't checked). If we want to support sharding, we just need to be sure that browse indexes are built using all applicable shards. 2.) The BrowseRequestHandler, which uses the SQLite databases generated by the indexing tools and then performs some searching to retrieve additional data. We might need some kind of replication mechanism to make the SQLite databases available to all shards... and also some adjustments to the performed searches to account for sharding. So there's probably significant work required to add sharding support. Probably not a high priority unless somebody expresses a real need for this. [VUFIND-651] Implement sharding support for getTerms() Created: 13/Sep/12 Updated: 28/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Reopened VuFind Search 1.3, 2.0beta Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Sub-issue of VUFIND-316 Fix requires adding the shards= query parameter to enable sharding and stripping shards (!) that whose core does not contain the requested $field. Comments Comment by Demian Katz [ 13/May/13 ] This is a very low-priority issue; getTerms is only used by the sitemap generator at this time, and the needs of sitemap generation may be better and more flexibly addressed by VUFIND656. However, I'm going to leave this ticket open in case there is a future need for sharded terms support. Feel free to comment here if you think of a use case. [VUFIND-637] User preferences' / profile page Created: 21/Aug/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch Wishlist Type: Reporter: Resolution: Labels: Improvement Priority: Filipe M S Bento Assignee: Unresolved Votes: personal_settings, profile, user Issue Links: incorporate incorporates incorporates incorporates incorporates incorporates Updated: 25/Apr/14 Wishlist VUFIND-510 VUFIND-613 VUFIND-520 VUFIND-614 VUFIND-279 Minor Unassigned 1 Email notices from MyResearch area Personal Setting: personal filters Allow users to disable autocomplete User settings: adjust number of resul... Additions to Profile Open Open Open Open Open Description Somewhat in the sequence of VUFIND-279 and VUFIND-614, it would be nice for validated/registered users to have an area where they could choose, in a fast way, several preferences (that can be stored in their entry, users table in MySQL as these settings perhaps would be read only once per session), apply and save them for future sessions usage: - Module they want as their home space, to where they want to be redirected after logging in (/Search/Home? “Your Account” area (=MyResearch/Favorites), open last search made (re-do it) -- new itens that match that search?; - Desired Export formats (“Export Record” in record’s full view): RefWorks, EndNote, BibTeX, MARC; - Choose the default “Number of records per page”; - Choose then desired Citation Formats to display in “Cite this”; - Chose the default Sort type (Relevance, Data descending, etc.); - Choose the desired theme, if more than one is available; - Choose the desired source to search by default (with a filter applied to search only that source after login -- that can obviously be removed in a regular fashion); - … other “hardcode” preferences in .ini files that affect all the users (but still keep them in the .ini files --> default values, for anonymous users). PLEASE do add more ideas in comments of things users’ would like to set in preferences. Many thanks! Filipe Comments Comment by Filipe M S Bento [ 23/Aug/12 ] More Actions > Link: really nice feature (but don't remember it in previous JIRA version... or I am wrong, was this feature available before?). Going to use it a lot in the future! Thanks, Demian! Filipe Comment by Tod Olson [ 13/Sep/12 ] A couple other ideas that come out of our user stories: - default search limit (e.g. pre-limit searches to a specific location or collection, or some other pre-defined list) - default results view (e.g. Ireland has list and grid view, not standard VuFind, but it the idea of multiple results views with different levels of detail has come from our users for years, and it would be nice to let them select their preference.) Having some hook for local user preference settings would be useful for any site doing customization. [VUFIND-639] Voyager driver does not account for EFFECT_DATE/EXPIRE_DATE for reserves Created: 27/Aug/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver 0.8.2, 1.0RC1, 1.0RC2, 1.0, 1.0.1, 1.1, 1.2, 1.3 Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Attachments: Updated: 09/May/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 reserves-expire.patch Description Currently, the Voyager driver displays all course reserves, even if they have date settings that would cause them to be hidden in the native Voyager OPAC. The attached patch (courtesy of Mark Sandford) goes partway toward hiding expired/not-yet-available reserves, though additional work may still be needed in the findReserves() method. [VUFIND-626] Custom fieldType for sorting in schema.xml Created: 12/Jul/12 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 1.3 Type: Reporter: Resolution: Labels: Improvement Vaclav Rosecky Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Consider adding custom fieldType for sorting in SOLR schema.xml (sort by author, title, ...) which can be overridden to desired locale if needed. Some languages have specific requirements for sorting. <fieldType name="textSort" class="solr.TextField" sortMissingLast="true" omitNorms="true"> <analyzer> <tokenizer class="solr.KeywordTokenizerFactory"/> <filter class="solr.ICUCollationKeyFilterFactory" locale="en" strength="primary"/> </analyzer> </fieldType> Comments Comment by Demian Katz [ 12/Jul/12 ] Would it also make sense to create some kind of mechanism that allows different sort fields to be used for different user language choices? It would probably be complicated and create some overhead in the index, but it might be worth thinking about. [VUFIND-620] Collaborative lists, public or private Created: 04/Jul/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch 1.3, 2.0alpha Type: Reporter: Resolution: Labels: Improvement Filipe M S Bento Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description Made a quick demo of our VuFind install (staging) to a couple of people in these last days and this exact same question was raisin (one was a PhD Candidate and others are a couple of Librarians, all female, if that demographic factor matters and bellow 30 years (well, for sure bellow 40): it would be nice to have lists that could be a fruit of several users contribution (shared, not only in RO mode [Read-Only] like public ones are, but RW ones [Read & Write]). Solution 1: users would have a public key (known only to them) that would share when wanting to be included in that list or better yet, Solution 2: no public key required -- a plain link: ask to join list -- only possible in public lists?... That inclusion could be authorized by the list owner, or if he/she gives permission, by other members of the list. This way that user would be able to add favorites to that shared list (and delete them?... Have your say). Thanks, Filipe Comments Comment by Demian Katz [ 06/Jul/12 ] You could combine all of these features if you wanted to. Imagine an implementation like this: There is a list_editors table that associates user IDs with lists; this controls which users (other than the owner, who can always edit) are allowed to modify a list. Users can be added to the list_editors table in three ways: 1.) They enter a token provided by the list owner. 2.) The list owner explicitly adds their username in an administrative interface. 3.) They request to join (perhaps going into a list_editors_pending table) and the owner approves them. (Obviously we wouldn't have to implement all of these options... but they're all possible if needed). The other piece to figure out is how to present shared lists in the user interface. Do they just seamlessly appear in the same place as single-user-owned lists? In this case, do they look exactly like a single-user list, or are they marked in some way (i.e. [SHARED] after name). Or do we need a separate section for "other users' lists that you can edit"? In any case, this isn't a totally simple feature, but it would be reasonably straightforward to implement and definitely has obvious uses. Comment by Filipe M S Bento [ 06/Jul/12 ] Hi, Demian, again! And again, like in http://vufind.org/jira/browse/VUFIND-619, I think we are not so far apart regarding possible solutions for this, give or take we are in the same wave length of thoughts. Yes, sure, a new table is needed (list_editors sounds great). The new one (2) you suggest (and also in 1) in which you inverted the roles... lists would have tokens, not users, and users would join themselves the list --- could be an URL with that token in it, sent in a message by the system or the list owner him/herself) the list owner needs to be flagged that a particular user wants to join / contribute to the list. My solution 2), yours #3, requires that the user is aware of its existence; well, if not public, the user will have no chance to see it, unless, someone shares the URL and we would need to change the error message: An error has occurred You do not have permission to view this list. Please contact the Library Reference Department for assistance To include the possibility of the user ask to join it (well, we could go a further step ahead and include in the list definition if it can be joined by other users / a checkbox for collaborative list) and only show that possibility if the list as that flag on. That brings me to a topic that I've talked (written) some time ago, if not in the developers’ meeting, directly with you, Demian, that is to have a way to search or browse, at least, the lists that are public. Well, that is something you mention somewhat also in your reply, the way these list would appear, but I think you are talking about at a posterior level, after joining the list: I would go for the second suggestion > a separate section for "other users' lists that you can edit"? separate: own lists | shared lists, having their own ones, that are also shared, the [SHARED] tag you mention after its name. Many thanks, once again, especially for your great support to this idea; I think at an academic level, like most of VuFind installs belong, this is quite important as all users somehow belong to communities, some small (PhD – Candidate and Advisor), some large (Labs, CU groups, etc.). Filipe PS: 1:20 am -- status remains the same :| but it is worth, being replying and sharing these ideas with you (all! Please do get involved, if not to press the green [agree] or the red button [disagree] > first form of focus groups – no discussions amongst participants going on there, like the ones we do now are stimulated to occur naturally). Comment by Demian Katz [ 09/Jul/12 ] Regarding your comment about making users aware of the existence of lists, you actually opened a ticket about this some time ago: VUFIND-443. I agree that these features are related to one another. It would be very useful to implement VUFIND-443 in order to make list sharing more effective. [VUFIND-619] "Remember Me" Login Functionality: yes or no? Created: 04/Jul/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch, User Interface 1.3, 2.0alpha Type: Reporter: Resolution: Labels: Environment: Improvement Minor Priority: Filipe M S Bento Unassigned Assignee: Unresolved 0 Votes: None if yes, accept cookies in browser must be enabled... Attachments: Imagem 060.png Imagem 064.png Wishlist Imagem 061.png Imagem 065.png Imagem 063.png Description Hi! Not so much a new functionally wish, more like a question: is it worth to implement and create a patch for it? "Once a user is authenticated, their credentials are typically stored in the session. This means that when the session ends they will be logged out and have to provide their login details again next time they wish to access the application. You can allow users to choose to stay logged in for longer than the session lasts using a cookie with the remember_me firewall option. The firewall needs to have a secret key configured, which is used to encrypt the cookie's content." * taken from Symfony cookbook, a PHP framework for web projects (what else?... http://symfony.com/). So I guess nothing too complicated to do. Although I'm raising the question if should or not invest my time in doing this for the community, eventually will do it for our own Service, as most of our users and sessions will generated from their own PCs / laptops / smatphones, tablets, whatever... (not from public kiosks). Beside the personal space management (favorites, lists, tags, Library personal data, etc.) being with an active account allows our users (again, not yet in production) to search EBSCOs DBs (in real-time, via EIT), that shows up fully parametized to the current search (and when a search renders in no results found), as Find More EBSCOs Databases (FT) * Academic Search Complete (....) bellow the "Year of Publication" narrow search slider; well, bellow the entire Narrow Search column >> more options to broaden the search to come.. beside the Subject module ( = Author one, with wikipedia’s entries [subjects] and everything else), already implemented and fully functional. So, have you saying: yes or no to "Remember Me" login functionality? Thanks, Filipe Comments Comment by Filipe M S Bento [ 04/Jul/12 ] <Imagem 064.png> "Explode" a subject, instead of narrow the search (when clicked >> query += "AND <that subject>"), a plain search for that subject... (cont) Comment by Filipe M S Bento [ 04/Jul/12 ] <Imagem 065.png> (cont) ... with added info from wikipedia when found. This Wiki added info just works for subject "explosions"; other fields explosion just do a plain search (but still have the "See Also" and recommendations at the top... = normal search for that term in a the field to what ot bellongs (from the narrow search entry). Comment by Filipe M S Bento [ 05/Jul/12 ] When I say "So I guess nothing too complicated to do" is because VuFind already stores a cookie with: PHPSESSID, __atuvc (?), language and ui (at least in the one I'm checking out). Or better yet, a "clean" session: Cookie Information - http://iia.staging.ua.pt/ NAME ui VALUE standard DOMAIN staging.ua.pt PATH / EXPIRES At the end of the Session NAME PHPSESSID VALUE 1kcloq7bkcrmo6eu69snmoirl0 DOMAIN staging.ua.pt PATH / EXPIRES At the end of the Session So I guess it is just a question of change the expiration date (well, include one, not have "At the end of the Session") and include in it an encrypted (is it worth it, I mean being encrypted? --well, I guess it's better -- search engines do love this kind of stuff) username and a true/false field "remember me". - Filipe Comment by Demian Katz [ 06/Jul/12 ] This functionality is not as simple as extending the lifetime of the session cookie. In addition to the cookie expiring on the client side, PHP will also expire the session data on the server side if it is not accessed after a certain period of time. I don't think this problem is normally solved by allowing sessions to persist indefinitely. A more common solution would be to create a new database table which associates a token with a user ID. This token is placed in a cookie with a long lifetime on the client machine. When VuFind checks to see if a user is logged in, it would have to do this: 1.) Check if there is currently an active session. If so, use it. 2.) Check if there is currently an active "remember me" token. If so, establish a new session using that data. Obviously in this situation, the user who comes back with the token will lose any short-term information that was only stored in the session (like recent search history). I think this is okay; the purpose of this feature should not be to persist every little detail forever (if we do that, lots of junk will accumulate on the server); it is simply to save the user the trouble of logging in over and over. There are probably some additional complications -- some authentication methods may not play well with the feature (i.e. if they have special logout requirements, weird things may happen if the user is logged in with a token in a way that bypasses the normal login process); obviously security needs to be taken into consideration (how long do long-term tokens live? how are they generated? do we use any extra layers of security like associating an IP address with the token?). So, bottom line: it can be done, but it's not entirely simple. I think it would be a useful feature, but it's not a high priority for me to implement right now. Obviously, if lots of people vote for this, the priorities can be adjusted. Comment by Filipe M S Bento [ 06/Jul/12 ] Hi, Demian! I think we are not so far apart regarding possible solutions for this; please be aware that it was written in heat of the moment just to get the discussion started (along the others last night). Besides being annoying for a user that uses (sorry about the redundancy) the same point of access to enter their login in every single session, especially if you built features that are only available to them if logged in, there is the security issue of having to enter their password every time, even if in a HTTPS secure environment. If it is a universal one (same for all University's services) the fewer the occasions they are asked to enter it, the better. > do we use any extra layers of security like associating an IP address with the token?) Well, when writing the ticket was also about to include that possibility, but then I thought about the situation I was at that time, logged in to the University’s Computer Center VPN, which gives me a different NAT IP address different every time, as it happens with users that access the net using our campus' wireless coverage (well, all of them). So that solution has to be ruled out. Unfortunately voting is something we don't see so much around here, so have no expectations than to implement it myself when I have the time; a support table that is read every time a session (PHP) is started is a good idea. But I would simplify and just had a new field to the “user” table ("active" or so). If the "remember me" is checked by the user when logging in, just change that true/false field to true and store an encrypted version of the username in a long term cookie (3 months or more). When he/she logs in, it would emulate a normal login (haven't analyzed how it is done in VuFind, but from what I've tried [for a different purpose] it is not just a question of having the session variable “$user” with a value ({assign var=user value="uncrypeted_username_string_read_from_cookie"}, or just signalize that PHP session is validated for that user, instead of an anonymous/proxy one(?). When he/she hits logout, the value of that field, in the "user" table, would be set to false and cookie encrypted username erased (don't have that much experience with cookies, but from the few I had they seem quite easy to handle). Well, if no votes are received I'll get back to this issue when I have the time, because in my opinion is something that our users will sure complain about when entering production, especially because I have placed: {if !$user}{translate text="Have an UU? Login to have access to all functionalities and extra sources"}{/if} at the homepage (/Search/Home) … UU = Universal User (same username/ password for all services … that just receive a token (IUPI) not the actual username and password , so that they can change the username (twice a year) or even better, the password as often as they want without losing access not even for a second to any of the services (if not direct Shibboleth idp (federated identity) some have our own version of it, like Aleph, because at that time, Aleph didn’t support Shibboleth auth/. Btw, UU = e-mail address, official one of the University. Thanks for your thoughts and feedback, Demian, Filipe PS: 0:36am over here and no dinner, so sorry if not so clear in some aspects. EDIT: current structure of "user" table for the ones that don't know it: mysql> desc user; +--------------+--------------+------+-----+---------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------+--------------+------+-----+---------------------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | username | varchar(30) | NO | UNI | | | | password | varchar(32) | NO | | | | | firstname | varchar(50) | NO | | | | | lastname | varchar(50) | NO | | | | | email | varchar(250) | NO | | | | | cat_username | varchar(50) | YES | | NULL | | | cat_password | varchar(50) | YES | | NULL | | | college | varchar(100) | NO | | | | | major | varchar(100) | NO | | | | | home_library | varchar(100) | NO | | | | | created | datetime | NO | | 0000-00-00 00:00:00 | | +--------------+--------------+------+-----+---------------------+----------------+ (sorry, no "system"/fixed font > what a mess!) Comment by Demian Katz [ 09/Jul/12 ] To mark a user as logged in, VuFind puts a copy of the database object representing the user's row in the session. (In 1.x, I think this is also available as the global $user variable... but in 2.x, it will be more neatly encapsulated in an account manager class -- globals are evil). Regarding your idea of adding a field to the user table and using an encrypted username as the "remember me" cookie, it would work, but I have a couple of reservations: 1.) Using an encrypted value as the cookie is inherently less secure than using a random token. Encryption can always be broken if someone is sufficiently determined, so there's a greater chance of a vulnerability that allows access to arbitrary accounts if the "remember me" token has a built-in meaning. 2.) If you use a random token and a user stores credentials on multiple machines or in multiple browsers, then you can end up with multiple tokens for a single user... that's why you need a separate table rather than a simple flag in the existing user table. Also, regarding remembering IP addresses, I see your point... but perhaps it would be worth having some configurable options for extra layers of verification. Maybe an IP with a subnet mask would cover your use case... or maybe there are other things to examine, like browser family, which could help reduce vulnerability to automated token-guessing attacks. [VUFIND-617] Show place-a-hold-button in resultlist Created: 03/Jul/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface 1.3 Type: Reporter: Resolution: Labels: Improvement Oliver Goldschmidt Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Minor Unassigned 0 place-a-hold-button-in-resultlist.patch Description Some weeks ago there was a discussion on the mailing list asking for functionality to show a button to place a hold in the result list. Here is a patch (against Vufind 1.3) that should do that. Comments Comment by Demian Katz [ 03/Jul/12 ] Where is $record[0]['recallhref'] coming from? Does this patch rely on a custom ILS driver? Also, this assumes a hold link in the first record; it might be safer to either take advantage of the new title-level holds option or to loop through records looking for a match in case the first item is unavailable but a subsequent one is available. And, of course, there are the inevitable problems with multi-volume sets and similar special cases. Comment by Oliver Goldschmidt [ 03/Jul/12 ] Thanks for your comments! I see, my patch is not so usefull as I was hoping (and promising)... Sorry, I thought recallhref was an attribute given by all ILS drivers. I have checked that and (of course) you are right; this is not the case. Its in the DAIA driver, in other drivers this attribute does not exist. So this solution unfortunately will only work with the DAIA driver. Using the title-level holds would be great, but I guess this is not possible with any ILS. Looping through records would be possible, of course. Since the DAIA driver should present only the link to the first available item, this should resolve the problems with multi-volume sets. Of course there might be other special cases, which I did not consider with this patch. Comment by Demian Katz [ 03/Jul/12 ] At least we have a workable solution for DAIA users, though that's obviously a small minority! For future reference, here are my comments on a more generalized solution from the mailing list: I don't think this has been done before, and it's probably not exactly simple, but it certainly should be possible in combination with the "Item_Status/show_full_status" config.ini option (though it may have performance implications, since the AJAX routine will be doing significantly more work). You'll need to modify the getItemStatuses method in web/services/AJAX/JSON.php. Instead of calling $catalog->getStatuses($_GET['id']), you should instead connect to Solr and perform a query on the requested IDs. Loop through the Solr response and construct record driver objects for each one. For each record driver object, call the getHoldings() method and then render a custom template in place of the standard template returned by getHoldings -- this replaces the current _getItemStatusFull() method. Comment by Oliver Goldschmidt [ 04/Jul/12 ] Based on Demians comments I have prepared an improved version of my patch, that fixes the problems with fixed index positions by sorting the result set. This version is still dependent on some special driver fields (i.e. an ILS-driver should return in its method _getShortStatus() at least the additional fields duedate, duedate_timestamp and recallhref to work properly with this patch). Currently only the DAIA driver returns these fields (the field duedate_timestamp is added with this patch also). [VUFIND-613] Personal Setting: personal filters Created: 29/Jun/12 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch, Search Wishlist Type: Reporter: Resolution: Labels: New Feature Oliver Goldschmidt Unresolved None Issue Links: incorporate is incorporated by VUFIND-637 User preferences' / profile page Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Open Description It would be nice if one could store personal settings like facets (or shards), that would be applied to any search. Comments Comment by Demian Katz [ 29/Jun/12 ] I can see how this would be useful. A few things to think about when designing the feature: 1.) The user interface will have to clearly represent where stored filters are coming from (as well as the fact that retrieving stored filters requires a login). If this is not very visible, users may be confused by unexpected search results. If it is too visible, it may become an annoyance for users who are not interested in the feature. 2.) There are some risks to stored filters -- if the Solr schema changes in the future, it could break user accounts. (Obviously, this isn't an entirely new risk -- bookmarked search links are subject to the same problem). Probably not a common problem, but once in a while it could serve as a significant annoyance. 3.) Where should personal settings be stored? The most obvious suggestion would be a new database table tied to user accounts... but it would also be possible to envision a use case where a cookie is used to maintain filters across user accounts (for example, computers in a public library that is part of a consortium might want to pre-filter searches to just that library). I'm not sure if this amounts to one feature with different configurable settings or two independent features. In any case, this isn't high on my own priority list right now -- there's a lot of other stuff to do at the moment -- but I'd certainly be happy to review and discuss a patch if somebody else has the time before I get to it. [VUFIND-614] User settings: adjust number of results per page Created: 29/Jun/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface Wishlist Type: Reporter: Resolution: Labels: Improvement Oliver Goldschmidt Unresolved None Issue Links: incorporate is incorporated by VUFIND-637 User preferences' / profile page Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Open Description In addition to VUFIND-173, the number of results per page could be adjustable for users. Comments Comment by Demian Katz [ 29/Jun/12 ] VUFIND-173 already lets the user choose the number of results per page. Is this ticket suggesting that the user should be able to store that value in her/his account so it becomes the new default on subsequent logins? (Or, along similar lines, should a cookie be used to remember page size over a longer period of time?) Comment by Oliver Goldschmidt [ 29/Jun/12 ] http://vufind.org/jira/browse/VUFIND-173 introduces a config option to let the maintainer set a general page size. This ticket is suggesting that the user (not the maintainer) can set this size in her/his account, so that any query he/she starts, will have this limit (and not the one by the maintainer). This would be another user setting, not a config setting. I hope this makes it a little bit more well-defined... Comment by Demian Katz [ 29/Jun/12 ] Thanks for the clarification. Note that the existing configuration already supports a commaseparated list of page sizes that results in a drop-down list in the user interface allowing the user to pick a page size. Additionally, the last page size chosen is already stored in the session and used for subsequent searches. So the only addition we need to complete this ticket is longerterm storage. So that leads to two questions: 1.) Where does long-term page size storage occur? Do we use a cookie so the value persists on a given machine, or do we use the user account so it follows a user around? The cookie has the disadvantage of affecting all users of a machine and being localized to that machine, but the user account has the disadvantage of requiring a login before taking effect. 2.) Do we need to create a user preferences area where the user specifically sets up this preference, or do we just automatically remember the user's last setting? Personally, I think simply remembering the last setting makes the most sense. [VUFIND-606] Grab item status from Z39.50 Created: 28/Jun/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver None Type: Reporter: Resolution: Labels: New Feature Kun Lin Unresolved voyager, z39.50 Updated: 09/May/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description I hope VuFind would be able to grab item status from Z39.50 server. It makes things easier when direct database access is not possible.(Voyage) Comments Comment by Demian Katz [ 28/Jun/12 ] I'm not too familiar with the Z39.50 protocol, but if it supports enough features to implement a subset of VuFind's ILS driver spec, it would make sense to implement a Z-driver for VuFind. If anyone has the time and knowledge to do this, I'll be happy to commit it. If your problem involves Voyager specifically, is it possible to use the RESTful API in place of database access as well? Perhaps the VoyagerRestful driver could be made to rely more heavily on the RESTful interface instead of using the database functions from the base Voyager class. [VUFIND-581] Authority Recommendation Module: search for non-preferred term should return also the ones that have the preferred term & vice-versa. Created: 16/May/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 1.3 Type: Reporter: Resolution: Labels: Improvement Filipe M S Bento Unresolved Search, feature Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Following the great new module, ticket VUFIND-538, by Ronan McHugh with enhancements from Demian, it would be nice if a search for a non-preferred term returns the records that have that exact terms, not only but also the ones that have the preferred term. This is quite a common feature in most of ILS systems that have AUT bases up & running. I mean, for search purposes they are equivalent. Example from ours: Poluição do ar Use for: Poluição da atmosfera Poluição atmosférica Poluentes atomosférico a search for "Poluição atmosférica" should return the records that have (wrongly) this nonpreferred term, but also the ones with "Poluição do ar" in their subject. VuFind as a synonymous table; would it be too hard to connect them? Well, I leave the idea for further analysis, I hope. Filipe Comments Comment by Ronan McHugh (Inactive) [ 17/May/12 ] If I understand correctly, this feature would essentially cut out the middle-man of the See Also box, and send users straight to search results for the authoritative term. This might be appropriate for searches where there is only one suggestion from the module, but I wonder if it is appropriate for searches where there are several suggestions? In this case, being forced to be more specific might actually be a good user experience, otherwise they will get a long list of results that they did not want. Comment by Filipe M S Bento [ 17/May/12 ] @Ronan McHugh: Hi! No, was not talking about "see also" (that is great as it is!), by no means: that would completely ruin the search experience, giving results not wanted at all! I was talking about, and only, the non-preferred terms (Use for:, block 4, not block 5 [see also]), terms that were replaced by new terminogy, that shouldn't have associated records in the database! In that case, the Authority Recommendation Module would display at the top: use xxx instead of your term and display them in the result list instead of nothing found. Most of the ILS do that. Thanks, Filipe PS: I kindly suggest consult for reference about preferred terms and non-preferred terms, an example found on the run, http://publish.uwo.ca/~craven/677/thesaur/main04.htm Comment by Demian Katz [ 17/May/12 ] The recommendation module interface allows the module to modify the main search before it is executed... so it may be a matter of adjusting the query to include an "OR" clause. As Ronan says, though, the trick is deciding when it is appropriate to do this -- if you get many possible cross-references, you don't want to apply all of them or you will have anarchy. Perhaps another possibility is to offer the option of either "change your query to this" or "add this to your query" (sort of like the "expand search" option of the existing spell check code). The problem there is finding a user interface that makes sense; I suspect nobody understands the purpose of the expand spelling option as it stands, so it's not exactly a great model to build upon. Comment by Filipe M S Bento [ 17/May/12 ] I am so sorry, but, and again, I am talking about non-preferred terms. And sorry to ask, but are you into AUT DBs deeply? I mean, are you familiar enough with "preferred and non-preferred terms" ~ "authorized forms of headings and unauthorized forms"? Sorry to be so rough, but this quite different from "see also", preferred and non-preferred terms are in practice equivalent ones; it's just a matter of evolution of the the term or use it to store the so called unauthorized forms of an heading. For instances, from MeSH: B, Lecithinase (no records in our DB) Use instead: Lysophospholipase (has link) and if we click in it (Lysophospholipase): Lysophospholipase > we get 3 records in our DB and a note: Note: 91(80); was see under PHOSPHOLIPASES 1980-90 I mean in AlphaBrowse. You should never get results from non-preferred terms if your ILS messaging queue is working ok (update Bib records from AUT ones). So to sum up: they are equivalent and "get many possible cross-references, you don't want to apply all of them or you will have anarchy" will never apply, Demian! Sorry... :) The problem is a note I am going to put in VUFIND-538 in the line of what you suggest, Demian, if we search for a non-preferred term (if it shows records --> well, they should be corrected to the preffered term) the Authority Recommendation Module shows at top, when searching for the subject "Contaminação ambiental" (for instances): See also: Poluição having the AUT record as follows: Poluição See also: Engenharia ambiental Resíduos perigosos Biorremediação Use for: Contaminação Contaminação ambiental CORRECT > It should show: Use instead: Poluição like AlphaBrowse shows! Seems little or no difference but ask your librarians and listen to what they say (I'm not a Librarian, but taught this and implemented from scratch our AUT DB). You should considered these 4xx fields (a help for the users searching for the old term to get to the right, current term in use in subject headings / fields in records as the old one should have been replaced meanwhile to the new prefered terms; and also a log, history of that term evolution. This block is also used to store unauthorized forms of headings (hey, that's why they call it an Authority database), that ILS redirect the search to te forms of authorized form of the term. Anyway, for the ones that like to have some strong authoritive reference, here you go: http://www.loc.gov/marc/authority/ad4xx.html. Hope this make this discussion a little bit more clear. Filipe PS: another example from MeSH, with a date range for the ex-preferred term, now a nonpreferred one (NANOSTRUCTURES > Nanoparticles, after 2007) - NANOSTRUCTURES should return no records, yet this term should appear a lot in the literature writen between 2005 and 2006: Nanoparticles Note: 2007; use NANOSTRUCTURES 2005-2006 Comment by Ronan McHugh (Inactive) [ 18/May/12 ] ok, apologies for the misunderstanding, I think I've got it now... If the user searches for a nonpreferred term, the module will automatically modify the search to be for the preferred term, correct? In this case, there should be no problem with the redirect, since there is only the one term. Now, it's worth pointing out that not every Authority Recommendation will only return one result. If a user's search is vague for example, there may well be several recommendations, in this case, a redirect is clearly impossible. In terms of implementation, I can imagine two paths. 1) An additional method to check for use of a non-preferred term in the authority index. If it returns true, it will modify the search terms. This method will have to be quite strict in terms of only returning true when it is definitely a non-preferred term and not just something which could be a non-preferred term, but could also be something else. 2) Functionality in the Authority Recommendation module that will check the return from the Authority index and modify the search terms if there is only one return which is a preferred term. I'd probably lean towards 1), but I'd be interested to hear other opinions. Comment by Demian Katz [ 18/May/12 ] I think we have to be a little bit careful here. I didn't previously comment about the see also/use instead distinction for a few reasons: 1.) Since we're doing a keyword search against the authority records, just because we find a "preferred term" in the results matching the user's keywords, that doesn't necessarily mean that it applies to the user's intended search. We're not in left-anchored heading search anymore, and our users generally aren't thinking that way, so our strategies have to change. 2.) For optimal authority functionality, your records need to be consistently generated using authorities. If authorities are applied properly, you have a guarantee that you'll never run across a non-preferred term. However, in reality, records aren't necessarily going to be so clean. If you harvest from multiple data sources, they may not use the same authorities. If your local catalogers haven't updated their authorities in a while, they may get out of sync with the ones in VuFind (if you're loading FAST data instead of a local authority file). Authorities may help users find things, but I don't think we can safely assume that they offer the only answer. 3.) Librarians understand and care about this distinction. I'm a librarian -- I care too. However, end users generally do not. I figured if we provided a bunch of links that might lead to better search results, the user would click one without worrying about its exact nature or origin. Perhaps it would be helpful to separate the results into "see also" and "use for" lists, but in the keyword-searching context, I don't know if that is especially meaningful. Anyway, all of that being said, I think there is some room for improvement... but a few thoughts: 1.) Any functionality that modifies the search terms should be configurable so it can be turned off. Some libraries will want it, but others will run into undesired side effects and will want to turn it off. I would recommend adding an "OR" instead of completely changing a search query, just in case some non-preferred versions of a term are lurking in the index in old records that haven't been corrected yet. 2.) If the search is modified, there should probably be an on-screen message indicating what happened and why. 3.) Perhaps search modification should happen after the search has been executed so we can account for how many records matched the original search term. Whew, this is getting long-winded. In any case, I agree with Filipe that we should use the authority data to its best advantage. I just think we need to be careful that we account for the unique strengths and weaknesses of VuFind's style of search. We can't simply behave like an old OPAC, because the data and the interface work differently. Comment by Filipe M S Bento [ 18/May/12 ] Deamian, > 3.) Librarians understand and care about this distinction. I'm a librarian -- I care too. However, end users generally do not that was why I was proposing that... as long as they get the relevant records, users don't care if they inserted a preferred or non-preferred terms / authorized forms of headings and unauthorized forms... blame Google and alike for that.. who cares to insert a term well written? Google will suggest the correct spelling and even show the results for this correctly spelled term… hey: that is exactly I am suggesting in this ticket!! :) ... as long as... > 2.) If the search is modified, there should probably be an on-screen message indicating what happened and why. Bingo! ... EDIT: Google again! :) Ok, but as it is now, with the mentioned correction of not displaying "see also" in the cases of 4xx terms (use instead), and Ronan solution is a good one (contingency one), we are good and ready to go! I mean, VuFind being a NGC solution should port to its core the same advanced features we find in OGC… :) Btw, > 1.) Since we're doing a keyword search against the authority records, just because we find a "preferred term" in the results matching the user's keywords, that doesn't necessarily mean that it applies to the user's intended search. We're not in left-anchored heading search anymore, and our users generally aren't thinking that way, so our strategies have to change. Sorry, could you please elaborate this... my bad, If I undertstood correctly that is what I am proposing, not the opposite. I think we should "skype"... :) perhaps in other words I will understand what you are saying... :) Filipe PS: but wait.... You know what would be really, really nice, as we have our Library records indexed with subjects in Portuguese? To have this feature enabled for the term in another language: e.g., AUT record: Main heading: Contaminação da água Term in English: Water - Pollution Term in English: Water pollution When a user searchs for "Water pollution" the system should retrieve our Libraries' Catalog records with "Contaminação da água" in their subject list (and yes, with a warning message too, at the top).... and again, vice-versa. As long as the AUT DB is updated (or use external ones, like EUROVOC, http://eurovoc.europa.eu/) this is an entirely new world for searches > search a term (subject) in your native language and it would retrieve records indexed with the corresponding term in any language present in AUT DB records' fields. Ah... ah... another one to think about (and I guess plenty of discussion meanwhile... :) ) PPS: we should mark these discussions as CONFIDENTIAL... :) Ok, talking serious, for sure there are ILSs out there that do this (I'm pretty sure ALEPH does... perhaps, we just don't have it configured to do it). Comment by Filipe M S Bento [ 24/May/12 ] Know what? I've test ran a solution for this, very pragmatic one: 1) Using base instructions here: http://vufind.org/wiki/stop_words_and_synonyms#synonyms 2) Data here: http://eurovoc.europa.eu/drupal/?q=pt/download/list_pt&cl=en (using EUROVOC as a test bed) EDIT: if you don't feel confortable enough (yet) with EUROVOC's Portuguese interface, you can use EN ones: http://eurovoc.europa.eu/drupal/?q=download/list_pt&cl=en (noticed? Drupal; OSS it taking the world... for free!) (download accordingly to your main language and let’s say... top of my head... I don't know which to choose, really, ok, I think I go for... closed yes choice… English! :) ) or even more langs if you have records enough to return something in that other language); 2.1) column F: =B1 & "," & C1 (fill-down for the remaining lines / expand the formula if you have more langs, beside yours and the other one I’ve randomly choose… I think it was English… :) ). 3) Copy-Paste column F to ./solr/biblio/conf/synonyms.txt (append); 3.1) Pay special attention to convert the file to UTF-8 encoding, if you have special chars in your main language --- else, SOLR won't start, when you… 3) Restart VuFind; 4) Test with some of those words or expressions, any field, subject, etc. (well, those two... all the other fields are the same whatever the lang); 4.1) Your search should retrieve records indexed with the term you have inserted, not only, but also records with that term translation to the other language; 5) If it is ok, good! If not, go to sleep (after all it’s 4am+) and with a fresh start tomorrow (yours) it will work ok (happened to me twice, but instead of 4am was... 7am!); 6) This is not, but I mean really, really, really a solution at all; it is just for you to have an idea of a multi-language theasures (much faster --- reading from a SOLR index not a txt file) may bring the discovery experience to a brand new level, that even the most expensive solutions do not "offer", if not in mistake (do it in a dev/ server... don't know the load it will put on a prod/ server!). All the best, Filipe PS: Demian: try in mines' for "poluição do ar" for instances (= air pollution). PPS: Demian, I've warned that it is the ugliest solution... is just to have an idea of a new degree in discovery... no more language barriers in finding the right terms to search for; users will have the possibility of just access the resources they feel comfortable in that language, facet filtering it. PPPS: Demian (sorry, again): your fault for me being reporting this now... was analyzing http://vufind.org/wiki/developers_call:minutes20120529 and had to relate this experience done a couple (4h) ago... :) Comment by Demian Katz [ 25/May/12 ] Filipe, As you say, this is definitely a straightforward, pragmatic solution. The only limitation is that you can't turn off the synonyms, and I suspect that in some (many?) cases they might cause the result list to include undesirable or confusing results. I think the advantage to building a recommendation module is that it could display at the top of the results: "You can broaden your search by including synonyms. Click here to try it!" ...and then add some parameter to the URL to activate synonyms. Without doing some research, I'm not sure if there's an easy way to toggle Solr's use of synonyms.txt -- I suspect it would require creating two different field types (one with synonyms, one without) and two copies of every field. I wouldn't call that an easy way. But another option is to simply let the recommendation module pre-process the search query, as previously discussed -- not as elegant or fast as letting Solr do the work for you, but possibly a less complicated solution if you want toggling. - Demian Comment by Filipe M S Bento [ 25/May/12 ] Demian, hi again! The ideal would be using the associated entry in AUT(horities) DB for the term in other languages (not discovering it in MARC21, but in UNIMARC is block 6xx, if not in mistake), if the AUT DB was well maintained for the present terminology. OR have a text version / DB (even in MySQL) version of this http://www.amazon.com/EnglishPortuguese-Portuguese-English-Dictionary-Technical-Scientific/dp/9722214926 loaded and an OR behind the scenes (switchable at search form). Demian, I also have some philosophies about certain stuff... :) one is that in a Discovery Solution any extra click represents thousands of lost clients... give them all and if they want, able them to narrow the search (facets). Most of the times, less is more, but in Discovery, this might render in letting some preciouse resources hidden (as they were before), which is step back... unless going the wrong direction (then it would be good to give a step back :) ). Filipe PS: Demian, so sorry, but not seeing any situation at all when the solution I’ve sent (proof of concept) could produce the effect of "include(ing) undesirable or confusing results"; like we (and I mean you too :) ) in high level support always ask for: examples, please :) Comment by Demian Katz [ 25/May/12 ] The "undesirable or confusing results" comment really depends on the nature of the synonyms in your system. For example, suppose we set up this synonym: lift = elevator Now someone does a search for lift, intending the concept in physics. Their search results are now going to be polluted with results about mechanisms for moving people from floor to floor within buildings. I understand that within the context of exactly matching terms from a controlled vocabulary, you are protected against this kind of thing. However, we are working in a keyword searching environment here, so these situations are more dangerous. I agree that in a discovery environment, it is good to provide the user with a lot of results and let them filter down. However, it is important that the top results returned at least make some degree of sense. Synonyms have the potential to give high relevance boosting to things that don't have an obvious relationship to the user's search query. In my lift example, if the user gets a result set where some things are about lift (the object) and others are about lift (the concept), at least it is obvious that the word "lift" is present in all of these things. If they do the same search and their top hit is the "Elevator Repair Manual" and the word lift is nowhere to be found, they may or may not figure out what has happened. If the results appear to be completely illogical, they are not going to stick around and refine them -- they are going to start over and try a different strategy. I feel that an "opt-in" strategy is safer when you risk dramatically changing the user's query. I admit that this is all speculation -- the real risk depends entirely upon the data set used... and of course it's very easy to implement this so that it can be configured to be either automatic or optin based on local preferences, so it's not like we need to come up with a single definitive answer that works for everyone. I just feel like precision still counts, even if recall is more popular in the age of discovery. Comment by Filipe M S Bento [ 25/May/12 ] Ok, you got me with that one: (to) lift (verb) = elevator (object) But I wonder, like you said, under a controlled vocabulary is there a chance of that happening more than a mere couple of times in hundreds... and I guaranty you if using a AUT DB don't won't happen because it only retrieves the related records in context, that is something that Authorities have the onus of giving. Hey, but this is me saying... Have a nice holiday weekend and see you Tuesday at “Developers’” Call; - Filipe PS: I guess this a non-ending discussion (good or bad, I just don’t know anymore :) ) --- But I'm sure something positive for VuFind will come out from it, either way it goes (or ways, as you said, let the final "customer" decide, better than not have a solution or at least have analyzed a possible one, even the decision is to maintain things as they are)! PPS: Yes, it is very annoying to explain why /Author/Home?author=Austen%2C%20Jane was retrieving info from Wikipedia about another completely different author (now it's ok: http://193.137.169.90/Author/Home?author=Austen%2C%20Jane%2C%201775-1817 >> even without the dates) and have no explanation for it, just, sorry, that is the info the system is seeing… I’m with you: accuracy above all (no excuses). [VUFIND-580] Consortium Support for Reserves Index Created: 15/May/12 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Reserves None Type: Reporter: Resolution: Labels: New Feature Phil Fenstermacher Unresolved None Issue Links: incorporate is incorporated by VUFIND-180 Better native support for consortia Open Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description The current reserves system seems to support only one reserves desk/service point. Our academic consortium has multiple libraries, some with their own reserves desk. Would it be possible to look at adding reserves desk fieldd to the reserves schema? Adding it to the schema would let us filter and facet desks while retaining the current features. Comments Comment by Demian Katz [ 16/May/12 ] I see two possible paths forward on this: 1.) We can add the same dynamic Solr fields from the biblio index into the reserves index -then you can define whatever field(s) you need for local purposes without changing the schema. 2.) Add explicit library/building/collection facets... but if we do this, I think we also need to figure out a way to make the index generation tool populate those facets. How do you plan on doing this? If we can find a simple standard solution, maybe we can get that into the trunk.... And of course, it's possible that both of these things would be useful, so maybe we want to implement both options. What do you think? Comment by Phil Fenstermacher [ 18/May/12 ] I would suggest that we come up with code to support populating facets that identify service points and explicitly add fields to the schema. Many, if not most consortia will have multiple reserve service points, likely making this much more useful than a local customization project. IMO anything in trunk is best defined in the schema (for completeness and documentation) and leave the dynamic fields exclusively for local purposes. That said, it can't hurt to add dynamic fields to the reserve schema for those local customizations. We're slowly working on code to support populating the field, and hope to submit a patch when it's done. This enhancement ticket was more of a preemptive one to make sure that no one is opposed to modifying the schema to support something like this. Comment by Demian Katz [ 21/May/12 ] Sounds good to me. I'll wait for your patch before taking any further action on this. I agree that it makes sense to define fields in the schema for clarity, and also that we might as well add the dynamic fields for unforeseen local customizations while we're modifying the schema anyway. [VUFIND-578] New recommendation module: wikipedia subject information Created: 15/May/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 1.3 Type: Reporter: Resolution: Labels: New Feature Filipe M S Bento Unresolved Result_List, Search Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Just thought of this right now, so sorry if still has rough edges: Like in Author module, we can have wikipedia info (I am using, with all the pros and cons we have discussed in the MLs) to retrieve the first lines of Author Bio, it would be nice to have that when a subject search is performed and/or entries in authorities | Browse the Collection Alphabetically, showed at the top, with links to new searches, when that applies. For instances: Microbiology Note: The study of microorganisms such as fungi, bacteria, algae, archaea, and viruses or (sorry, Portuguese, from our OPAC authority DB; previous one was from MeSH): Poluição See also: Engenharia ambiental Resíduos perigosos Biorremediação or from Wikipedia (http://en.wikipedia.org/wiki/Phenomenology_(particle_physics)) Phenomenology (particle physics) Particle physics phenomenology is the part of theoretical particle physics that deals with the application of theory to high-energy particle physics experiments. Within the Standard Model, phenomenology is the calculating of detailed predictions for experiments, usually at high precision (e.g., including radiative corrections). Beyond the Standard Model, phenomenology addresses the experimental consequences of new models: how their new particles could be searched for, how the model parameters could be measured, and how the model could be distinguished from other, competing models. Phenomenology may in some sense be regarded as forming a bridge between the rarefied, highly mathematical world of theoretical physics proper (such as quantum field theories and theories of the structure of space-time) and experimental particle physics. (....) link to the full article @ WikiP. Sorry haven't applied yet "VUFIND-538 - The authority recommendation module has been committed. In combination with the free FAST data released by OCLC, this is very powerful; it makes "subject" search much more useful than before" (or had breakfast, but that is another matter), so please do apologies if in some parts is redundant... only have a server (staging; while not having a production and a Dev one, must be very careful). See you later on at today's Dev Call, Filipe Comments Comment by Demian Katz [ 15/May/12 ] I've renamed this ticket to make the goal a little more clear (hopefully). In VuFind 2.0, the wikipedia logic that in 1.x is coded into the Author module has been separated into its own recommendation module. Presumably there should be a way to adapt that wikipedia authors module into a wikipedia subjects module that could be plugged in wherever appropriate. Comment by Filipe M S Bento [ 15/May/12 ] Ok, also because VUFIND-538 seems to do the authority recommendation part. Thanks, Filipe [VUFIND-571] Failed Advanced search goes back to Advanced search Created: 02/May/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 1.1 Type: Reporter: Resolution: Labels: New Feature Sandino Vargas Unresolved Search, advanced, failed Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Here at Western Michigan University Libraries we implemented a feature that allows users to edit a failed search This is how it looks like: https://catalog.library.wmich.edu/vufind/Search/Results?join=AND&bool0[]=AND&lookfor0[]=Milk&type0[]= edBy=abc&filter[]=&type0[]=createdate&lookfor0[]=&illustration=1&type0[]=publishDate&lookfor0[]=&subm This is a fairly simple hack that we did to the layout and other tricks on Advanced.php. We really need this func Comments Comment by Demian Katz [ 03/May/12 ] Thanks for sharing this. Are you able to post a patch showing the code? Comment by Sandino Vargas [ 02/Oct/12 ] To implement this feature we changed a couple of files related to Advanced search and the failed search templates: for the web/interface/themes/default/Search/list-none.tpl file we add part of the content of "web/interface/themes/default/Search/advanced.tpl" to it and make it load once the server finds no results (instead of clicking on a "edit your advanced search" link when it fails): {*WMU CHANGES: Adding editable advanced search form on failed advanced search*} {if $whichModuleIsThis == 'advancedFAILED'} <div class="resulthead"></div> <form method="GET" action="{$url}/Search/Results" id="advSearchForm" name="searchForm" class="search"> <h4> <b>Edit Your Failed Advanced Search</b> </h4> {if $editErr} {assign var=error value="advSearchError_$editErr"} <div class="error">{translate text=$error}</div> {/if} <div id="groupJoin" class="searchGroups"> <div class="searchGroupDetails"> {translate text="search_match"} : <select name="join"> <option value="AND">{translate text="group_AND"}</option> <option value="OR"{if $searchDetails}{if $searchDetails.0.join == 'OR'} selected="selected"{/if}{/if}>{translate text="group_OR"}</option> </select> </div> <strong>{translate text="search_groups"}</strong>: </div> {* An empty div. This is the target for the javascript that builds this screen *} <div id="searchHolder"></div> <a href="#" class="add" onclick="addGroup(); return false;">{translate text="add_search_group"}</a> <br /><br /> <input type="submit" name="submit" value="{translate text="Find"}"><br><br> {if $facetList} <table class="citation" width="100%" summary="{translate text='Limit To'}"> <tr> {foreach from=$facetList item="list" key="label"} <th align="right">{translate text=$label}: </th> {/foreach} </tr> <tr> {foreach from=$facetList item="list" key="label"} <td> <select name="filter[]" multiple="multiple" size="10"> {foreach from=$list item="value" key="display"} <option value="{$value.filter|escape}"{if $value.selected} selected="selected"{/if}>{$display|escape}</option> {/foreach} </select> </td> {/foreach} </tr> </table> {/if} <table class="citation"><th>{translate text="Illustrated"}:</th><th>Publication date:</th><tr> {if $illustratedLimit} <td> {foreach from=$illustratedLimit item="current"} <input type="radio" name="illustration" value="{$current.value|escape}"{if $current.selected} checked="checked"{/if}> {translate text=$current.text}<br> {/foreach} </td> {/if} <td width="50%"> <input type="HIDDEN" name="type0[]" value= "publishDate"> <input type="text" size="15" name="lookfor0[]" value=""> (i.e: 1950-1988)</br> For a single year, enter same year in the box (i.e.: 1999). For an open-ended range, enter -1999 (i.e.: for up to 1999) or 1999- (i.e.:for 1999 and up). </td> </tr> </table> <!-- END --> <input type="submit" name="submit" value="{translate text="Find"}"><br> {if $searchFilters} <div class="filterList"> <h3>{translate text="adv_search_filters"}<br/><span>({translate text="adv_search_select_all"} <input type="checkbox" checked="checked" onclick="filterAll(this);" />)</span></h3> {foreach from=$searchFilters item=data key=field} <div> <h4>{translate text=$field}</h4> <ul> {foreach from=$data item=value} <li><input type="checkbox" checked="checked" name="filter[]" value='{$value.field|escape}:"{$value.value|escape}"' /> {$value.display|escape}</li> {/foreach} </ul> </div> {/foreach} </div> {/if} </form> {* Step 1: Define our search arrays so they are usuable in the javascript *} <script language="JavaScript" type="text/javascript"> var searchFields = new Array(); {foreach from=$advSearchTypes item=searchDesc key=searchVal} searchFields["{$searchVal}"] = "{translate text=$searchDesc}"; {/foreach} var searchJoins = new Array(); searchJoins["AND"] = "{translate text="search_AND"}"; searchJoins["OR"] = "{translate text="search_OR"}"; searchJoins["NOT"] = "{translate text="search_NOT"}"; var addSearchString = "{translate text="add_search"}"; var searchLabel = "{translate text="adv_search_label"}"; var searchFieldLabel = "{translate text="in"}"; var deleteSearchGroupString = "{translate text="del_search"}"; var searchMatch = "{translate text="search_match"}"; var searchFormId = 'advSearchForm'; </script> {* Step 2: Call the javascript to make use of the above *} <script language="JavaScript" type="text/javascript" src="{$path}/services/Search/advanced.js"></script> {* Step 3: Build the page *} <script language="JavaScript" type="text/javascript"> {if $searchDetails} {foreach from=$searchDetails item=searchGroup} {foreach from=$searchGroup.group item=search name=groupLoop} {if $smarty.foreach.groupLoop.iteration == 1} var new_group = addGroup('{$search.lookfor|escape:"javascript"}', '{$search.field|escape:"javascript"}', '{$search.bool}'); {else} addSearch(new_group, '{$search.lookfor|escape:"javascript"}', '{$search.field|escape:"javascript"}'); {/if} {/foreach} {/foreach} {else} var new_group = addGroup(); addSearch(new_group); addSearch(new_group); {/if} </script> {/if} In the web/interface/themes/default/Search/searchbox.tpl we commented out the part that enables the user to edit the advanced search: {* WMU CHANGE: We are not using these options anymore, because we're creating the edit form for advanced search in this file {if $searchType == 'advanced'} <a href="{$path}/Search/Advanced?edit={$searchId}" class="small">{translate text="Edit this Advanced Search"}</a> | <a href="{$path}/Search/Advanced" class="small">{translate text="Start a new Advanced Search"}</a> | <a href="{$path}" class="small">{translate text="Start a new Basic Search"}</a> <br>{translate text="Your search terms"} : "<b>{$lookfor|escape:"html"}</b>" {else} END *} In this same file, we make the option that if the Advanced search was successful, give the user a link to edit it (this link will appears in the bottom part of the search box): {* WMU CHANGE: If it's a successful advanced search, give the user the opportunity to edit it *} {if $searchType == 'advanced' && $whichModuleIsThis != 'advancedFAILED'} | <a href="{$path}/Search/Advanced?edit={$searchId}" class="small">{translate text="Edit this Advanced Search"}</a> {/if} Also we add a if statement on the web/services/Search/Advanced.php, to avoid the load of the advanced.tpl template on failed searches: if (isset($_REQUEST['WhichModuleIsThis']) && $_REQUEST['WhichModuleIsThis'] == 'advancedFAILED') { // WMU: Do Not set Templates (the template will be set by the failed search tpl file) } else { $interface->setPageTitle('Advanced Search | Library Catalog | Western Michigan University'); $interface->setTemplate('advanced.tpl'); $interface->display('layout.tpl'); } The last file modified file is the web/services/Search/Results.php, where we create a couple of control variables to identified if the search returns no results and if it was from the advanced module. At the beginning we declare a control variable: // WMU CHANGE: This variable will tell the Advanced.php file to build the search // form on a failed (NON RESULT) advanced search $whichModuleIsThis = ""; later we need to know which module is the one working: $whichModuleIsThis = $searchObject->getSearchType(); Inside the if statement to know if there were no results we add: if ($searchObject->getResultTotal() < 1) { // No record found $whichModuleIsThis .= "FAILED"; // WMU CHANGE: We append the word "FAILED" to identify and Advanced failed search. $interface->setTemplate('list-none.tpl'); $interface->assign('recordCount', 0); After assigning 'showSaved', 'savedSearch', 'searchId' their corresponding values we add some control variables to the global variable $_REQUEST and load the non-result page: // WMU: Setting some control variables $_REQUEST['WhichModuleIsThis'] = $whichModuleIsThis; $interface->assign('whichModuleIsThis', $whichModuleIsThis); // WMU: Call the Advance.ph file to generate the search form, only in failed searches if ($whichModuleIsThis == 'advancedFAILED'){ require_once 'Advanced.php'; $failedAdvSearch = new Advanced(); $_REQUEST['edit'] = $searchObject->getSearchId(); $failedAdvSearch->launch(); } I hope this can help, if you need more info, let me know. For some files in this patch, there were another (waldo library specific) changes that were made, that's why I post a clean version of it and not the SVN commit. [VUFIND-555] GUI to modify relevance ranking Created: 12/Apr/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: New Feature Christian Dabrowski Unresolved None Updated: 07/May/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description It would be nice to have a GUI where one could modify the relevance ranking in Vufind by considering several values, i.e. publishing date, subject classification, subject heading, format etc. Comments Comment by Demian Katz [ 12/Apr/12 ] This is a complex task that can never be perfectly achieved through a GUI (since there are so many different options available), but some kind of basic searchspecs.yaml adjuster might be a useful tool to help people who don't want to have to dig into the YAML code. [VUFIND-535] VuFind "Landing Page" information ticker Created: 19/Mar/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface Wishlist Type: Reporter: Resolution: Labels: New Feature Luke O'Sullivan Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description Many sites now have a ticker like function which displays information pertintent to its users. VuFind could encorporate such a function on it's front page which displayed custom messages from an ini file ("E.g. System Maintenance is planned for"). It could also collate remote information such as RSS Feeds and Twitter Statuses from librarians or developers or circulation statistics etc. Comments Comment by Demian Katz [ 19/Mar/12 ] I wonder if some sort of simple plug-in mechanism for the home page would make sense to allow flexible configuration of this and other potential front-page features. [VUFIND-531] Search: included the CallNumber and it's description (heading) it in the full record view with a link to perform a search for that sequence Created: 15/Mar/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 1.3 Type: Reporter: Resolution: Labels: Improvement Filipe M S Bento Unresolved usability Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description As it is now, CallNumber [numbers that, unless you have a list to choose from you just don't know them, except you are an indexer and even so....] search field in the search form render useless; my suggestion is may involve keep it in the search form, but mostly included it in the full record view with a link to perform a search for that specific sequence in the CallNumber. Filipe PS: again (set by default, her forward) did a search here in JIRA and did not find any related ticket; please do apologize if there is Comments Comment by Demian Katz [ 19/Mar/12 ] Is the idea here that you could click on a call number to find other nearby/related records? How would you determine which search to perform? Depending on the call number system used, the rules for this might vary -- i.e. in some systems, all call numbers are unique, so you would have to search for something broader like a class. If multiple call number systems are used in a library (i.e. LC, Dewey, custom local system), how would you identify which links to apply to which call numbers? I think this would be a helpful feature, but we'll need to think about some of these questions in order to come up with a generic implementation suitable for the trunk. This may be an easy local customization for many libraries, but to come up with a generic case may require something more complicated. Perhaps some kind of regular-expression-driven configuration would do the job. [VUFIND-530] Browse the Catalog: allow both ordering by number of results (current) and by alfabetical order (request) Created: 15/Mar/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Browse 1.3 Type: Reporter: Resolution: Labels: Improvement Filipe M S Bento Unresolved Usability Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description As it is, browsing of Dewey Decimal call numbers (/Browse/Dewey), the ordering of the filtered entries is done by number of records in that particular heading. From my own experience, users when browse this kind of list are expecting to have the related headings near each other, in a hierarchically manner (like narrow terms of the broader ones). I think we should consider have an option to change that order, form in the line of of the one present in the results page for sorting order. A related ticket follows (to remove the CallNumber [numbers that, unless you have a list to choose from] search field and instead included it in the full record view with a link to perform a search for sequence in the CallNumber). Filipe PS: did a search here in JIRA and did not find any related ticket; please do apologize if there is [VUFIND-971] Make horizon access rely completely on the API Created: 01/Apr/14 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver None Type: Reporter: Resolution: Labels: Improvement Josh Bannon Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description The current HorizonXMLAPI ILS driver extends the Horizon ILS driver, which depends on Sybase horizon database access. This tight coupling to the database itself is undesirable because it will be fragile in the face of Horizon upgrades which change the database and because it requires the unusual ability to query Sybase from PHP. In some environments, we can use Sybase through mssql extensions by easily installing through apt or yum. In other environments this isn't possible. In particular this can't be easily done if you are running on Zend Server. It appears that every function supported by the HorizonXMLAPI driver is supportable through the API with the exception of getNewItems(). The behavior of getNewItems() is supportable through Solr. So in order to remove Horizon database coupling, we should implement all calls through the API. Comments Comment by Josh Bannon [ 01/Apr/14 ] This change seems like it would be best implemented in HorizonXMLAPI.php, but it will be fairly large. Would it be better to have an entirely new driver so that libraries can easily test at their leisure? Comment by Demian Katz [ 02/Apr/14 ] There are a variety of directions you could go with this, and I don't have a strong opinion on which is best. A few thoughts, however: - It would be useful to retain the existing database-driven "new items" functionality for users who want it. I think this is fairly easily done if you make the driver tolerant of missing database configuration (so that non-DB users can construct the driver without a fatal error) while leaving the existing code in place. This way, users who have DB access can continue to run as they currently do, but users without it can be encouraged to switch to Solr-driven new items. - If we decide to create a separate API-only driver, we do have the option of eventually replacing the existing HorizonXMLAPI code by simply removing the class and setting up an alias in the Zend Framework configuration (e.g. "HorizonXMLAPI" becomes an alias of "HorizonAPIOnly" or whatever we choose to call the new class). My only hesitation with the idea of a separate class is that I'm not sure how this would play with the idea of retaining optional DB-driven new items. - It may be worth polling the vufind-general and/or vufind-tech mailing lists to see how many people are currently using HorizonXMLAPI. If memory serves, it was developed by a library that has since stopped using it. I imagine there are still some people using this in the wild, but if you can't find any current users, that may make some decisions easier to make. [VUFIND-969] All Facets Created: 31/Mar/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: New Feature Chris Hallberg Unresolved None Updated: 25/Apr/14 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Add a facets option that will add an 'all' link near the 'less' link in an expanded facets. Similar to 'more', but will show all the results for that facet. There is a closed GitHub Pull Request on this here: https://github.com/vufindorg/vufind/pull/11 [VUFIND-965] Improve ISBN/ISSN handling in AllFields search Created: 06/Mar/14 Updated: 10/Mar/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 2.2, 2.2.1 Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description In VuFind 2.2, we added isbn and issn to the AllFields search specification. Because these fields are analyzed differently from other field types in the spec, this may cause some unusual side effects -- for example, a record with a bad ISBN value of simply "x" will be matched by any word containing that letter. It's also possible (though not especially likely) that this could trigger the classic "inconsistent stopword list" DisMax problem. We should evaluate whether/how to improve this situation. Some options: 1.) Investigate whether it would be appropriate to use a custom analyzer like this one: https://github.com/billdueber/solr-libstdnum-normalize 2.) Investigate whether we would get better results by copyField-ing the isbn/issn values to the allfields field instead of referencing them directly 3.) Consider the possibility of relaxing the analysis in Solr and instead do more up-front ISBN/ISSN validation It may be that the current solution is "good enough." But if you have thoughts on these or other options, please comment here. [VUFIND-951] Google Scholar Tags Created: 28/Jan/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 28/Jan/14 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Luke O'Sullivan shared this on the mailing list: --I have added google scholar tags to our vufind based repository. I took an approach similar to that used when generating openurl links: /** * Get Google Scholar Tags * * @return array */ public function getGoogleScholarTags() { $meta = array(); $format = $this->getOpenURLFormat(); $pubDate = $this->getPublicationDates(); $pubDate = empty($pubDate) ? '' : $pubDate[0]; $meta[] = array("name" => "citation_title", "content" => $this->getTitle()); $meta[] = array( "name" => "citation_author", "content" => $this->getPrimaryAuthor() ); foreach ($this->getSecondaryAuthors() as $author) { $meta[] = array("name" => "citation_author", "content" => $author); } $meta[] = array( "name" => "citation_publication_date", "content" => $pubDate ); switch ($format) { case 'Edited book': case 'Authored book': case 'Book': $meta[] = array( "name" => "citation_isbn", "content" => $this->getCleanISBN() ); break; case 'Journal article': case 'Article': $meta[] = array( "name" => "citation_issn", "content" => $this->getCleanISSN() ); $meta[] = array( "name" => "citation_volume", "content" => $this->getContainerVolume() ); $meta[] = array( "name" => "citation_issue", "content" => $this->getContainerIssue() ); $meta[] = array( "name" => "citation_firstpage", "content" => $this->getContainerStartPage() ); $meta[] = array( "name" => "citation_journal_title", "content" => $this->getContainerTitle() ); break; case 'Journal': $meta[] = array( "name" => "citation_issn", "content" => $this->getCleanISSN() ); default: break; } return $meta; } In core.phtml we then do $tags = $this->record($this->driver)->getGoogleScholarTags(); foreach ($tags as $tag) { if (!empty($tag['content'])) { $this->headMeta()->appendName($tag['name'], $tag['content']); } } --We may want to consider making this a configurable option, though if so, it should be off by default -- most VuFind instances are not serving up the sort of content indexed by Google Scholar, but for sites using it as an institutional repository front end, this would be appropriate. [VUFIND-907] Support for geographic search Created: 01/Oct/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 2.0 Type: Reporter: Resolution: Labels: New Feature Vaclav Rosecky Unresolved None Updated: 25/Apr/14 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description I'm working on geographic search in VuFind, basic implementation inspired by Ere Maijala implementation in VuFind 1.x for finna.fi can be found here: https://github.com/moravianlibrary/VuFind-2.x/tree/geo [VUFIND-902] Boost more recent editions Created: 23/Sep/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Updated: 24/Sep/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description More recent editions of items should be given a boost in the searchspecs Comments Comment by Demian Katz [ 24/Sep/13 ] How would you propose doing this? If you simply boost based on date, then newer things will always be ranked above older things -- depending on the collection being searched, that may or may not be appropriate. Do you have an idea for identifying editions and only sorting those by year? Perhaps one solution would be to put only an extremely low boost based on date so it serves only as a tie-breaker... but tuning that correctly could be tricky. If no better answer comes along, we could at least put a global date-based boost in searchspecs.yaml commented out so people know how to turn it on if they need it -- but I don't think it should be on by default, since it may cause undesired behavior, and it has a performance cost. [VUFIND-887] Add option to exclude web crawler hits from creating stats entries Created: 13/Sep/13 Updated: 24/Mar/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Statistics None Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description By using data available from http://www.robotstxt.org/dbexport.html, we could create a list of bots which could then be used to prevent web crawler hits from being entered into the user_stats and user_stats_fields tables. This should help prevent massive database sizes. Comments Comment by Demian Katz [ 13/Sep/13 ] Makes sense, and shouldn't be terribly difficult to implement since stats handling is fairly well centralized. Just a couple of thoughts/questions on design: 1.) This should be a configurable option, but perhaps on by default to prevent unexpected database overload. 2.) We should think about how to retrieve the robots database -- do we bundle the data, or have VuFind pull on the fly and cache? If we bundle, we have to keep it up to date; if we pull on the fly, we create a potential external point of failure. Perhaps some hybrid or configurable approach is best. Comment by Luke O'Sullivan [ 13/Sep/13 ] We could also go down the road of : 1) Bundling an updated file along with every VuFind 2.0 release which used on install to create a cached file 2) Having a script under util which basically updated the bundled file on request Comment by Demian Katz [ 13/Sep/13 ] Yes, that makes a lot of sense. Comment by will [ 23/Mar/14 ] I think it would be possible to detect bots via a case insensitive match for a few needles like "bot" and "crawler" in the $_SERVER['HTTP_USER_AGENT'] string. I wouldn't mind looking at this issue but I actually found this page when looking for general information on user stats and the user_stats table. I'd like to read over the documentation on the intended functionality of those, first. Can you point me in the right direction for that? Comment by Demian Katz [ 24/Mar/14 ] VuFind's statistics mechanisms should probably be considered experimental at this point; I'm not sure if anyone is actually using them for anything. The 1.x stats gathering was purely Solrbased, and 2.x introduced the user_stats_* tables as a possible database-driven alternative. There's a little bit of documentation on the plugin mechanism for creating different handlers for statistics here: https://vufind.org/wiki/vufind2:statistics_drivers Beyond that, the best documentation is probably the code in the VuFind\Statistics namespace. If you still have questions, let us know (perhaps the vufind-tech mailing list would be the best forum). If you see room for improvement, I wouldn't consider any of this to be set in stone, so feel free to make suggestions. [VUFIND-870] Asset Pipeline Created: 16/Aug/13 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface None Type: Reporter: Resolution: Labels: New Feature Priority: Joe Atzberger Assignee: Unresolved Votes: asset, cache, minify, pipeline Wishlist Minor Unassigned 1 Description At this point we have many pages delivering JS and CSS requiring multiple requests. Some of the deliveries are minified and some are not. We have the opportunity to optimize a lot of this delivery, because of the small number of different pages and the largely common set of JS/CSS, in the style of an asset pipeline. For CSS/JS on at least the home page, search results and detail page, we should combine, minify and *cache* the result. This doesn't prevent us from adding on other scripts/styles dynamically, it just makes the core more performant. Options include: https://github.com/kriswallsmith/assetic, "pipe" and roll your own. Zend may have its own version. (For development and debugging, this feature would benefit from cache visibility on the admin page and the pending "delete cache" button.) Comments Comment by Demian Katz [ 19/Aug/13 ] I agree that this would be a beneficial feature, and it's something I've had on my mind for a long time, but never found time to implement (somehow, "do it" tasks usually take priority over "do it more efficiently" tasks). I'm not aware of a native Zend Framework pipeline feature, though there is a logical place to implement this functionality: in the toString() methods of the Zend\View\Helper\HeadScript and Zend\View\Helper\HeadStyle classes. These helpers collect all of the resources, then dump out the relevant HTML to pull them in. This would be the perfect place to merge/minify/cache, assuming you have a workable mechanism for mapping relative VuFind URLs to local file paths and come up with a way of dealing with URLs pointing at third-party sites (which shouldn't exist in the core, but might happen in customized instances). A couple of obvious gotchas to think about as well: 1.) A lot of VuFind's CSS relies on relative image paths. If we merge that and serve it from a different path, those will all get broken. Not sure if/how existing solutions address this potential problem. 2.) JS minification sometimes breaks code, particularly if the code isn't syntactically beautiful and if the minification is aggressive (I'm thinking, for example, of the "JS accepts missing semicolons as long as there's a linebreak" issue). Hopefully, since VuFind uses jslint in continuous integration, that will help minimize problems... but any solution of this nature would require extensive re-testing to be safe. Might also be worth posting on the ZF developers list to see if anyone has or is building something we could reuse; as I say, I've given this thought in the abstract, but I haven't had time to see what's really out there on the ground. Comment by Anna Headley [ 21/Aug/13 ] I am totally on board with performance improvements generally, but I dislike minification. It makes in-browser debugging very difficult. I would like to see minification left out or have an option to turn this off for dev purposes. Comment by Demian Katz [ 21/Aug/13 ] I agree that minification (and indeed, the entire pipeline) should be configurable -- always useful to have the ability to turn off layers to determine whether or not they are responsible for a given problem. [VUFIND-872] Phing target phpunit fails due to memory constraints when creating code coverage Created: 18/Aug/13 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Tests 2.1 Type: Reporter: Resolution: Labels: Environment: Bug Minor Priority: David Maus Unassigned Assignee: Unresolved 0 Votes: None Linux w500 3.10-2-amd64 #1 SMP Debian 3.10.5-1 (2013-08-07) x86_64 GNU/Linux Wishlist Debian GNU/Linux jessie/sid (current Testing) PHP 5.5.1-2 (cli) (built: Aug 5 2013 14:10:28) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans Description Running the Phing target for phpunit fails with: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16777216 bytes) in /usr/share/php/PHP/Token/Stream.php on line 205 Possible solution: add -dmemory_limit-1 to phpunit call to disable memory limit. Comments Comment by Demian Katz [ 19/Aug/13 ] I'm not having any luck with the proposed solution... I edited my php.ini to reduce the system memory limit and reproduce the error, but adding the -dmemory_limit=-1 setting to the phpunit command in build.xml seems to make no difference. The setting in php.ini definitely affects the ability of the tests to run, but the -d parameter has no apparent influence. This discussion thread suggests that the setting should work, and if it doesn't, it may be due to an explicit ini_set() somewhere in code: http://stackoverflow.com/questions/8810094/phpunit-memory-limit-parameter-does-not-apply However, if that were the case, I wouldn't expect editing php.ini to have any effect either. I also tried adding ini_set('memory_limit', -1); to the test suite's bootstrap.php in case the problem was related to CLI parameter parsing, but that also failed to improve the situation. So I agree that it would be nice to have a way to fix this potential problem, but I don't have a working solution at this time. Any other ideas? [VUFIND-860] RecommendLinks recommendation module Created: 26/Jul/13 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 2.0.1 Type: Reporter: Resolution: Labels: Improvement Vaclav Rosecky Unresolved recommendation Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description I created simple recommendation module that show links to other services - useful as NoResultsRecommendations: https://github.com/moravianlibrary/VuFind2.x/commit/3b4751a22a76b85b02ad6038be1cbdaf776233e5 [VUFIND-837] Add Range option to VuFind Statistics Created: 03/Jul/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Statistics 2.0.1 Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Attachments: Updated: 18/Oct/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 vufindStats.patch Description Adding a ranged option would allow users to select stats from a particular time period and could be used in creating features like "Most Popular Item / Search of the Week/Month/All Time" [VUFIND-836] Indexing MODS records Created: 03/Jul/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Import Tools None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 03/Jul/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description This ticket is a placeholder for sharing code/configuration related to importing MODS records into VuFind. Comments Comment by Demian Katz [ 03/Jul/13 ] One option for MODS import is to convert MODS to MARC ( see http://www.loc.gov/standards/mods/mods-conversions.html ) and then use the standard MARC import tools. However, Eoghan has mentioned that in some cases, you lose important data when following this path, so a MODS-specific XSLT + Record Driver may be a better solution in some situations. [VUFIND-834] SolrCloud Configuration Created: 02/Jul/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement Benjamin Mosior Unresolved None Updated: 25/Apr/14 Wishlist Attachments: solr.xml Priority: Assignee: Votes: Minor Unassigned 0 solrconfig.xml Description This ticket is mostly to start discussion of SolrCloud configuration inclusion in the VuFind project. I think it would certainly be nice if VuFind could be HA-ready out of the box. I'm attaching configurations and general information for creating a simple 2-replica setup in a RHEL6 environment. I'm sure that this process would work fine for other typical Linux distros, though I have no idea about Windows. I used this post as a general guide: http://systemsarchitect.net/painless-guide-to-solr-cloudconfiguration/ ============ ZooKeeper Part One ============ First, I set up a zookeeper server per the guide. For the sake of simplicity, I have it running on the first vufind server. In order to blend the installation into VuFind, I downloaded zookeeper (zookeeper-3.4.5) and extracted it to vufind/solr/zookeeper. Following the instructions, I set dataDir=/var/lib/zookeeper in zoo.cfg. Other necessary components here include the "cloud scripts", which are located in the example/cloud-scripts directory of a fresh solr-4.2.1 download. I placed the cloud-scripts directory in vufind/solr/cloud-scripts. In order to get the vufind/solr/cloud-scripts/zkcli.sh working, I had to copy the following libraries from the solr-4.2.1 example/solrwebapp/webapp/WEB-INF/lib/ directory into vufind/solr/lib: commons-cli-1.2.jar commons-io-2.1.jar lucene-analyzers-common-4.2.1.jar lucene-core-4.2.1.jar slf4j-api-1.6.4.jar slf4j-jdk14-1.6.4.jar solr-solrj-4.2.1.jar zookeeper-3.4.5.jar I believe I had to run the solr-4.2.1 example server as they mention in the guide in order to extract the libraries from solr.war. Run "vufind/solr/zookeeper/bin/zkServer.sh start" on the first vufind server and make sure zookeeper starts without errors. ============ Biblio Configuration ============ I have attached my resulting vufind/solr/biblio/conf/solrconfig.xml. I imagine this sort of config would have to be used for all cores, though the <dataDir /> would have to be updated to reference each specific core in order to preserve VuFind's default solr directory configuration. ============ Solr Core Configuration ============ I have attached my resulting vufind/solr/solr.xml. Note that "zkHost" will be the same on each Solr replica if you use the IP address (not localhost or 127.0.0.1) of the zookeeper server. Also note, I used the hostname of my VM in the "host" field in order to make it more readable in the "cloud" control panel located at http://example.solr.hostname:8080/solr/#/~cloud ============ ZooKeeper Part Two ============ Change into the vufind/solr/ directory on the first VuFind server and run these commands: "./cloud-scripts/zkcli.sh -cmd upconfig -zkhost 127.0.0.1:2181 -d biblio/conf/ -n biblio" "./cloud-scripts/zkcli.sh -cmd linkconfig -zkhost 127.0.0.1:2181 -collection biblio -confname biblio -solrhome biblio" You would likely need to run the above for cores other than biblio. Then: "./cloud-scripts/zkcli.sh -cmd bootstrap -zkhost 127.0.0.1:2181 -solrhome ." At this point, it's probably a good idea to start up VuFind (/vufind/vufind.sh start) on the first core and see if you get any errors. Definitely check the "cloud" control panel mentioned above, in addition the logging section. ============ Second VuFind Server ============ Configuration on the second VuFind server should be as easy as setting the vufind/solr/solr.xml (replacing it with the attached solr.xml and updating the host field) and running "vufind/vufind.sh start". No messy modifications are necessary. After starting the second VuFind, Solr should automatically copy the index over from the first VuFind server. Comments Comment by Benjamin Mosior [ 02/Jul/13 ] I tried to document as I went through it, but I apologize in advance if I made omissions or mistakes. Regardless, this will hopefully be a good way to start discussion about SolrCloud as far as its relevance to documentation or inclusion of default behavior in the VuFind project. I started by using a full biblio index, but I haven't actually tried running any updates yet. Supposedly you can update any Solr instance, and it will push to the other(s). Comment by Benjamin Mosior [ 30/Jul/13 ] I'm posting back just to say that the SolrCloud is a semi-huge investment in terms of time and effort. For comparison, configuring a simple Master-Slave replication setup is ridiculously effortless. In /$VUFIND_HOME/solr/biblio/conf/solrconfig.xml, just add the following stanza to the bottom, uncommenting the master or slave section as appropriate: <!-- Solr Replication The SolrReplicationHandler supports replicating indexes from a "master" used for indexing and "slaves" used for queries. http://wiki.apache.org/solr/SolrReplication It is also necessary for SolrCloud to function (in Cloud mode, the replication handler is used to bulk transfer segments when nodes are added or need to recover). https://wiki.apache.org/solr/SolrCloud/ --> <requestHandler name="/replication" class="solr.ReplicationHandler" > <!-To enable simple master/slave replication, uncomment one of the sections below, depending on whether this solr instance should be the "master" or a "slave". If this instance is a "slave" you will also need to fill in the masterUrl to point to a real machine. --> <!-<lst name="master"> <str name="replicateAfter">commit</str> <str name="replicateAfter">startup</str> <str name="confFiles">schema.xml,stopwords.txt</str> </lst> --> <!-<lst name="slave"> <str name="masterUrl">http://your-master-hostname:8080/solr/biblio&lt;/str> <str name="pollInterval">00:00:60</str> </lst> --> </requestHandler> [VUFIND-826] Create ACL for VuFind Adminstration Created: 17/Jun/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Admin None Type: Reporter: Resolution: Labels: New Feature Luke O'Sullivan Unresolved None Updated: 06/Aug/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description In the future, certain administration functions may require different levels of access e.g. Tag Management, Comments Management etc vs Updates, Deletes etc Add ACL to the Admin facility will allow differentiation of users. [VUFIND-819] Allow custom view layout per record driver Created: 28/May/13 Updated: 28/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record 2.0RC1 Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Minor Unassigned 0 vufindCustomRecordView.patch Description Currently, VuFind uses the same view.phtml template for layout of all record views. If you want to allow a custom layout on a per-driver basis, the attached patch (courtesy of Luke O'Sullivan) may be useful. [VUFIND-807] Change user data and password in ILS user account (Aleph) Created: 08/May/13 Updated: 08/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver, MyResearch None Type: Reporter: Resolution: Labels: Improvement Oliver Schihin Unresolved Aleph, ILS, authentication Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description The Aleph Driver (and other ILS drivers) are not able to update or create user accounts in the ILS. It should be possible to update user data (address, phone, etc.), to create a new user and to change the password. Corresponding methods can use the Restful API and/or X-server. For address changes:http://www.exlibrisgroup.org/display/AlephOI/Address For updates through X: http://www.exlibrisgroup.org/display/AlephOI/update_bor [VUFIND-782] BackendInterface::probe(Query $query, ParamBag $params) Created: 10/Apr/13 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: New Feature David Maus Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description [int] public function probe(AbstractQuery $query, ParamBag $params = null) Returns the number of documents matching $query using $params. Use cases: - a federated search that uses a tabbed display - auxiliary searches, e.g. "The `Verfasserlexikon' contains 179 entries for `John Doe'" [VUFIND-121] Microsoft Research Pane SOAP Service Created: 07/Oct/09 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Issue Links: incorporate is incorporated by Updated: 23/Sep/12 Wishlist Priority: Assignee: Votes: VUFIND675 Minor Unassigned 0 Retrieve related records / info from ... Description We should consider developing a VuFind interface with the Microsoft Research Pane. Open [VUFIND-37] ILS Interface and display Created: 12/Dec/08 Updated: 26/Sep/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver, MyResearch, Record, User Interface None Type: Reporter: Resolution: Labels: Improvement Alan Rykhus Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description I have a suggestion for the interface between the different ILS platforms and VUFind. Since the different ILS's return different information it ends up that the display of this information is different for each ILS. Also the different ILS systems need different information to do retrieval of information. This effects patron information, holding information, and whether or not a system has certain functionality available. This effects 2 main components. First you have the interface between VUFind and the ILS. Second you have the configuration of the display of this information. To handle the first problem a standard interface can be defined between the two that includes all possible data needed to obtain information from the ILS. This can be handled by using the $user array and passing that from VUFind to the customized ILS drivers. If certain data is not needed by a particular ILS, the information is not populated in the $user array. A list of all needed data for the different ILS types would be needed and defined for the $user array. Some of these fields could mean different things to different ILS system drivers. To handle the different displays the themes functionality could be used. There would be different pages for the each ILS. These pages would know what data to expect from the particular ILS and could display it appropriately. What would really be nice is to have a default set of pages in one location, and then for the ILS customized pages you would only need the pages that are different. VUFind could look in the ILS driver directory for a page, if it did not exist, it wold then use the default page. This would keep page maintenance to a minimum. Any suggestions or comments are welcome. I finally got caught up with some system upgrade issues and plan on spending the next few weeks tweaking interface to an Aleph ILS. al Comments Comment by Demian Katz [ 26/Sep/13 ] Since this ticket was opened, the ILS driver interface has become a lot more flexible and has incorporated some of the suggestions here. I would consider the "first problem" cited here to be largely solved -- and if there are open issues related to that, more specific separate tickets should probably be opened. Regarding the display part of the problem, the idea of using the theme system to load ILSspecific templates is even more viable in VuFind 2 than it was in VuFind 1 -- we could easily build a mechanism similar to that used by record drivers to have ILS-based templates that fail back to generic default behavior. This would increase flexibility by allowing us to put in ILSspecific enhancements when needed, though I would still try to maximize the use of shared templates whenever possible. Does anyone have a specific use case where an ILS-specific template would be useful/necessary? I don't want to implement new infrastructure without a compelling reason, but if one can be provided, I'll be happy to take a closer look at this and make a proposal. [VUFIND-171] Wikipedia: non-English pronunciations not handled correctly Created: 12/Nov/09 Updated: 02/Dec/09 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Author None Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description The Wikipedia parser in the Author/Home module currently handles only English pronunications. This should be expanded to support other languages. For example, see the entry for "Johann Sebastian Bach," which includes a German pronunciation guide. Comments Comment by Demian Katz [ 02/Dec/09 ] See also the "also" reference in the pronunciation section for Tolkien's entry. [VUFIND-168] Wikipedia: handle disambiguation pages Created: 11/Nov/09 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Author None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 19/Nov/09 Wishlist Priority: Assignee: Votes: Minor Unassigned 1 Description The Wikipedia information on the Author/Home page doesn't display well when a disambiguation page is encountered... for example: http://vufind/Author/Home?author=Godfrey%2C Thomas%2C 1736-1763. http://en.wikipedia.org/wiki/Thomas_Godfrey We should either figure out a way to deal with the disambiguation, or we should detect disambiguation and hide results entirely. [VUFIND-148] More granular language indexing Created: 28/Oct/09 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Import Tools None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 19/Nov/09 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description There has been some discussion about the 041h MARC field used for "original language of a translated work." Currently, this is indexed along with other languages into the language field. However, it might be beneficial for some users to remove this from the index or index it to a separate field for more granular searching and faceting. One possible solution would be to create multiple language index fields -- something like language_all (all 041 subfields), language_original (original language) and language_expression (language of current expression) -- and then let users pick which one to turn on in facets.ini. That may be overkill for a relatively minor issue, though -- it might be better to leave it to individual institutions to customize their import process appropriately. If nothing else, we can at least put a note above the language line suggesting that 041h might be worth customizing. Please add comments/votes to this issue if you would like to see action on it. [VUFIND-126] Manipulation of result filters (derived from facets etc.) Created: 09/Oct/09 Updated: 01/Oct/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search Wishlist Type: Reporter: Resolution: Labels: Improvement Till Kinstler Unresolved None Wishlist Priority: Assignee: Votes: Minor Till Kinstler 0 Description At the moment (pre 1.0RC2) filters (fq parameters) sent to Solr with search requests are directly derived from user interaction (user selecting facet values) on the user interface. There is no easy way to manipulate those filter parameters before they are sent to Solr without hacking VuFind source code. Goal of this issue a feature that allows easy manipulation of filter parameters. We should collect use cases for filter manipulation here to get an overview of requirements before implementing the feature. Comments Comment by Till Kinstler [ 09/Oct/09 ] Use case: add a static additional filter value to any query, if a specific facet is selected. William Denton brought this up in an email on vufind-general: http://sourceforge.net/mailarchive/message.php?msg_name=Pine.BSF.4.63.0910061750460.57192%40as2.dm.e Comment by Till Kinstler [ 09/Oct/09 ] This discussion thread on vufind-tech may be relevant for this feature, too: http://www.nabble.com/Excluding-facets-tt25246056.html#a25246056 Comment by Till Kinstler [ 09/Oct/09 ] Use case: Adding dynamic filters derived from external sources We restrict access to parts of our index by applying filters to Solr queries (we have to do so because of license is We get user attributes through Shibboleth ("external source", may be any other kind of data source like LDAP, a database or a flat file as well), calculate a user's individual access rights from those attributes (with simple rules user belongs to institution A he may use collection N") and apply filters matching those access rights to each Sol request. Comment by Demian Katz [ 04/Apr/11 ] Note that the SearchObject_Solr class (web/sys/SearchObject/Solr.php) contains an addHiddenFilter() method w can be used to filter search results without displaying a selected facet value in the interface. As of this writing, it used for an optional feature of the New Items search, but this could be easily exploited to serve other purposes -a matter of deciding what configurable settings are needed and where to put them. [VUFIND-124] Circulation Stats for Popularity Created: 07/Oct/09 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Import Tools, Search None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Updated: 03/Jul/13 Wishlist Priority: Assignee: Votes: Minor Unassigned 2 Description Investigate the possibility of harvesting circulation stats, loading them into the index and using them as a factor in result ranking. Comments Comment by Joe Atzberger [ 03/Jul/13 ] This may be easiest to deal w/ using the externalFileField approach I mentioned on the last call, rather than actually hitting the index. Comment by Demian Katz [ 03/Jul/13 ] More details on ExtenalFileField: http://lucene.apache.org/solr/4_3_1/solr-core/org/apache/solr/schema/ExternalFileField.html [VUFIND-991] User manager Created: 19/Jun/14 Updated: 19/Jun/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Admin None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Demian Katz 0 Description It would be useful to have a user manager in the admin module (to delete accounts, reset passwords, etc.). [VUFIND-1007] MySQL 4-byte UTF-8 support Created: 22/Jul/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Architecture None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 22/Jul/14 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description The present MySQL configuration used by VuFind only supports UTF-8 characters up to 3 bytes long. 4-byte UTF-8 needs to be separately enabled, as described here: http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-upgrading.html There are a couple of obstacles here: - Because using utf8mb4 encoding affects field size, we should evaluate whether there is a need to increase the size of any columns. - It appears that utf8mb4 was not introduced until MySQL 5.5.3, so using this option by default would raise our minimum requirement significantly (from the current 5.1.10). Please comment on this ticket if you need this feature or have ideas related to its implementation. [VUFIND-622] Improvements to Authority Module (and Linked Data?) Created: 05/Jul/12 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 2.0alpha Type: Reporter: Resolution: Labels: New Feature Ronan McHugh (Inactive) Unresolved Authority, LinkedData Attachments: 05-07-12.patch austin clarke1.png about.png records by.png Wishlist Priority: Assignee: Votes: Minor Unassigned 4 author info.png records Description This patch is intended as a starting point for incorporating more linked data in Vufind. Authority Module: The core of the changes involves an enhanced Authority module. The current Authority module consists of only a search and a MARC view (the Details tab) of individual Authority records. This patch makes the individual record view more substantial. There is a persistent wrapper which contains information from an enhanced AuthorInfo class. In order to prevent misidentification of the Wikipedia article (the Sarah Sloane problem), the module uses the records LCCN to make a call to VIAF. This returns a json blob containing a link to the correct Wikipedia article. The module then retrieves the Wikipeda data as normal, although it will also present data from the InfoBox. Below the Wikipedia wrapper there are three tabs. Two of these tabs are populated by Search objects, Works By and Works About the subject in question. At present, these tabs are not fully functional - pagination does not work properly and facets are not being displayed. Redirects: The Authority module is now accessed primarily through redirects. When an author clicks on an author or subject in the results page or the record page, the url helper will now detect whether authority links are set in the config. If so, they will add a parameter to the request. This parameter will be interpreted by the resultsAction which will search the Authority index to find a matching record. If a record is found, the user will be redirected to that Authority record. Wikipedia Even if users don't want to use the enhanced Authority Record view, they can take advantage of improvements to the Wikipedia code. The getAuthorInfo method now accepts a direct link as a parameter. This link is populated in the module by searching the Authority Index and retrieving the raw lccn number for the first matching record. This lccn number is then passed to VIAF which may or may not return a direct link to the Wikipedia article. Users can configure whether they will only accept a direct link to the Wikipedia article or whether they will accept the best guess result in case there is no direct link from VIAF. Linked Data We would like to use this patch as a starting point for a broader discussion of use of Linked Data in Vufind. Although at present this patch only uses VIAF to get a Wikipedia link, it would be possible to extend this functionality to fetch and present information from DBPedia, Freebase etc. We will try and begin this discussion on the mailing list. Comments Comment by Filipe M S Bento [ 05/Jul/12 ] Ronan, This is no less than <fantastic> stuff; can't hardly wait to try in my staging install (and wrap/close this comment with </fantastic> :) )! For the ones that prefer to make backup of the files altered by patches, you can use the command (although most of them are new ones --- even got FLICKR as source for images… really great stuff!): lsdiff 05-07-12.patch | xargs tar cf 05-07-12.patch_backup_changed_files.tar Acctually will only backup “marc_auth.properties” all the other are new… well, perhaps this command might be more useful in the future. With this one one, you shall get a lot of "tar: (....) : Cannot stat: No such file or directory" messages. Congrats Ronan, once again, Filipe EDIT: ah... this is for 2.0alpha... was not recognizing most of the files (well, root folders: "application" and "library", because I'm still in 1.3. Guess I have to pass this one... :( I suppose you do not have a 1.3 compatible (not ZendF1, plain old pear/smarty working one?) Nevertheless, it was my first look at VF2.0 code and patches like this one of yours promise a great future for VF2 (ZF2). Comment by Ronan McHugh (Inactive) [ 06/Jul/12 ] Hi Felipe, afraid that I don't have it for 1.x unfortunately. The Flickr stuff shouldn't actually be in there, that is from a porting over of our work with Flickr in 1.x to 2.0 alpha. There is also a patch for that which I have shown to Demian, but it will have to wait until 2.0 beta to be incorporated into the trunk (as will this one). Comment by Demian Katz [ 28/Nov/12 ] Since this ticket is no longer useful as-is (being built against an early 2.0 alpha that is now completely obsolete), I have spoken to Ronan and Eoghan about the spirit of the patch so we can recreate it against current 2.0 code in the future. Some relevant quotes from our correspondence: --Ronan (on the intent of the patch): Since we have digitized a lot of our authority data recently, it made sense for us to try and use it in some way. In this case, the use case is from users clicking on an author’s name on a record or results page. The Authority/[authorityId] page thus became a central point for aggregating all information we possessed about that entity, which in this case consisted of two biblio searches, a VIAF/Wikipedia call, and the data parsed from the authority record itself. More resources could be added to this central point if they were available. The same module could also be used for aggregating information about specific subjects, which could be accessed in much the same way. --Eoghan (general information/future direction): I think being able to handle records for people, places, concepts/subjects in addition to bib records would be a great addition to VF2. As Ronan said, VUFIND-622 was mostly a proof-ofconcept. However, a lot of what we were aiming for seems to be covered by what David was talking about in this thread: http://vufind-tech.2307425.n4.nabble.com/Params-Results-OptionsRecords-Collections-td4654583.html . So maybe the need for ugly hacks will be handled as part of David's VF2 refactoring? Trove is a good example of how this would look: http://trove.nla.gov.au/people/612352?q=writer&c=people . Or WorldCat Identities too. There is also the tie in with the Linked Data world which we discussed here: http://vufindtech.2307425.n4.nabble.com/More-use-of-Linked-Data-in-Vufind-td4654263.html [VUFIND-404] Record's details view, new tab: Community Created: 16/May/11 Updated: 23/Oct/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record 1.1 Type: Reporter: Resolution: Labels: Environment: Improvement Minor Priority: Filipe M S Bento Unassigned Assignee: Unresolved 0 Votes: OpenSocial, collective-intelligence, community, plugins n/a Attachments: VuFind_Record_CommunityTab_facebook.png VuFind_Record_CommunityTab_facebook_comment_using.png facebook.patch pt.patch Wishlist Description Community can play an important role in helping resources' discovery, by evaluating and recommending them. Web 2.0 components, and the collaborative and participatory environment associated with their use, can help enrich information search, discovery and retrieval systems, gathering the potential knowledge distributed among its users. These components can prove to be a precious asset in promoting collective intelligence by knowledge sharing, encouraging the users to evaluate the resources found, so that the next users, when conducting a similar search, can obtain and assess the most relevant results ("Search > Find > Evaluate > Understand> Share" cycle). The attached patch adds a new "Community" tab to record's details view. As it is, this tab is populated, as a proof-of-concept, with facebook plugins, but it can be populated with scripts from http://www.google.com/friendconnect or any other similar "OpenSocial" service that allows refering to each record freely (i.e., without a prior registration to have a key for each "object" (URL)). This is a "plug'n'play" patch: no API / developer key needed to have it running. Regarding the included scripts: Facebook offers a series of Social Plugins (http://developers.facebook.com/docs/plugins/) that allow not only publishing the URL and description of VuFind's resources in Facebook profile wall (share on user's News Feed), but also to discuss them within VuFind (even without publishing them in user's news feed). The attached patch is a very simple implementation of three of these: - Send: besides allowing to share with other facebook users, it's main value resides in the fact that allows to publish the title and link of the current record to a group(s) in facebook, commenting it (optional); a user by using this feature recommends that resource to a certain group he/she belongs and thus may start a discussion around it and allows it's discovery to other users with similar interests, being this the main motivation to implement this feature; - Recommend: a special form of "Like" button, using the verb "recommend", instead, in all references (in VuFind record's view or in facebook wall); facepile will display the facebook profile pictures of users who have recommended that resource; - Comments: allow to discuss it within the record page, publishing it, optionally, in the user's news feed. These comments can be commented themselves and have all of the "Like" funcionalities. NOTE: as it is in the patch, comments are not moderated. To allow moderation it necessary to indicate the facebook user id(s) of the moderator(s) in the XFBML ("simply include open graph meta tags on the URL specified as the href parameter of the plugin" > http://developers.facebook.com/docs/reference/plugins/comments/). Due to its nature, this plugin allows users to participate whether or not they have signed into VuFind, thus expanding the gathering of added value information from users outside the local community, without anykind of extra processing or storage needs, as all of the information is stored in facebook (for better or worst -- cloud computing / free services common concerns). Revised and complemented by Demian (thanks for all the support!), please apply this patch from VuFind root (default: /usr/local/vufind/). Comments Comment by Filipe M S Bento [ 16/May/11 ] This new tab is not intended, by all means, to replace VuFind native "comments", the excellence placeholder for users' reviews of that resource. Rather, it was sought, namely the facebook "comments" part, to be a place where users post questions, their answers, recommendations of related resources, etc., all of this aggregated and visible within the record view. Comment by Filipe M S Bento [ 16/May/11 ] If a user does not have an active facebook account, he/she's presented the option to comment using other services account, by associating it with the facebook account. Comment by Demian Katz [ 16/May/11 ] Supplemental patch to update Portuguese language file with new strings. Comment by Andrea Marchitelli [ 09/Oct/14 ] Any interest in porting to 2.x version? Comment by Demian Katz [ 23/Oct/14 ] It should be easier to implement this as a plugin with 2.x's RecordTab interface. I think the original patch was a proof of concept and needed a bit more polishing -- the question is whether this is something that could be configured to display particular widgets, or if the ever-changing nature of social media functionality makes it more logical to leave these sorts of things as local customizations. (Though even if local customization is the best answer, having an example or how-to would be useful). [VUFIND-583] language names in VuFind’s internationalization files Created: 22/May/12 Updated: 14/Nov/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Browse, Search None Type: Reporter: Resolution: Labels: New Feature Christian Dabrowski Unresolved feature Attachments: de.ini es.ini fr.ini language_map.properties language_map_iso639-1.properties Issue Links: incorporate incorporates Wishlist Priority: Assignee: Votes: VUFIND-1044 Minor Unassigned 1 Translation for language names Open Description Demian wants to include the language names in VuFind’s internationalization files so that they can be translated in relation to the user’s current language setting, rather than requiring them to be translated at index-time. As I translated the mapping of the language_map.properties file into german I open this ticket in agreement with Demian. Comments Comment by Demian Katz [ 22/May/12 ] Thanks for sharing these, Christian. Just to give everyone a status update on where things stand: up to VuFind 1.3, all of the language files included the same values for language names. These values translated the names from the English defaults in the configuration file into their native forms (i.e. "German => Deutsch"). This was necessary to ensure that the language selection drop-down list always showed options that would be understandable to a user who wanted to change to their own language. Starting in VuFind 1.4, these "native translations" have been moved to their own separate translation file -- native.ini. This makes it easier to maintain the language files (no need to add a new line to every file when a new language is introduced) and also opens up the possibility of translating language names in a more useful way outside the context of the language selection drop-down. I'm not sure when I'll get around to taking care of this -- there are a number of clean-up tasks in the language files that need to be addressed in order to start taking advantage of translatewiki.net, which I hope to do eventually -- but it is very helpful to have these German strings ready to go when the time comes (probably sometime after the release of 2.0). Comment by Demian Katz [ 21/Aug/14 ] Until this issue is resolved, adding language translation is currently a matter of making three customizations: 1.) You'll need to add all of the language translations from English to other-language equivalents in your language files. You can create custom language files for this purpose in your local/languages folder (local/languages files are merged with, rather than fully replacing, the default language files). 2.) You'll need to turn on translation for the language facet -- this can be done with the translated_facets[] setting of the [Advanced_Settings] section of facets.ini. 3.) You'll need to customize the RecordDriver/SolrDefault/core.phtml template of your theme to replace the escapeHtml() call with a transEsc() call in the loop that displays the language names. If anyone goes to the trouble of doing this and can share their custom translation files here, that would be helpful for future reference. Comment by Johannes Ruscheinski [ 26/Aug/14 ] Following Demian's steps, 1.) through 3.), I managed to get things working for German. This is my local/languages/de.ini. I tried to delete all identity mappings (x = "x") which is why several languages are missing. I hope it may be useful for someone else. Comment by Demian Katz [ 26/Aug/14 ] Thanks for sharing! I would actually advise against removing identity mappings, however; since VuFind will sometimes default to different language files if entries are missing, leaving out identities may actually lead to unexpected/undesirable behavior. Comment by Johannes Ruscheinski [ 08/Sep/14 ] Mapping for over 400 language names corresponding to the ISO 639-2 codes from English to French. Comment by Johannes Ruscheinski [ 09/Sep/14 ] A partial mapping (186 entries) from English language names as found in .../import/translation_maps/language_map.properties to Spanish. [VUFIND-946] Would It be possible to add a title level reserve link on the search results page Created: 03/Jan/14 Updated: 16/Dec/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 1.4, 2.1 Type: Reporter: Resolution: Labels: Environment: Improvement Allen Patrick Unresolved reserve, results, search Linux ubuntu 12.4 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description My users want to know if I could add a reserve title link on the search results for every title found. Is this something that could be done easily or would it be a can of worms? Comments Comment by Demian Katz [ 06/Jan/14 ] You should be able to achieve this technically by taking some of the logic found in the RecordTab/holdingsils.phtml template and copying it into RecordDriver/SolrDefault/resultlist.phtml. (That's the 2.x solution, but I imagine it would be similar in 1.x, just with slightly different template names). It's not completely straightforward, for at least two reasons: 1.) There may be performance implications -- depending on how your ILS works, getting the title-level hold information may be a somewhat expensive operation. Doing it for every single search result might be problematic. 2.) Since users have to be logged in to place title-level holds, you may have to think about how to present the "please log in" reminder in the search results context. It might make sense to add this as a configurable option (off by default), but it's likely more complicated to do it generically within the VuFind core than it is to do it as a local customization for your specific instance. Let me know if you need more guidance, and if you get it working to your satisfaction, please share a patch here so we can consider adapting it as a standard option. Comment by Allen Patrick [ 16/Dec/14 ] I have added code to the /usr/local/vufind2/themes/blueprint/templates/RecordDriver/SolrDefault/result_list.phtml It puts a link on the search results page which brings the user directly to the /usr/local/vufind2/themes/blueprint/templates/record/hold.phtml form so the user can just press one button to verify that they indeed want to make the reserve. It brings up the offer to login if they are not already logged in. I have been trying to figure out how I can put a setting in one of the config files to turn the feature on and off. Currently as you can see below I am using the [QRCode] section and setting showInResults = true I have not been able to figure out how I could have my own section like [AllowOneClickReserve] and having allowOneClick = true for example to make this feature turn on or off with a setting. If someone could point me in the right direction on setting this up I would be most thankful. <? if ($QRCode = $this->record($this->driver)->getQRCode("results")): ?> <img src="<?=$this->imagelink('silk/book_open.png')?>" style="margin-left:2px;verticalalign:text-bottom"/> <? $holdings = $this->driver->getRealTimeHoldings(); $holdlink = ''; foreach($holdings as $key => $value) { foreach( $value['items'] as $value2 ) { if ( $value2['addLink'] == 1 ) $holdlink = '/Hold?' . $value2['link']['query']; } } if ( strlen($holdlink) > 7 ) { $holder = $this->recordLink()->getUrl($this->driver) . $holdlink; echo '<a href="' . $holder . '">Reserve this now!</a>' . '<br>'; } ?> <? endif; ?> Comment by Demian Katz [ 16/Dec/14 ] You could add a new method to VuFind\View\Helper\Record which checks the configuration. This is the class being called when you make the $this->record($this->driver)->getQRCode() call. If you look at the getQRCode method, you should be able to figure out how to create a similar (and in your case, much simpler) method for checking a different setting. Let me know if you still have any questions! Comment by Allen Patrick [ 16/Dec/14 ] Thanks Demian One thing that I thought was weird when I started looking into it was that the QRCode section has a "showInResults" setting that turns it on. However I used grep to see where it was accessed and could only find reference to it in the config.ini file and no where in the code. I cannot figure out how that could be. Comment by Demian Katz [ 16/Dec/14 ] I think the reason you're not finding the string is that it's dynamically generated... there's a function that takes a section name, and prepends "showIn" to it in order to generate the key that needs to be looked up. So there's no "showInResults" key in the code... [VUFIND-856] adjust index-alphabetic-browse to work with a replicated index Created: 23/Jul/13 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Browse None Type: Reporter: Resolution: Labels: Improvement Anna Headley Unresolved None Attachments: Wishlist Priority: Assignee: Votes: index-alpha-replicated-dk.patch Minor Unassigned 0 index-alpha-replicated.diff Description the script assumes your index is in a dir called index. Replicated indices look like index.index_version_number. small patch attached. Comments Comment by Demian Katz [ 06/Aug/13 ] Anna, See attached index-alpha-replicated-dk.patch -- I've expanded your patch so that the index detection is a function, and that function is applied to both the biblio and authority index directories. Please let me know if this still works for you (I tested it with fake data on my system, but I don't have a replicated index that I can easily test with "for real"). If this works for you, I'll go ahead and commit it... though I'm a little concerned that it's going to be nearly impossible to replicate this functionality in the Windows batch file version of the script. Any ideas on that? Thanks! Comment by Benjamin Mosior [ 06/Aug/13 ] Demian, I figured I would chime in: I went ahead and tested both in our slave (biblio/index.$version) and master (biblio/index) environments, and the alphabetical browse script handled locating the index in both cases. It's still running (8.6M records) in both environments, but I don't anticipate any issues related to this particular patch. Comment by Demian Katz [ 07/Aug/13 ] I've committed the revised patch here: https://github.com/vufind-org/vufind/commit/a86f32b16b0c63abdfc8cdbab3a45c373a72e41f ...so AlphaBrowse will be compatible with replicated indexes under Linux starting with release 2.1. However, since Windows support is more difficult and I haven't had time to work on it, I'm going to leave this ticket open for now. I don't think this is a particularly high priority, so please comment here and remind me about this if you actually need the functionality in Windows. Comment by Anna Headley [ 14/Aug/13 ] Thank you, Ben. I'm having a little trouble with my test setup right now on this front, and after putting a bit of time into trying to figure it out I need to let it go for now and move on to something else so I appreciate you testing this!! And thank you, Demian, for your improvements. I unfortunately can't help with the Windows issue. [VUFIND-761] Change phpcs coding standard Created: 08/Mar/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Tests None Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved None Updated: 16/Feb/15 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description The current PEAR coding standard does know about the `inheritDoc' annotation. This annotation is extremely useful for methods that implement an interface or abstract class. Comments Comment by David Maus [ 08/Mar/13 ] Related: Allow docstring of unit test methods to be empty. The method name could speak for itself, e.g. /** * @expectedException InvalidArgumentException * @expectedExceptionMessage not exist */ public function testConstructorThrowsPathNotExists () { $a = $this->getMockForAbstractClass('Zend\Http\Client\Adapter\AdapterInterface'); $d = new CaptureDecorator($a, 'i-do-not-exist'); } /** * @expectedException InvalidArgumentException * @expectedExceptionMessage not a directory */ public function testConstructorThrowsPathNotDirectory () { $a = $this->getMockForAbstractClass('Zend\Http\Client\Adapter\AdapterInterface'); $d = new CaptureDecorator($a, __FILE__); } Comment by Demian Katz [ 08/Mar/13 ] Looks like the Symfony2 standard has support for @inheritDoc -- here's the pull request: https://github.com/opensky/Symfony2-coding-standard/pull/21 I'm not familiar enough with phpcs internals to know the best path forward here -- do we make a pull request for the existing PEAR standard, or is there a different way? Obviously it would be ideal to achieve this in a way that doesn't require extra complex setup for everyone who uses phpcs. Comment by David Maus [ 23/Jul/13 ] Recent version of PHP CodeSniffer support a phpcs.xml configuration where one can specify which rules to pick: https://github.com/squizlabs/PHP_CodeSniffer/wiki/Annotated-ruleset.xml Comment by Demian Katz [ 23/Jul/13 ] Great -- if you want to propose a configuration, I'll be happy to upgrade the CI server if necessary. Comment by Demian Katz [ 16/Feb/15 ] Now that phpcs 2.x is out, I thought I would revisit the issue. Still seems to be under discussion here: https://github.com/squizlabs/PHP_CodeSniffer/pull/214 [VUFIND-747] Create Breadcrumb Helper for VuFind2 Created: 15/Feb/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface 2.0beta Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Attachments: Updated: 16/Feb/15 Wishlist Priority: Assignee: Votes: Minor Luke O'Sullivan 0 breadcrumbs.patch Description Breadbrumbs are currently assigned in the templates like: $this->layout()->breadcrumbs = '<em>' . $this->transEsc('Search') . ': ' . $this->escapeHtml($lookfor) . '</em>'; This solution lacks flexibility as if a user wished to changed the html layout of the breadcrumbs, they would be forced to edit every breadcrumb instance. There is a Zend2 Breadcrumb helper: http://framework.zend.com/manual/2.0/en/modules/zend.view.helpers.navigation.html#zendview-helpers-initial-navigation-breadcrumbs but the helper appears to be based on the Zend2 Navigation helper which VuFind does not utilise. Demian has suggested a breadcrumb view signature like: addElement($text, $link) addRawElement($html) getElements() removeElement($i) show() So then the layout would do $this->breadcrumbs()->show() which would allow other templates to manipulate breadcrumbs and allow users to create custom helpers should they desire. Comments Comment by Demian Katz [ 15/Feb/13 ] Thanks for discovering the ZF2 helper. At a glance, it does appear to me that writing a custom breadcrumb helper is going to be less complicated than trying to incorporate the Zend Navigation structure (which seems a bit overly complicated to me, though perhaps I'm misunderstanding its nature). If anybody has strong opinions about using the native ZF2 mechanism, I'd be interested to hear more about that. But we can always migrate later if we have to. I should also note that my proposed method signature was devised in about two minutes, so it's not necessarily a well-thought-out design. Comments are welcome (and Luke, feel free to change it for pragmatic reasons while you work). It definitely would make sense to implement a fluent interface (i.e. most method return $this) so that you can chain calls like: $this->breadcrumb()->addElement('Home')->addElement('Search')->addElement('Record'); I'd also recommend avoiding implementing anything we don't need -- e.g. if there is no use case for addRawElement(), ignore it for simplicity. Might also be good to borrow the get/setSeparator idea from the native ZF2 helper. Comment by Luke O'Sullivan [ 26/Feb/13 ] Initial Breadcrumbs Patch Comment by Luke O'Sullivan [ 26/Feb/13 ] The attached breadcrumbs patch contains the following features: 1) A breadcrumb section in config.ini ; This section controls how breadcrumbs are generated. [Breadcrumbs] ; Available methods are "separator" to build breadcrumbs using a defined separator, ; "ol" for an ordered list and "ul" for an unordered list method = "separator" ; standardTag determines which tag (if any) standard breadcrumb items are enclosed ; in. Choose a standard html tag or false for none. Only applies to separator ; method. standardTag = false ; standardClass determines which class (if any) is added to the standard breadcrumb ; items. Use false for none; standardClass = false ; lastTag determines which tag (if any) the final breadcrumb item is enclosed in. ; Choose a standard html tag or false for none; Only applies to separator method. lastTag = "em" ; LastClass determines which class (if any) is added to the final breadcrumb item. ; Use false for none; lastClass = false ; sepatorTag determines the tag used for generating separators; ; Choose a standard html tag or false for none; separatorTag = "span" ; separatorClass determines which class (if any) is added to the separator tag. ; Choose a standard html tag or false for none; separatorClass = false ; separatorValue detmerines what text is outputted as the separator separatorValue = ">" 2) An updated layout.phtml and results.phtml for testing 3) A breadcrumbs helper The breadcrumbs helper has the following public functions 1) AddElement (Adds an element to the breadcrumb array plus an optional link and key for reference) 2) AddRawElement (Adds a html element to the breadcrumb array plus an optional key for reference) 3) GetElements (Retrieves the breadcrumbs array) 4) HasBreadcrumbs (Returns boolean true or false) 5) Remove Elements (Removes an element by index or key) 6) Show (Outputs the breadcrumb trail) Current issues 1) Mixing of keys / indexes 2) Removing an item by index will break the index order (It may be possible to create two arrays which map between an indexed array and a key array) Possible enhancements 1) Additional functions like addBefore, addAfter, replaceAt Comment by David Maus [ 06/Mar/13 ] What speaks against a custom implementation and for the Zend helper is a) combatting the NIH (Not Invented Here) and more importantly b) maintenance costs. The less custom code for common requirements of a web application, the more specific code for our domain. It all adds up. Bonus: Utilizing Zend as much as possible opens up the possibility to outsource certain parts of application development. Comment by Demian Katz [ 06/Mar/13 ] I agree that utilizing Zend is ideal in theory -- but the Zend breadcrumb helper seems to be tightly bound with the Zend navigation helper, and that seems to be oriented toward building a more static sort of site than VuFind. I didn't look deeply, so perhaps my initial impression is incorrect -- I'm certainly open to a proposal about how to use the ZF helpers within VuFind; I just didn't see an obvious way forward from glancing at the docs. Comment by Demian Katz [ 28/May/13 ] Since there hasn't been sufficient time to discuss this in depth, I'm pushing the fix version up to 2.1. [VUFIND-878] Use abstract base class for listeners, implements SharedAggregateListenerInterface Created: 30/Aug/13 Updated: 16/Feb/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search 2.1 Type: Reporter: Resolution: Labels: Improvement David Maus Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description All our search listeners attach to the shared event manager. Unless the process towards 2.2 indicates otherwise we should use an abstract base class for search listeners that implements Zend's SharedAggregateListenerInterface (similar to https://gist.github.com/dmj/6281336 but with an abstract public function onSearchPost). Comments Comment by Demian Katz [ 30/Aug/13 ] This makes sense to me -- but do we want to require implementation of onSearchPost? Not every listener will necessarily need it. Should hooking that event be optional, either controlled by an Interface or a class property? Either way, would you like to work on this, or should I put it on my list? Comment by David Maus [ 08/Sep/13 ] I think I would opt for a onSearchPost that simply returns as the default but I also think it is too early to make this decision + too early to really start working on it. [VUFIND-1000] Option to pre-filter search/home Created: 15/Jul/14 Updated: 19/Feb/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Right now, the search/home screen shows a search box, plus links to facet values. You can either perform a search, or click a facet to pre-filter. It would be nice to offer the ability to replace the facet links with checkboxes, and allow those checkboxes to pre-filter the search entered in the search box, somewhat similar to the way the advanced search screen works. Comments Comment by Demian Katz [ 15/Jul/14 ] Some initial thoughts for future reference... Ideal Solution - Add a mechanism to search/searchbox.phtml that allows the injection of additional controls inside the main search form. - Add a configuration option to turn on search/home pre-filtering via config.ini. - Modify search/home.phtml so that, based on the appropriate configuration, it can render checkbox controls and inject them into search/searchbox.phtml as an alternative to its current rendering of links. - The checkbox controls should have a name of 'filter[]' and a value containing the filter value prefixed with ~. - Because of the way search/home.phtml is shared by other modules (Summon, WorldCat, etc.) we need to be careful that adding this feature for Solr doesn't break other areas. Quick and Dirty Solution To prototype this without having to build the infrastructure for configuring / injecting into searchbox.ini, it should be possible to modify search/home.phtml so that, instead of including search/searchbox.phtml, it renders its own custom search form. This would not be a suitable solution for inclusion in master, but it's likely workable as a local solution, especially for VuFind implementations that only use one search module (Solr) rather than multiple (Solr+Summon, etc.). Comment by Chris Hallberg [ 16/Jul/14 ] Congratulations! 1000 tickets! Comment by Demian Katz [ 24/Jul/14 ] Code to implement a format drop-down in the search box (definitely not master-worthy, but workable in some contexts): <select name="filter[]"> <option value="id:[* TO *]">All Items</option> <? $formats = array('Book', 'Journal', 'etc.') ?> <? foreach ($formats as $format): ?> <? $selected = (isset($this->filterList['format']) && is_array($this->filterList['format'])) ? in_array($format, $this->filterList['format']) : false; ?> <option <?=$selected?'selected = "selected" ' : ''?>value="format:<?=$this>escapeHtmlAttr($format)?>"><?=$this->escapeHtml($format)?></option> <? endforeach; ?> </select> [VUFIND-566] Twilio Support for SMS Created: 26/Apr/12 Updated: 02/Mar/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: Improvement Phil Fenstermacher Unresolved None Attachments: Wishlist Mailer.php Priority: Assignee: Votes: Mailer.php.diff Minor Unassigned 1 sms.ini.diff sms.tpl.diff Description Because of some of our recent frustrations with sending text messages via e-mail I decided to hack together a patch so that VuFind can send SMS messages using Twilio. The method is configurable in the sms.ini file (valid values are mail or twilio). A full new version of Mailer.php file is attached since the generated patch isn't the easiest to read. Comments Comment by Tom Misilo [ 24/Feb/15 ] I don't have a 2.x version of VuFind currently running. I was wondering if anyone has time to possibly look at implementing this, otherwise I may be able to do it, however it will be probably Fall before I will have time. I just wanted to say Twilio does have a PHP Library available for composer: https://github.com/twilio/twilio-php Comment by Demian Katz [ 02/Mar/15 ] I don't have access to the Twilio API (I assume this isn't free), but I suspect that an implementation should be fairly straightforward if you adapt the existing VuFind\SMS\Clickatell class. It's entirely possible that it's easier to use the library you mention rather than looking at the old 1.x code. If you need any architectural advice or code review, let me know and I'll be happy to help... but I'm not well positioned to implement this on my own. [VUFIND-686] Create an index from SuDoc numbers (Superintendent of Documents) Created: 04/Oct/12 Updated: 21/Mar/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Import Tools, Search None Type: Reporter: Resolution: Labels: New Feature Minor Priority: Sandino Vargas Unassigned Assignee: Unresolved 1 Votes: Documents, Superintendent, marc, schema.xml, sudoc Wishlist Description For libraries, like Waldo Libraries here at WMU, that have government documents it is important to define and index a SuDoc number. We implemented a solution for this, that may be of help to other libraries. We defines the field in solr/biblio/conf/schema.xml as: <field name="sudoc" type="string" indexed="true" stored="true" multiValued="true" termVectors="true"/> In the file import/marc_local.properties we define the index (we actually use script(callnumber.bsh) instead of 'custom' since we are stripping white spaces and periods from these numbers): sudoc = custom, getFullCallNumber(086a) To define the search query on web/conf/searchspecs.yaml we did: sudoc: CustomMunge: docno: # Strip whitespace, quotes and periods: - [preg_replace, '/[ "\.]/', ""] - [preg_replace, '/\:/', "\\:"] # Strip pre-existing trailing asterisks: - [preg_replace, "/\*+$/", ""] # WMU: Convert to a left anchored search - [append, "* "] QueryFields: - sudoc: - [docno, 300] We also integrate SuDoc searches as part of cal lnumber searches as well. I hope this can help someone. Comments Comment by Tom Misilo [ 08/Apr/13 ] so did you use: sudoc = script(callnumber.bsh), getFullCallNumber(086a)? instead of custom, ...? Also, I was wondering how you got the call number to display on the item page? For example: https://catalog.library.wmich.edu/vufind/Record/1407941/Details#tabnav Comment by Tom Misilo [ 09/Apr/13 ] Also, have you implemented browsing by call number for SuDocs? Comment by Sandino Vargas [ 19/Apr/13 ] Hello Tom Misilo. Q--so did you use: sudoc = script(callnumber.bsh), getFullCallNumber(086a)? instead of custom, ...? A--We use "sudoc = script(callnumber.bsh), getFullCallNumber(086a)" because we made some changes in the way the Call Numbers and the SuDoc Numbers are processed, i.e., we striped spaces and period sings out of them. Q--I was wondering how you got the call number to display on the item page? A--We use the custom field 999 and add the call number to one of its subfields (we use subfield 'e'). From there, we use the web/RecordDrivers/MarcRecord.php file and in the function getCoreMetaData() we use: $marc = new File_MARC(str_replace(array("\n", "\r"), '', $this->fields['fullrecord']), File_MARC::SOURCE_STRING); to get the fields from the fullrecord variable. Then proceed to find the 999|e: if ($marcRecord = $marc->next()) { $callNumber = ""; if ($field = $marcRecord->getField('999')) { if ($subfield = $field->getSubfield('e')) { $callNumber = $subfield->getData(); } } $interface->assign('coreHoldings', $callNumber); } Then, to display, we change the web/interface/themes/blueprint/RecordDrivers/Index/core.tpl and add the following code after line 13 (or it can be placed whatever you want to be display): {if $coreHoldings} <tr> <th>{translate text="Call Number"}: </th> <td>{$coreHoldings|escape}</td> </tr> {/if} Q--have you implemented browsing by call number for SuDocs? A--We have not. If you have any questions please let me know. Comment by Tom Misilo [ 21/Mar/15 ] Thanks Sandino, I was wondering if you can share the customizations that you did to the callnumber.bsh to handle SuDoc's? Thanks! [VUFIND-287] Formatting of punctuation, text alignment, etc., in Hebrew (and Arabic) may be compromised Created: 07/Jul/10 Updated: 24/Jun/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface 1.0RC2 Type: Reporter: Resolution: Labels: Task Daniel Lovins (Inactive) Unresolved None Issue Links: incorporate is incorporated by Wishlist Priority: Assignee: Votes: VUFIND149 Minor Unassigned 0 Standardize/update language translati... Open Description Due to the absence of Unicode Formatting Characters in application source code, inconsistencies in punctuation handling (e.g., as contained in mapping files or supplied by templates) and other complications of bidirectional script, text alignment and punctuation may be problematic in certain cases. A related issue is the fact that Hebrew translations for prepositions like 'in', 'to', 'by', are prefixes rather than space-delimited words, so display may not always look correct. Comments Comment by Demian Katz [ 24/Jun/15 ] See https://github.com/vufind-org/vufind/pull/409 [VUFIND-526] Comment spam filtering with recaptcha Created: 09/Mar/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Reopened VuFind Record None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Updated: 06/Oct/15 Wishlist Priority: Assignee: Votes: Minor Chris Hallberg 2 Description As an alternative/complement to VUFIND-326, it would also be useful to have a configurable option to turn on recaptcha (or something similar) to reduce spam. Comments Comment by Chris Hallberg [ 30/Sep/15 ] https://github.com/vufind-org/vufind/commit/eb1a8a270bf57f895e21d4c86c508d2c00b3afdc Comment by Demian Katz [ 06/Oct/15 ] Reopened issue -- this isn't quite working right due to limitations in the current ReCaptcha implementation. [VUFIND-1135] Add date range support in Solr Created: 10/Nov/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Updated: 10/Nov/15 Wishlist Priority: Assignee: Votes: Minor Demian Katz 0 Description Solr now supports DateRange fields which can represent a range of dates rather than a single point in time. It would be useful to make these available in the schema in some fashion. See: https://cwiki.apache.org/confluence/display/solr/Working+with+Dates [VUFIND-1137] Allow pattern-based file loading in cover generator Created: 10/Nov/15 Updated: 10/Nov/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Demian Katz 0 Description It is a fairly common use case to retrieve image files from disk using a pattern based on inputs like ID and size. We should create a simple configurable mechanism to support this. [VUFIND-178] Implement "guided" version of Advanced Search. Created: 20/Nov/09 Updated: 02/Dec/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Attachments: Image2.png 23_14.32.55.png Wishlist Priority: Assignee: Votes: Minor Unassigned 3 ScienceDirect - All Sources Search - 2013-09proposal.png Description The current advanced search is aimed at power users, but it would also be nice to have a more Google-like advanced search that's less intimidating for inexperienced users. See the attached proposal.png for Andrew Nagy's original rough proposal for the form used by this feature. Some basic requirements: - The fields displayed in the guided search form should come from searches.ini so that the form can be easily customized when users add their own custom search types. - The guided search is a companion to the existing advanced search, not a replacement. We should design this so that depending on library preferences, they can choose to offer either advanced search option alone or both search options together. A tabbed interface might be one possibility. Comments Comment by Luke O'Sullivan [ 28/Jul/10 ] Would it be possible (desirable) to also have a "basic advanced" search - (obviously with different terminology) administrators could then decide which "Advanced Search" Tab is displayed first, perhaps along the lines of Adv Comment by Luke O'Sullivan [ 28/Jul/10 ] Proposed "Basic Advanced Search" Comment by Demian Katz [ 28/Jul/10 ] The "basic advanced" screen shot you provide actually looks very much like VuFind's original Advanced Search get when you mix operators -- order of precedence is not obvious. Maybe I'm just being dense, though. In any case, I think the original idea of this "guided search" was to have a more Google-style advanced search w implementing multiple interfaces and then letting institutions choose which to enable. Comment by Luke O'Sullivan [ 23/Sep/13 ] Here's an example of the "Guided" search from Science Direct http://www.sciencedirect.com/science?_ob=MiamiSearchURL&_method=requestForm&_temp=all_search.tmpl Comment by Luke O'Sullivan [ 23/Sep/13 ] Science Direct Example [VUFIND-542] Improvements to Author indexing Created: 29/Mar/12 Updated: 11/Jan/16 Status: Project: Component/s: Affects Version/s: Fix Version/s: In Progress VuFind Import Tools, Search None Type: Reporter: Resolution: Labels: Improvement Ronan McHugh (Inactive) Unresolved None Attachments: NLI - Multiple Author Facets.png author-mod 02-10-12.patch author-mod 10-04-12.patch author-mod 10-10-12.patch authorInitials.patch Wishlist Priority: Assignee: Votes: Minor Demian Katz 3 Description Over the past while, users and librarians here at NLI have given us some feedback about problems with author searches in our Vufind instance. Eoghan has asked me to summarise these problems and suggest some solutions in order to kickstart a discussion about how to improve author search in Vufind. Since this would involve relatively core changes to the way that Vufind does search, we'd prefer to have some feedback from other developers before working on our own solution. Summary of issues: 1) At present only Main Authors - Personal Name (MARC 100) are indexed in the author field in Solr. Since MARC records only permit one main author, this has the disadvantage of relegating second authors to the 700 field and thus the author2 field in Solr. The 700 field (Added Entry - Personal Name) is the same used for other contributors such as illustrators, donors etc. This additional relationship information is typically defined in the $e field, although second authors will not receive an entry in the $e field. This is means that second authors will not receive query boosting and will effectively be ranked the same in results as donors, illustrators etc. Similarly, where Main authors are Corporate Names or Meeting Names (MARC 110,111), they will be defined as Author2 in Solr instead of author. This problem also carries over into faceting. Since only main authors are used in faceting, it is not possible to facet by Corporate Name or second author. 2) When searching for authors, users who enter only the initial for the first name, e.g. "Lee, J." for Joseph Lee will not receive any results. This is because Solr doesn't have any tokens for the initials. Suggested Solutions: Add 110, 111 to author in marc.properties. This will have the effect of weighting corporate authors / meetings on the same level as personal names. A beanshell script could be written to distinguish between different types of 700 field entries, e.g.: - When $e of 700 is blank or value denoting authorship, index in Solr author field - When 700$e contains value denoted contribution (e.g. illustrator) index as author 2 - when 700$e contains other values not related to authorship (e.g. donor) don't index as an author but possibly index elsewhere This would require making author multi-valued which presumably would have a knock-on effect for both PHP logic and Smarty templates, and would require tweaking the search weightings. The script could use the LOC relator terms/codes [1] as a basis, but should be able to lookup a user-specified list of terms/codes too. A .bsh script or Solr regex script could be written to do some additional processing of names (e.g. Lee, Joseph -> Lee + J) and index the results in a new Solr field or in author_additional. Suggestions and comments welcome. Comments Comment by Tod Olson [ 29/Mar/12 ] Making author multi-value may have a side-effect on sort by author. Currently the author sort use authrStr, which is a field copy from author. Maybe that will work just fine when sorting records with multiple authors, maybe the author sort will require some modification. Comment by Demian Katz [ 29/Mar/12 ] You're right -- some modification will be needed; I don't think Solr will let you copyField a multi-valued field to a non-multi-valued field. We would have to change some indexing rules (and possibly add a new sort-specific field) to make this work. Comment by Ronan McHugh (Inactive) [ 30/Mar/12 ] Here are some screenshots from a quick test I made with some sample data. The only PHP error I am getting is as follows: Warning: urlencode() expects parameter 1 to be string, array given in C:\vufindtest\web\RecordDrivers\IndexRecord.php on line 710 I guess that it won't be difficult to change the function to accept parameters from an array, but presumably this will have knock on effects elsewhere. Otherwise: As can be seen from the screenshots, the Author field is "Array" in List view. No surprise there. I guess wherever that is defined would need to be modified to check for how many authors there are and return "X and Y" for multiple authors. This will mean that the clickthrough will be for both the authors. Searching for author works fine, even after I deleted the cache. I hadn't expected this to work, but perhaps there is an obvious reason? Likewise with a faceted search with author as a facet. Checking my Solr Schema Browser, it seems that authorStr was populated correctly, so I suppose this is why Author search works but PHP doesn't display Author correctly. Apologies if there's anything obvious I'm missing here, I'm still getting to grips with the system. Comment by Ronan McHugh (Inactive) [ 10/Apr/12 ] Author Modifications patch This patch is a practical implementation of some of the ideas discussed in [VUFIND-542]. Namely it enables multiple first authors by modifying the relevant php and display templates and adding a configurable beanshell script to determine authorship based on user-supplied parameters. 1) Beanshell script The role of this script is to allow a more nuanced determination of authorship and second authorship based on a MARC record. The script references a file /web/conf/authorclassification.ini that classifies the LOC relator codes according to their creative role, firstAuthor, secondAuthor or nonCreative. This allows the system administrator to alter the fields defined as first or second author. The script is called from marc_local.properties. The administrator calls the getAuthors method and passes in the list of fields to be searched (e.g. 100abcd:110abc) for this particular author type (first or second author). Finally they pass in the type of author field currently being populated, either Author, secondAuthor or AuthorStr. The getAuthors method checks all the desired fields of each record to see 1) if they are populated 2) how they are populated. If the fields are 100,110 or 111, they are automatically considered to be first authors, unless the administrator wants 110 or 111 fields to be considered as second authors. If the field is 700 and there is no relator information, the field is considered to be an author.If the field is 700 and there is relator information, the script compares the relator information given to the relator classifications in author-classification.ini. It assigns the field a value based on the result of this comparison. NOTE - if the administrator does not want 700s with a blank relator field to be automatically considered authors, they can simply not pass 700s into the script from marc_local.properties. 2) Schema XML The solr biblio import schema had to be altered to allow this patch to work. Author is now multivalued. AuthorStr is no longer populated by Author, but instead by the first Author value using the author-modifications script. 3) Internal PHP and display templates Several php files and related tpl files had to be modified to allow for multiple author values. In IndexRecord.php the getPrimaryAuthor method was replaced with the getPrimaryAuthors in most cases. The getPrimaryAuthor method has been left in place but it now returns the first element from getPrimaryAuthors. Most calls to the method have been updated to getPrimaryAuthors(), except for the getOpenURL method which still uses getPrimaryAuthor. The relevant tpl files have been updated to display multiple authors (core.tpl,listentry.tpl,result.tpl). One error remains with the similar items module /record/view.tpl whereby a trailing space after each author is displayed. Comment by Ronan McHugh (Inactive) [ 29/Jun/12 ] This is also relevant to a user complaint we have received about title searching. When users make a title search, VuFind returns results based on author name. This is because VuFind includes the value of the 245c field in the index of title_full. To rectify this, Solr should be prevented from indexing the 245c field as part of title_full. In the below example, title searching for murphy report will return records with title report and author murphy. http://catalogue.nli.ie/Search/Results?lookfor=murphy+report&type=Title&submit=FIND Our fix: in marc.properties: author_additional = 505r:245c title_full = 245abfghknps, first Comment by Filipe M S Bento [ 09/Jul/12 ] Dear Ronan (et alii), When I saw this ticket of yours I thought, ok, finally a solution that brings down the barriers of not being possible to have more than one Main Author (main intellectual responsibility), that VuFind SOLR biblio schema forces due to its design was originally thought of to be a pure OPAC 2.0 (just pure speculation of mine, no facts to prove it), having the OPAC as the sole source of records (and this weird thing of MARC not allowing the author field to be repeatable: I mean it forces to have always an author elected as the main and the other(s) relegated to a not so honorable position of co-authors (in UNIMARC, at least, they are near each other: 700, 701 & 702). In real world, especially of scientific publishing most of the times, either if it corresponds to the truth of not, many articles and alike are fruit of joint efforts and co-writing of 2 or more colleagues. I was about to install it because I thought it would resolve this for good, but then I saw this “documentation” from you: 2) Schema XML (…). AuthorStr is no longer populated by Author, but instead by the first Author value using the author-modifications script. Well, and writing to entire team, not directly at Ronan (by all means, I do truly appreciate all your patches and contributions, you’re doing a fantastic job; wish I had a small sample of your programming skills [I have but not so much in PHP > breaking loose of MS dependency) if we take in mind that the Author facet, sorting, list of authors retrieved in autocomplete, but most important, Author facet (yes, I know), all come from AuthorStr value and taking, for instances and randomly :) , the example of Author facet, just one of the authors is displayed (amongst same level ones) so in fact it’s not possible to filter by a certain author, because he/she is not present in the facet, just because he/she comes from a family which name is in the wrong side of the A to Z sort world… Ironies apart, I’m aware that in terms of SOLR that is not so simple, turn it to multivalued, but for all the purposes mentioned above, since each author would have its own AuthorStr for certain record (that has several “main” authors, “contributors” as many OIA-PMH sources and formats call them) they would be displayed as an unique entry, not an array. Take for instance the example of “format” (multiValued="true") – and even “language” is formatted as multivalued. For sure I am missing something here, else you wouldn’t taken that option (better, maintain it); apologies for that, but what ever are the implications I think, if not already thought of in VF2.0, of ways to overcome it. If not, there will be fingers point at VuFind install and say, “hey, why Xyz not being shown in the Author facet?”, if they aren’t doing so already. Thanks, Filipe PS: I’m aware of <copyField source="author2" dest="author2Str"/> and of <copyField source="author_additional" dest="author_additionalStr"/>, but ./sys/Recommend/AuthorFacets.php: 'field' => 'authorStr', 'limit' => 10, 'sort' => 'count' and more like that > none for author2Str or author_additionalStr: [[email protected] web]$ grep -i -R author2Str ./ [[email protected] web]$ grep -i -R author_additionalStr ./ [[email protected] web]$ = aren’t used anywhere at all! Poor guys! (men and women, authors that also worked hard and aren’t given credit for it :| ) Comment by Ronan McHugh (Inactive) [ 10/Jul/12 ] Hi Felipe, that is a good point, I hadn't thought of the implications for narrowing searches on the authors. We haven't committed this patch to our local instance yet since it requires some more testing and feedback from our users, but I will make sure to look at that aspect before long. If I can improve it with your suggestions I will commit back here. At the moment I am living in Vufind 2.0 world, which is a very different place altogether. Comment by Demian Katz [ 10/Jul/12 ] Filipe brings up a good point that it makes sense to have all author names available for faceting. This will help make the author recommendation module better as well as improving the normal side faceting behavior. However, there is one place where we can't escape picking a single author: sorting. You can't sort on a multi-valued field. You have to pick one single value to determine the position of the record in the list. One possible solution would be to maintain the current "main author / secondary authors" system but use copyFields to generate an "allAuthors" multi-valued field. Then you have a single value in the one case where it really matters, but you can grab a pool of values in other situations. The one disadvantage of using copyFields (rather than directly populating) is that you may have less control over the order in which values are loaded into the index... for author lists where people are sometimes sensitive about ranking, that might be a problem... but it's worth experimenting with. Comment by Ronan McHugh (Inactive) [ 02/Oct/12 ] Here is a new version which enables faceting based on all primary authors. This was accomplished through the creation of an allAuthors copyfield which handles faceting while authorStr is retained as single value to allow sorting. Thanks to Demian and Felipe for the feedback and suggestions! Comment by Demian Katz [ 05/Oct/12 ] A few comments/questions related to this latest patch: 1.) Have you tested the implications for citations and exporting? Those areas of the code didn't appear to be touched -- I think they use a combination of getPrimaryAuthor and getSecondaryAuthors; if PrimaryAuthor + SecondaryAuthors != AllAuthors, these changes might cause some names to get dropped in those places. 2.) Did you check that new template strings are present in language files? For example, I think "Primary Authors" is probably new. And on that subject, is it worth counting the list so we can use "Primary Author" for the common single-author case and only pull out "Primary Authors" when necessary? 3.) .ini loading has become more complicated because of a need to account for different layouts in VuFind 1.x and 2.x. It might be worth adding some public methods to the compiled SolrMarc VuFindIndexer class so that Beanshell scripts don't need to reinvent the wheel when loading configurations. I'll see if I can get something like this into the next SolrMarc release. (No action needed on your part right now... just making a note about the issue for future reference). Comment by Ronan McHugh (Inactive) [ 08/Oct/12 ] A new patch uploaded with changes to tpls (Main Author vs Main Authors) en.ini incorporated plus some tidying up around the place. Citation seems to be working fine for me but I couldn't fully test Export since I don't have EndNote and their website is down. Comment by Demian Katz [ 08/Oct/12 ] Thanks, Ronan. If you need to test EndNote without access to the application itself, you can also use the Zotero Firefox plugin -- I believe it still supports the same import format. Comment by Ronan McHugh (Inactive) [ 08/Oct/12 ] Hi Demian, I tried that and it seems like only the first author is getting exported as author. It looks like the export-endnote tpl is a pretty old bit of code. The entire marc record is passed to the tpl which then does all the parsing of the fields. So the author field is coming straight from the 100a. If I were to apply the changes here, I think I would need to replicate the entire logic from my beanshell script in smarty form which doesn't really seem worth the hassle. Do you think it's okay if I just leave it? Comment by Demian Katz [ 08/Oct/12 ] Ronan, you are correct -- I forgot how old that code was in 1.x. It's all been rewritten in 2.0, so we can worry about this when porting the patch forward. Comment by Ronan McHugh (Inactive) [ 08/Oct/12 ] Great, are you thinking of committing this or just leaving it as a patch? Comment by Demian Katz [ 08/Oct/12 ] I think it makes sense to commit this at some point -- it's a more flexible model than the current configuration. I haven't decided whether to make it part of 1.4 or leave it a patch for 1.x and worry about an official implementation for 2.0 only, though. Depends on time and demand. If it would make your life easier to have it in trunk, I'll certainly try to take that into consideration. Comment by Ronan McHugh (Inactive) [ 08/Oct/12 ] Just noticed a little bug in my getPrimaryAuthor method that would cause an error if there were no authors for a record. Comment by Ronan McHugh (Inactive) [ 08/Oct/12 ] Demian, we were just discussing how this would effect the presentation of corporate authors on record pages. The method at present doesn't distinguish between corporate authors and human authors, both types will be shown as either Main Authors or contributors. Therefore, the "Corporate Author" field on the record page is redundant for us. We have decided to comment it out in our trunk to prevent duplication, but were wondering if you had any thoughts about dealing with it in the trunk? If users still want to distinguish between corporate authors and human authors, they can do so by editing the fields supplied to the bsh in marc.properties. But if users don't do this, they will be presented with duplicate information based on our modifications to the import rules. Comment by Demian Katz [ 08/Oct/12 ] If I had to take a guess, I would speculate that the majority of users aren't going to care about corporate authorship getting its own distinct label in the record view... but there might be a vocal minority that needs this. It might be worth polling the mailing lists about this to see how people feel (getting the cataloger's perspective would be useful), but I would be inclined to let the corporate author field display go away in the default trunk setup, as long as we provide instructions on how to get it back as a custom option in case somebody really needs it. Comment by Ronan McHugh (Inactive) [ 11/Oct/12 ] Here is a bsh script that will process the supplied author fields and return initials in several forms. For example, Yeats, William Butler, will be indexed as "w b y wb wby", Duncan-Smith, Iain, will be indexed as "i d s id ids". International Labour Organisation will be indexed as "i l o ilo". The aim of this is to ensure that users get results when they search for initials without spaces, e.g. "wb yeats" or "ilo". Comment by Demian Katz [ 18/Feb/15 ] Another issue to consider as part of comprehensive author field redesign: Right now, author_additional is used only for table of contents authors; these names are searched but never displayed from Solr (since TOC display is handled by direct MARC processing). This seems inelegant; should we rename author_additional to author-toc, change the way the field is used, or do nothing? Comment by Demian Katz [ 27/Apr/15 ] A VuFind 2 port of this code is in progress in this pull request: https://github.com/vufind-org/vufind/pull/354 I've significantly reworked the BeanShell code from the original patch to make it simpler and more generic. Functions have been renamed, and the basic idea here is that, rather than caring about semantic meanings of particular MARC tags, and instead of having built-in concepts of primary/secondary authors, the revised code simply filters the author results using a couple of parameters: the tags which may be included if no relator is present, and a whitelist of relators to allow when a relator value is found. I'm sure there's still room to further improve this code, but I feel this is a step in the right direction. I've also made some schema adjustments which are similar (but not identical) to the ones proposed in the older patch. The net result is just about the same, but I've also taken the liberty of eliminating some unused author fields to simplify matters. There's a lot of work still to be done on the PHP side -- watch the PR for progress there. I also haven't done anything with the initials patch yet. That feels like a separate (and smaller) issue, so I think I'll work through the primary patch before I worry too much about that one. Comment by Demian Katz [ 11/Jan/16 ] Just an update to note that all functionality from this ticket (including the author initials) is now implemented in the pull request. We still need to do some review before merging to master (not to mention minting a new SolrMarc release), but this is great progress! [VUFIND-1140] Cover image metadata API Created: 08/Dec/15 Updated: 08/Dec/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Issue Links: incorporate incorporates VUFIND-986 Add a "hasImage" method to the Image ... Open Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description The current system for displaying cover images relies on embedding image tags that then proxy images from third-party APIs, cover generation tools, etc. One disadvantage to this system is that because the cover is being displayed as an image, it cannot communicate any additional information to the calling code. Thus, we can't easiily hide covers for which no image is available. We can't easily embed links to comply with terms of service for booksellers that require links to accompany their images. It would be helpful if we could implement an AJAX API to retrieve additional information about images that have just been displayed. Ideally, this API should share a cache with the image loader itself so that the information can be retrieved without duplicating API calls. Comments Comment by Demian Katz [ 08/Dec/15 ] Some early discussion of this feature can be found on this pull request: https://github.com/vufind-org/vufind/pull/507 Comment by Demian Katz [ 08/Dec/15 ] There was some discussion on the December 8, 2015 developers call about the idea of passing metadata back in the HTTP headers of the images being loaded. Unfortunately, this is not feasible since the browser offers no mechanism for accessing these headers. See: http://stackoverflow.com/questions/17162994/javascript-image-access-headers-in-response [VUFIND-453] Problems with processing of DismaxParams section of searchspecs.yaml Created: 20/Sep/11 Updated: 15/Jan/16 Status: Project: Component/s: Affects Version/s: Fix Version/s: In Progress VuFind Search 1.2 Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Minor Demian Katz 0 fix.patch Description Two bugs were found in the processing of the DismaxParams section of searchspecs.yaml: 1.) Double quotes in parameter values (i.e. bq of format:"Conference Proceedings"^10) could cause fatal errors in advanced searches. 2.) In some circumstances, multiple instances of the same parameter (i.e. multiple boost queries) were ignored. The attached patch fully fixes issue #1 and partially fixes issue #2. Issue #2 still affects advanced searches -- we need to figure out a way to repeat parameters using LocalParams syntax (see http://wiki.apache.org/solr/LocalParams ). Comments Comment by Demian Katz [ 01/Nov/11 ] Thread from solr-user mailing list with more details: http://lucene.472066.n3.nabble.com/Questions-about-LocalParams-syntax-td3352056.html Related ticket in Solr's JIRA: https://issues.apache.org/jira/browse/SOLR-2798 Comment by Demian Katz [ 15/Nov/11 ] The attached patch was committed as r4267 (included in VuFind 1.3); I'm moving the fix version for this ticket to Wishlist until SOLR-2798 is resolved -- I think it's better to wait for this to be fixed on the Solr side than to come up with a hacky solution on the VuFind side. Very few users should be affected in the meantime. Comment by Demian Katz [ 15/Jan/16 ] The SOLR-2798 ticket has finally been resolved, and the fix will be incorporated into Solr release 5.5. I can confirm that the latest code solves the problem described on this ticket -- once we upgrade Solr to a new enough version, we can close this ticket. [VUFIND-1145] Investigate simplification of request link logic Created: 11/Feb/16 Updated: 11/Feb/16 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Presently, the hold/recall functionality (and the ILL / storage retrieval request features which are heavily derived from it) has very complex logic related to handling links, with different layers of detail and processing spread between ILS drivers, the \VuFind\ILS\Logic classes and templates. It seems likely that some of this behavior (and the related data properties) may be redundant or unnecessary. We should do a thorough review of the code with the goal of reducing complexity/redundancy and improving clarity. [VUFIND-974] Non-Sorting Control Characters Created: 11/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record, Search 2.2.1 Type: Reporter: Resolution: Labels: Improvement Frédéric Demians Unresolved None Updated: 25/Apr/14 Wishlist Priority: Assignee: Votes: Minor Unassigned 0 Description Non-sorting characters are available in biblio records: http://www.loc.gov/marc/nonsorting.html This is new in MARC21 world, but it is used since ages in UNIMARC biblio records. For example, French national library catalog (BNF) and the Collective catalogue for Higher Educational and Research libraries (SUDOC) use them. Those characters are generally referred as NBS/NSE characters: non-sorting begin and non-sorting end characters. For the time beeing, VuFind indexing mechanism honors the non-filing indicator but doesn't take into account NSB/NSE characters. Title sorting is done in VF using a specific index named title_sort which is populated by a custom script: getSortableTitle. This function is delegated to SolrMarc getSortableTitle method: https://code.google.com/p/solrmarc/source/browse/trunk/lib/solrmarc/src/org/solrmarc/index/SolrIndexer.java#1 So to implement non-sorting characters support into VF, I can see two solution: 1. Modify Solrmarc 2. Overload for VF Solrmarc getSortableTitle Comments Comment by Demian Katz [ 11/Apr/14 ] I think it makes the most sense to modify SolrMarc in this case -- this is a change of general utility rather than something VuFind specific. If you are able to create a patch, I can help get it included in the next SolrMarc release. It would also be helpful if you could post a sample record here demonstrating the control characters. A general thought: it would be useful to give SolrMarc a generic "getSortableFieldValue" method which strips out the non-filing characters, and then make getSortableTitle a wrapper around this. Comment by Tod Olson [ 11/Apr/14 ] Note also that the NSB/NSE characters have different code points in MARC ANSEL vs UCS. So translation must be tested, as well as different the different encodings. Comment by Frédéric Demians [ 12/Apr/14 ] I don't have original MARC21 bibliographic records. I get mine by converting them from UNIMARC records. So the question may be: is there any MARC21 biblio records in the wild containing NSB/NSE characters? I'm not sure that, even if there is a LOC proposal, it has been used by anyone. For the time being, I decided to improve my conversion procedure. NSB/NSE characters are used to calculate the Number of nonfiling characters to put in 245 second indicator. It solves my sorting by title issue in VF. Thanks for the discussion. If someone can point to a MARC21 catalog using NSB/NSE characters, I may try to implement a solution directly in SolrMarc. [VUFIND-506] Add Goodreads review support Created: 10/Feb/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Attachments: Updated: 04/Jul/12 Wishlist Priority: Assignee: Votes: Trivial Unassigned 1 Imagem 071.png Description Goodreads has an API for obtaining reviews: http://www.goodreads.com/api We should look into integrating this with VuFind. It appears to be iframe-based, which is not ideal, but we can probably make it work. Comments Comment by Filipe M S Bento [ 13/Feb/12 ] Got to take a better look, but didn't find a method to retrieve books' summary; right now I am using the trick I've explained in a former tickect to use the same script of google preview to get this: http://books.google.pt/books?id=MgEJgwgyFBkC&hl=ptPT&source=gbs_ViewAPI&redir_esc=y that comparing to goodreads's one... well, is just the same: http://www.goodreads.com/book/show/3535679-carbon-nanotubes Was planning of finding a way to open google one's in a jquery popup... if this one (googdreads) gives it, even in iframe, better! if not, anyone has an idea how to open an external page in a "blind" jquery popup window (why jquery you may ask > not to be blocked by popup blockers.... yes, I know it requires javascript to be active, but hei, who does these days disable javascript or browser that does not support JS?) Googled it a lot and no way so far... :| Comment by Demian Katz [ 14/Feb/12 ] I'm not aware of a book summary API -- I was just thinking of adding Goodreads as an option in the "reviews" setting of the [Content] section of config.ini. Comment by Filipe M S Bento [ 15/Feb/12 ] Demian, hi, again! Me too, I don't believe they offer such a "free lunch" (book summary API). There is although a variation of the preview script that let's you point to the whole page (summary included), so no need for the "hack" I've done and mentioned above. You can see it working where, link at the end of the metadadata section of the record ("Google Books") that was proviced by Ex Libris. The preview one was included by us and it is the same as you've here in VuFind. Please note that some do not offer a preview, but still are found in Google Books database (so the link shows up in the record, e.g., http://opac.ua.pt/F/?func=findb&find_code=SYS&REQUEST=000217905 ) and do have summary and preciouse other info (in this case: http://books.google.pt/books?id=MgEJgwgyFBkC&hl=ptBR&source=gbs_ViewAPI&redir_esc=y ). All the best, Filipe PS: and again: anyone knwo a way to poup the content of this external page in a jquery popup window? Thanks in advance! Comment by Demian Katz [ 15/Feb/12 ] Does Jonathan Rochkind's ajaxyDialog help with your popup problem? http://bibwild.wordpress.com/2011/01/04/ajaxydialog-a-jquery-ui-widget-to-make-links-orforms-open-destination-in-a-jquery-ui-dialog/ Comment by Filipe M S Bento [ 15/Feb/12 ] Demian, many thanks, going to try it, although this part TODO: Actual live example/demo is of most importance, because I didn't find any placeholder for the external links... :| Something more concrete like this would be nice (just found it now, so going to give it a go, later on (tomorow): http://forum.jquery.com/topic/how-to-load-external-page-in-dialog-box Comment by Filipe M S Bento [ 04/Jul/12 ] <Imagem 071.png> In the absence of better solutions (summary via API), using a blind iframe (no scrollbars, no frames... as natural to the page as possible [the looks of an "inside job"])… :| Just need a way to place a loading animated gif as background when the goodreads (external) page loads within the iframe... now it's bkank all over... Filipe [VUFIND-468] Flickr API support for record pages Created: 27/Oct/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: New Feature Lutz Biedinger (Inactive) Unresolved feature Attachments: Updated: 09/May/13 Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 flickr1.patch Description This patch allows for any marc record with a flickr url (in the patch this is stored in the marc field 530 |u and is something like http://www.flickr.com/photos/[AccountID]/[photoID]/) to retrieve information from Flickr using the flickr API. The flickr response is xml and parsed using xslt and then displayed in a new flickr tab. flickr1.patch only supports general photo Info (including tags) and Comments, however other methods from the api are available but no proper parsing for these is implemented in flickr.xsl. This patch may be useful for anyone trying to use flicker information on record pages, but most likely will need to be customized/expanded. In order to use this patch you will need to obtain a flickr api key from: http://www.flickr.com/services/api/keys/ this key needs to be placed in the [flickr] section in config.ini in order to enable the flickr tab. Comments Comment by Lutz Biedinger (Inactive) [ 27/Oct/11 ] flickr1.patch only supports the default theme. Comment by Eoghan Ó Carragáin [ 09/Feb/12 ] A live example of this patch: http://catalogue.nli.ie/Record/vtls000191622/Flickr#tabnav Comment by Ronan McHugh (Inactive) [ 05/Jun/12 ] Hi Demian, just wondering whether there is any interest in bringing this into the trunk or 2.0? Comment by Demian Katz [ 05/Jun/12 ] It might be interesting to see if it can be implemented more easily in 2.0, since Zend Framework includes libraries for working with flickr (Zend_Service_Flickr -- ZF1: http://framework.zend.com/manual/en/zend.service.flickr.html , ZF2 proposal: http://framework.zend.com/wiki/display/ZFPROP/Zend_Service_Flickr+2.0++Mickael+Perraud ). The VuFind 2.0 design makes adding new tabs a little less complex (the record driver returns an associative array of tabs, and associated templates are loaded using a naming convention), but we may need to add a new feature to support the fancy "flickr logo as tab text" feature of your patch. I haven't spent much time looking closely at this patch because it seems very specialized for your particular use case... but if others are interested, I'll be happy to work with you to generalize it (though I probably won't have time until VuFind 2 development is a little farther along). We can discuss this on the next dev call to get a feel for other people's needs. Comment by Ronan McHugh (Inactive) [ 05/Jun/12 ] Sounds like a good idea. I will have to port it over to VF2 at some stage anyway, so it would make sense to use the Zend libraries to make a more general solution. [VUFIND-376] Add Wikipedia Citation option to Cite This Created: 25/Jan/11 Updated: 25/Jan/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record Wishlist Type: Reporter: Resolution: Labels: Environment: New Feature Eoghan Ó Carragáin Unresolved None all Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description The Open Library provide "Wikipedia Citation" as one of their "Download catalog record:" options in the bottom right corner of their record pages (e.g. http://openlibrary.org/works/OL15396198W/Ireland). This provides the user with formatted citation which can be copied directly to wikipedia (see http://en.wikipedia.org/wiki/Template:Cite#Citing_books) [VUFIND-279] Additions to Profile Created: 14/Jun/10 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Issue Links: incorporate incorporates Updated: 14/Nov/13 Wishlist is incorporated by Priority: Assignee: Votes: VUFIND272 VUFIND637 Trivial Chris Hallberg 1 Add "change password" functionality w... User preferences' / profile page Resolved Open Description To facilitate holds, I have added a "Preferred Library" to the profile page. This is basically a drop down menu which allows users to choose a default library for hold and requests should be sent to. This could be expanded to include "Preferred Theme" and "Preferred Language" so that user's don't have to change these options. Such changes would require additional fields in the mysql user table. Comments Comment by Demian Katz [ 23/May/11 ] The "preferred library" feature was added in r3932, but the theme and language settings remain on the to-do list. Comment by Phil Fenstermacher [ 02/Jan/12 ] A field for a phone number would be helpful too. We've had a lot of requests from users for us to save/pre-populate the phone field when sending SMS messages. Maybe other info (like email address) should be saved as well for similar uses? [VUFIND-261] Add configurable option to use RefWorks OpenURL export method. Created: 26/Apr/10 Updated: 11/Jan/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved RefWorks Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description RefWorks supports an OpenURL export method: http://www.refworks.com/directexport.htm#OpenURLSpecs This is less detailed than the current callback-oriented approach, but it may be useful for some institutions where firewall configuration prevents the callback method from working. We should consider adding a config.ini option to optionally use the OpenURL method in place of the callback method for RefWorks. [VUFIND-771] Allow users to force all links within a hierarchy tree to link to the Collection Module Created: 27/Mar/13 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Hierarchy 2.0beta Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 collection.patch Description Some users may wish all the links generated by a hierarchy tree to take users to the collections module without reference to location in which the tree was generated or whether or not the record was a hierarchy itself. The attached patch creates a hierarchy_link_type field in the solr schema which, if population with "collection" will enforce the behaviour described above. [VUFIND-750] Calendar export for checkout items Created: 26/Feb/13 Updated: 26/Aug/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch 1.4 Type: Reporter: Resolution: Labels: Environment: Improvement Christian Dabrowski Unresolved feature SLES 11 Attachments: Calendar.patch VUFIND-750_01.png VUFIND750_02.png VUFIND-750_03.png VUFIND-750_04.png addthisevent.css atemay.js checkedout_patched_addthisevent_by_ Christian_Dabrowski.tpl Wishlist Priority: Assignee: Votes: Trivial Unassigned 2 Description This patch includes the changes in the checkedout.tpl to make the calender plugin work. It is based on the addthis.com plugin. When you apply the changes to the checkedout.tpl add the attached files into: web\interface\themes\blueprint\js\atemay.js web\interface\themes\blueprint\css\blueprint\addthisevent.css Comments Comment by Filipe M S Bento [ 04/Mar/13 ] Hi Christian! Thanks for sharing this: it’s really great (did not know AddThisEvent, "Add to Calendar" Widget). I’ve tried it immediately after you’ve shared it and had this message in standby mode since then. Please do apologize for being submitting it only now. The patch was generated against a somewhat locally modified by you version of checkedout.tpl, right? I’ve also have mine a little bit modified so, when it failed against it, I’ve tried with current trunks one (as of 2013-02-26 8pm) and the some result. So I’ve “manually patched” it. The result is checkedout_ patched_addthisevent_by_ Christian_Dabrowski.tpl that I’m taking the liberty of attaching. Btw, in my install I’ve moved “blueprint/addthisevent.css” to “addthisevent.css” (web/interface/themes/blueprint/css/), because Blueprint is a CSS framework in it self (if not in mistake is this one: http://www.blueprintcss.org/). Also, for the ones who adopt this great extra, need to make some changes in the checkedout.tpl file, namely palce your own data in: <span class="_location">FH-SWF {translate text='Library'}</span> Attached are some partial screen shots of my install with some tweaks in the CSS. Thanks / all the best, Filipe PS: we do have automatic e-mails alerts that are sent at 1am of the due day, but with this, not only patrons can specify it as a task or alerts with a greater time-span, but also, and if using google calendar, they can also add a request for a SMS reminder (free; we have also this possibility but someone would have to pay for each SMS sent). Comment by Filipe M S Bento [ 04/Mar/13 ] checkedout.tpl patched againts current trunk's one (as of 2013-02-26 8pm) Comment by Filipe M S Bento [ 04/Mar/13 ] Partial screenshots. Comment by Christian Dabrowski [ 05/Mar/13 ] Filipe, thank you for correcting this - yes, you are right our checkedout.tpl was slightly different. To avoid this and get a clean version I'll do the patches in the vendor branch next time. By default we add to the calender event: a prefix saying "due date": author, title. In the event description you'll find the same including the location. The due date is of course created automatically. We had to modify the orignal code (thanks to Daniel, our programming-wise student!), so while reusing this feature you'll probably need to touch the code too. I have checked the calender events with google, yahoo, outlook and thunderbirs lightning (sunbird plugin) - all worked as it should. The only unsatisfying thing was: using thunderbird with lightning you have to import the calender event. In the other cases you directly get the event popup. The mail reminder we also use via our ILS, but it sometimes happens that the mail gets into spam or simply is not delivered because of full account etc. Some people say it comes too early, some say it comes too late.. a never ending story. This here makes the due dates more personal. I hope that people have their due dates more present when adding them to their calender. Comment by Tom Misilo [ 06/Aug/13 ] Would it be possible to maybe see this added to the Plan for 2.X? Comment by Christian Dabrowski [ 26/Aug/13 ] Hi Tom, I think this should be easy adopted to V2. But as I don't have a V2.X installation here, I just can't do it. But all necessary files are posted. Christian [VUFIND-730] external recommender: Bibtip Created: 17/Dec/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record, Search 1.3 Type: Reporter: Resolution: Labels: Environment: Improvement Christian Dabrowski Unresolved recommendation Vufind 1.3, SLES 11 Attachments: Updated: 09/May/13 Wishlist Priority: Assignee: Votes: Trivial Unassigned 1 bibtip.patch Description This patch integrates the external recommender "bibtip" (www.bibtip.com). Before you apply the patch, create an empty bibtip.tpl file in blueprint\RecordDrivers\Index. For further questions on the product bibtip feel free to contact Mr. Spiering from bibtip.com (Email on the website). Comments Comment by Christian Dabrowski [ 17/Dec/12 ] Here is a link to a record page with bibtip: http://194.94.3.187/vufind/Record/000813566 [VUFIND-684] Show the Brief Description of a record optionally Created: 02/Oct/12 Updated: 09/May/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record 1.1 Type: Reporter: Resolution: Labels: New Feature Priority: Sandino Vargas Assignee: Unresolved Votes: config, description, record, summary Attachments: Wishlist Trivial Unassigned 0 optional_summary_display.patch Description Implementation of the "Brief Description" as an option on config.ini. This is the part in the record view where we get a brief description of the record. Sometimes is not that "brief" and it take too much display space (making it difficult for small screen computer to display the important information first). So we decided to make this an option that can be turn off/on. Comments Comment by Demian Katz [ 03/Oct/12 ] Thanks for sharing this. Did you consider addressing this simply by creating a custom theme? It would be a somewhat lighter-weight solution to adjust a template rather than adding a new configuration setting, and this approach would also allow you to select different behavior in different themes (i.e. mobile vs. standard) if you so desired. However, I do realize that the config-based approach can have some advantages of its own (i.e. it's easier to change later without thinking too hard about template structure). I would be interested to hear if others would like to see this feature added to the trunk -- right now I'm inclined to leave it in JIRA as an optional patch rather than making the default configuration file larger, but if there is enough demand, we can certainly make it a standard feature. If we do go that route, though, it might be worth thinking about whether there's a better way to expand this -- i.e. to allow multiple fields to be easily disabled in various contexts. [VUFIND-640] Support highlighting in WorldCat module. Created: 27/Aug/12 Updated: 26/Sep/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind WorldCat 2.0beta Type: Reporter: Resolution: Labels: New Feature Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description Although VuFind 1.x supports crude keyword highlighting in its WorldCat search module, this functionality has not been ported forward to 2.x. If we want the feature back, we should make it configurable and decide on a way to support it in the new, less redundant 2.x architecture. Comments Comment by Demian Katz [ 27/Aug/12 ] If we implement this, we should remember to update the wiki: http://vufind.org/wiki/search_result_highlighting [VUFIND-529] "Retain my current filters" requires Javascript Created: 14/Mar/12 Updated: 14/Mar/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description The "Retain my current filters" checkbox in the search screen currently only operates when Javascript is enabled. We could implement a non-JS solution, but it adds complexity -- we would have to add an additional hidden input (possibly within a noscript tag) and add a name attribute to the checkbox. Then, if the hidden input's value is found in the request, VuFind could remove filters if the named checkbox was not checked. Note that this would also have the side effect of adding a new parameter to every search URL unless we add even more complexity to generate different checkboxes depending on Javascript status. If you think this is worth the trouble, please vote/comment here. Otherwise, this will remain a very low-priority enhancement, since the cost may not justify the benefit. [VUFIND-810] More Flexible LayoutClass Helper Created: 10/May/13 Updated: 26/Sep/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface Wishlist Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description At present the LayoutClass helper is simply either bar on left or bar on right. A more flexible helper would allow users to override default behaviour per page if required and change the size of the span-* classes if desired. /** * Helper class for managing blueprint theme's high-level (body vs. sidebar) page * layout. * * @category VuFind2 * @package View_Helpers * @author Demian Katz <[email protected]> * @license http://opensource.org/licenses/gpl-2.0.php GNU General Public License * @link http://vufind.org/wiki/vufind2:developer_manual Wiki */ class LayoutClass extends \Zend\View\Helper\AbstractHelper { /** * Does the sidebar go on the left? * * @var bool */ protected $left; /** * Constructor * * @param bool $left Does the sidebar go on the left? */ public function __construct($left = false) { $this->left = $left; } /** * Helper to allow easily configurable page layout -- given a broad class * name, return appropriate CSS classes to lay out the page according to * the current configuration file settings. * * @param string $class Type of class to return ('mainbody' or 'sidebar') * @param boolean $override Whether or not to reverse the default behaviour * * @return string CSS classes to apply */ public function __invoke($class, $override = false) { $left = (true === $override) ? !$this->left : $this->left; switch ($class) { case 'mainbody': return $left ? '$this->mainSpan $this->sidebarPush last' : '$this->mainSpan'; case 'sidebar': return $left ? '$this->sidebarSpan $this->mainPush sidebarOnLeft' : '$this->sidebarSpan last'; default: return ''; } } } Comments Comment by Demian Katz [ 10/May/13 ] If I understand correctly, the code you have attached here simply allows the option to reverse the default sidebar behavior. How would you plan on implementing custom span widths? While more flexibility would be useful, I also want to be careful to keep this fairly generic -- we may eventually (perhaps sooner rather than later) move away from Blueprint given the current trend toward responsive design. I'm hoping that, should that happen, we won't have too many Blueprint-specific details in the code to have to worry about. Just something to keep in mind while working on this! Comment by Demian Katz [ 26/Sep/13 ] Another option might be to make the second parameter accept four possible constants: DEFAULT -- use the standard configured sidebar position REVERSE_DEFAULT -- use the opposite of the standard configured sidebar position FORCE_LEFT -- force sidebar to left FORCE_RIGHT -- force sidebar to right I think that covers all the positioning options, and this would be valid for both the Blueprint and Bootstrap themes. Because of the responsive nature of Bootstrap, I wouldn't want to add a static width parameter at this point, but perhaps we could define some constants to describe a few layouts to choose from, like FIFTY_FIFTY, LARGE_SIDEBAR, THIN_SIDEBAR, etc. I don't want to implement any of this without an actual use case, but let me know if you still think this is worth pursuing. [VUFIND-783] My Research Dashboard Created: 15/Apr/13 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind MyResearch None Type: Reporter: Resolution: Labels: New Feature Luke O'Sullivan Unresolved None Attachments: Updated: 26/Sep/13 Wishlist Priority: Assignee: Votes: Dashboard_20130415-121012.png Trivial Unassigned 1 dashboard.patch Description A My Research Dashboard is designed to give users a quick overview of their account [VUFIND-781] Add Option to only retrieve full text urls from Marc records Created: 10/Apr/13 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Record None Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description Some users may not wish to display non-full text urls (e.g. Table of Contents) in the search results / record pages. Adding a fulltext check would allow users to choose if they wanted full text only urls. E.g. SolrMarc.php /** * Return an array of associative URL arrays with one or more of the following * keys: * * <li> * <ul>desc: URL description text to display (optional)</ul> * <ul>url: fully-formed URL (required if 'route' is absent)</ul> * <ul>route: VuFind route to build URL with (required if 'url' is absent)</ul> * <ul>routeParams: Parameters for route (optional)</ul> * <ul>queryString: Query params to append after building route (optional)</ul> * </li> * * @return array */ public function getURLs($fullText = false) { $retVal = array(); $proceed = true; // Which fields/subfields should we check for URLs? $fieldsToCheck = array( '856' => array('y', 'z'), // Standard URL '555' => array('a') // Cumulative index/finding aids ); foreach ($fieldsToCheck as $field => $subfields) { $urls = $this->marcRecord->getFields($field); if ($urls) { foreach ($urls as $url) { // Is there an address in the current field? $address = $url->getSubfield('u'); // Do we need to check if this is a full text url if (true === $fullText) { // Get Indicators $ind1 = $url->getIndicator(1); $ind2 = $url->getIndicator(2); $proceed = ($ind1 == "4" && ($ind2 == "0" || $ind2 == " ")) ? true : false; } if ($address && $proceed) { $address = $address->getData(); // Is there a description? If not, just use the URL itself. foreach ($subfields as $current) { $desc = $url->getSubfield($current); if ($desc) { break; } } if ($desc) { $desc = $desc->getData(); } else { $desc = $address; } $retVal[] = array('url' => $address, 'desc' => $desc); } } } } return $retVal; } This would also require a change in the VuFind/Helper/Root/Record class Comments Comment by Luke O'Sullivan [ 10/Apr/13 ] A further development might be to have the getURLs function accept a string : "fulltext" to retrieve only fulltext urls, "nonfulltext" to retrieve only non fulltext urls, "default" to retrieve both Comment by Luke O'Sullivan [ 10/Apr/13 ] /** * Return an array of associative URL arrays with one or more of the following * keys: * * <li> * <ul>desc: URL description text to display (optional)</ul> * <ul>url: fully-formed URL (required if 'route' is absent)</ul> * <ul>route: VuFind route to build URL with (required if 'url' is absent)</ul> * <ul>routeParams: Parameters for route (optional)</ul> * <ul>queryString: Query params to append after building route (optional)</ul> * </li> * * @return array */ public function getURLs($mode = "default") { $retVal = array(); $proceed = true; // Which fields/subfields should we check for URLs? $fieldsToCheck = array( '856' => array('y', 'z'), // Standard URL '555' => array('a') // Cumulative index/finding aids ); foreach ($fieldsToCheck as $field => $subfields) { $urls = $this->marcRecord->getFields($field); if ($urls) { foreach ($urls as $url) { // Is there an address in the current field? $address = $url->getSubfield('u'); // Get Indicators $ind1 = $url->getIndicator(1); $ind2 = $url->getIndicator(2); $isFullText = ($ind1 == "4" && ($ind2 == "0" || $ind2 == " ")) ? true : false; if ("fulltext" === $mode) { $proceed = $isFullText; } elseif ("standard" === $mode) { $proceed = !$isFullText; } if ($address && $proceed) { $address = $address->getData(); // Is there a description? If not, just use the URL itself. foreach ($subfields as $current) { $desc = $url->getSubfield($current); if ($desc) { break; } } if ($desc) { $desc = $desc->getData(); } else { $desc = $address; } $retVal[] = array('url' => $address, 'desc' => $desc); } } } } return $retVal; } Comment by Demian Katz [ 25/Apr/14 ] I seem to have lost track of this ticket. Is there still a need for this on your end? If so I'll take a closer look and give it more thought. If I'm understanding correctly at a glance, is the idea here that in some cases, indicators will tell us something about the content of the 856 field? If so, I imagine in many cases they're not set correctly (based on past experience of MARC consistency), but still, might be useful -- if nothing else I wonder if we could use this to generate smarter labels for links that don't have a description provided. [VUFIND-778] Add a Get Orders Method to the ILS Driver Created: 05/Apr/13 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver None Type: Reporter: Resolution: Labels: New Feature Luke O'Sullivan Unresolved None Attachments: Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 VoyagerVillanova.php Description Our members of staff like to use our catalogue to see if any items for a particular record are on order. Items on order could be added to the existing Holdings Tab or could be assigned to a new "Orders" Tab Comments Comment by Demian Katz [ 10/Apr/13 ] I'm attaching a copy of Villanova's custom Voyager driver (currently built against VuFind 1.4); this adds several features, some very Villanova-specific, but there are some bits of code related to orders (see the _resolveEmptyStatus() method in particular). [VUFIND-772] XML / Hierarchy File Generator Created: 27/Mar/13 Updated: 25/Apr/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Hierarchy None Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Attachments: Wishlist generate-xml.php Priority: Assignee: Votes: xml.config.php Trivial Unassigned 2 xml.properties xml.xsl Description Sometimes it may be necessary to generate Solr records as holding records. This may be especially true when users are trying to create a hierarchical structure from records which do not have one to begin with. I for example create the first three levels of our tree structure and then index our records via OAI which then "hang of" third level elements. generate-xml.php takes an array from xml.config.php and creates an xml document which can be batch processed by VuFind. It is recursive so it will look for a key with the value of "children" and create XML files for anything it finds there. It will also build hierarchical tree components if the buildHierarchy option is set to true. Files are stored accord to the protected $basePath = ""; value which should be vufind/local/harvest/xxx if you want to use vufind's batch processes. Also attached are xml.properties and xml.xsl which perform the conversion to solr document as part of vufind's batch process. E.g. sh batch-import-xsl.sh ./hierarchy ../import/xml.properties. If required, generate-xml.php could easily be added to VuFind2 and act in a similar way to the OAI Class. Comments Comment by David Maus [ 02/Apr/13 ] xml.xsl: <xsl:template match="@*|node()"> <xsl:for-each select="@*|node()"> <field> <xsl:attribute name="name"><xsl:value-of select="local-name()" /></xsl:attribute> <xsl:value-of select="." /> </field> </xsl:for-each> </xsl:template> Couldn't this be rewritten as: <xsl:template match="*"> <xsl:for-each select="*"> <field> <xsl:attribute name="name"><xsl:value-of select="local-name()" /></xsl:attribute> <xsl:value-of select="." /> </field> </xsl:for-each> </xsl:template> The expression "@*|node()" matches all attribute nodes ("@*"), and all element and text nodes ("node()"); the expression "*" matches all element nodes. Or is creating <field/> elements for attributes intentional? Comment by Luke O'Sullivan [ 02/Apr/13 ] Hi David, Thanks for the comments - you're completely right of course :) Cheers, Luke [VUFIND-218] Checkbox facets broken with Javascript disabled Created: 26/Jan/10 Updated: 20/Jun/11 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Search, Summon None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description Right now, checkbox facets don't work without Javascript. We should try to add appropriate <noscript> behavior. [VUFIND-170] Wikipedia: entity encoding problems Created: 11/Nov/09 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Author None Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Updated: 19/Nov/09 Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description The text of Wikipedia entries displayed by the Author/Home module sometimes contains unescaped reserved HTML characters (i.e. " instead of &quot;). In practice, browsers handle this fairly well, but it would be nice to produce completely valid HTML output -- we should investigate a way of correcting these problem characters without breaking other Wikipedia parsing functionality. [VUFIND-152] Better language support in Admin module Created: 28/Oct/09 Updated: 19/Nov/09 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind Admin, User Interface None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description The current Admin module is hard-coded in English. We may want to consider making this translation-capable. Note that comments in config files are an important part of the documentation, so translations of these might also be valuable (though maintaining multiple language copies of standard config files could become a complicated problem). [VUFIND-997] Better error reporting in feedback module Created: 27/Jun/14 Updated: 27/Jun/14 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface 2.2.1 Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description Right now, issues like an invalid email address input cause the feedback submission window to pop up a generic error alert. It would be better if we could offer more helpful, descriptive and attractively presented responses. [VUFIND-282] Print Button Created: 17/Jun/10 Updated: 17/Jun/10 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface None Type: Reporter: Resolution: Labels: Improvement Luke O'Sullivan Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 2 Description The addition of a Print button to the results and record pages with the following options 1) Print Selected 2) Print Current Page 3) Print All [VUFIND-1146] Text centering in cover generator is slightly inaccurate Created: 11/Feb/16 Updated: 11/Feb/16 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind User Interface None Type: Reporter: Resolution: Labels: Bug Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description When using the dynamic cover generator to create cover images, the text displayed on the images is often a few pixels off from being perfectly centered. This is due to a current limitation of PHP: the imagettfbbox() function used to calculate position measures the width of a block of text in pixels. The imagettftext() function used to draw a block of text requests the position of the baseline of the text, but some fonts have characters that project beyond the baseline. There is currently no built-in function (at least, none that works without installing an extra extension) to measure these differences. Thus, when baseline and pixel width are slightly different, the centering is slightly skewed (usually to the left). Possible long-term solutions: - Wait for PHP to add more functionality - Add a new dependency (on an extension or third-party font library) Current available workaround: - Use a monospaced font for generating covers if this bothers you. [VUFIND-1153] Improvements to VoyagerRestful patron block behavior Created: 03/Mar/16 Updated: 03/Mar/16 Status: Project: Component/s: Affects Version/s: Fix Version/s: Open VuFind ILS Driver None Type: Reporter: Resolution: Labels: Improvement Demian Katz Unresolved None Wishlist Priority: Assignee: Votes: Trivial Unassigned 0 Description The National Library of Finland has made a couple of improvements to the VoyagerRestful driver relating to pat 1. The code filters for local blocks, preventing a block from another library stopping holds in a "universal borrow environment. 2. Translation has been implemented for certain block codes. These changes can be seen in their GitHub: https://github.com/NatLibFi/NDLVuFind2/blob/f76acf0f8713f978d8c9193db7ce5407abc6bad3/module/Finna/src/Finna/ILS/Driver/VoyagerRestf https://github.com/NatLibFi/NDL-VuFind2/blob/f76acf0f8713f978d8c9193db7ce5407abc6bad3/local/languages gb.ini#L48 To incorporate these into the VuFind master, we may want to make the local filter configurable and make the tra system a bit more generic (to avoid currency codes in the language file, and to make translation string names les specific). However, it seems that it would only take a small amount of adaptation to make use of the existing cod Generated at Sat Mar 05 22:12:53 EST 2016 using JIRA 6.2.6#6264sha1:ee7642271310c09537d01e5848a003c4498a0eed.