[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</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 "). 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.