Mike Rylander [Mon, 7 Aug 2017 14:05:05 +0000 (10:05 -0400)]
offline: Remove reference to nonexistent file
When the status bar was removed back in commit 7814064, the reference to its
backing JS file was removed from base_js.tt2. It looks like that slipped
back in at some point in the combined serials/offline branch. This removes
that references, which causes offline failure.
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Kathy Lussier <klussier@masslnc.org>
Here is implemented an offline mode interface for the web staff client.
It is made available during both network and server outages by using the
UpUp[1] service worker wrapper.
We leverage Lovefield[2] for local storage of library settings, configuration
data, offline transactions, and the standalone offline block list.
In order to make use of the offline interface, users should first log into
the web staff client and navigate to the "Search -> Search for Patrons"
interface, perform a search, select a user from the results, and open the
Patron Editor interface. This will allow the offline interface to collect
all the relevant configuration information for the workstation. In addition,
the offline interface available from the Circulation menu provides a "Download
block list" button when accessed while logged in.
Cesar Velez [Thu, 24 Aug 2017 21:17:11 +0000 (17:17 -0400)]
LP#1710512 - OPAC js strings need to be i18n-izable
Adds a way to translate displayed string messages, in OPAC
JS source code alerts and other outputs. This is done by having
js.tt2 include i18n-strings.tt2 which contains an explosed/global
JS blob variable called eg_opac_i18n. This is intended to work
in similar fashion as base_js.tt2 in the webstaff ng client.
Signed-off by: Cesar Velez <cesar.velez@equinoxinitiative.org> Signed-off-by: Jason Stephenson <jason@sigio.com> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>
blake [Tue, 17 May 2016 21:27:00 +0000 (16:27 -0500)]
LP1582354 report able to show bibs where the last copy was deleted cancels
Created a view for ease of reporting. This source table allows you to construct
a clever aggregate report template which will report bibliographic ID's where a
library or a group of libraries no longer have a copy attached but had* a copy
attached. This is especially useful when a holdings sync is required with an
external vendor.
Signed-off-by: blake <blake@mobiusconsortium.org> Signed-off-by: Chris Sharp <csharp@georgialibraries.org> Signed-off-by: Jason Etheridge <jason@EquinoxInitiative.org>
LP#1048822 - Fuller Title for reporter.super_simple_record
The simplified pull list uses reporter.super_simple_record for
title information. reporter.super_simple_record currently only
pulls the first 245a value for the title. For titles that
use 245(n|p) to fully identify the title this leaves out information
that staff need to find the item.
This patch adds all of the 245(n|p) to the 245a in the title. I've found
this covers most cases where staff need a fuller title. The order of
the 245(n|p) also matters, so steps are taken to keep the marc ordering
of those fields.
Testing:
Before Patch - find a title that uses a 245(n|p) field to fully identify the
title. Place a hold on the title. Use the simplified pull list to view the
location that has that item on the shelf. Observe that only the 245a is in
the title field.
After Patch - Look at the simplified pull list again and see that the title now
includes more information.
Signed-off-by: Josh Stompro <stomproj@larl.org> Signed-off-by: Dan Pearl <dpearl@cwmars.org> Signed-off-by: Kathy Lussier <klussier@masslnc.org>
Skye Howard [Thu, 17 Aug 2017 21:52:08 +0000 (21:52 +0000)]
LP#1629298: Web Client Checkout Fails For Barcodes With Spaces
Web Client checkout trims spaces from patron barcodes differently than xul client checkout
The web client was not removing the whitespaces before checking barcode searches
this commit includes a step where the whitespaces are removed.
Signed off by Skye Howard <showard@catalyte.io>
Signed off by Cesar Velez <cesar.velez@equinoxinitiative.org> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>
New optional SMS text notification to be sent 3 days prior to the due
date of any circulating item for patrons who have an SMS text number
and carrier stored in their accounts. This action trigger is disabled
by default and can be enabled in Admin > Local Administration >
Notifications / Action Triggers.
Mike Rylander [Wed, 9 Aug 2017 18:14:42 +0000 (14:14 -0400)]
LP#1698206: Remove remaining SQL uses of the old copy visibility cache
There were two remaining uses of the old copy vis cache in SQL functions used
to render OPAC pages. This commit gets rid of those.
There is still one reference to the asset.opac_visible_copies table in the old
staged-search function, but that is not used anywhere in the code now, so no
need to change that. Instead, we should start pruning old code.
Mike Rylander [Mon, 10 Jul 2017 14:35:07 +0000 (10:35 -0400)]
LP#1698206: Indicate broad searches and heavy facets
There is a configurable, pagable limit on hits, defined by the superpage
size and max superpages. When the hit count equals this (by default,
100000) we add a '+' to the hit count to show that there are even more hits.
Facets are calculated per superpage, and if the facet use count equals the
number of superpages seen so far multiplied by the superpage size, we
likewise add '+' to indicate that there are likely more records matching the
facet.
For facets, a user can page far enough to increase the visible number, if
they cross superpage boundaries.
The old code needed to refine the estimated hit count as each superpage was
read, but we don't need any of that anymore. Also, it was causing hit count
display issues on superpages after the first. So, we do away with all that.
=== Background
Evergreen stores all data, including that useful for patron and staff search,
in a normalized schema that is time and space efficient for transactional use
cases, and provides guarantees on data integrity. In addition, development is
made simpler than would be the case otherwise and arbitrary reporting is made
possible.
However, this structure is not effective for direct, SQL-only search
functionality in a hierarchical, consortial dataset. This is a problem that
is relatively unique to Evergreen, as it is most often employed to host and
serve large consortia with overlapping bibliographic datasets and
non-overlapping item and location datasets. Other search engines, including
those built into other ILSs, do not generally have to account for
hierarchically organized location visibility concerns as a primary use case.
In other words, because it provides functionality that requires a hierarchical
view of non-bibliographic data, a problem space for Evergreen is essentially
nonexistent in competing products.
Evergreen's search infrastructure has evolved over the years. In its current
form, the software first performs a full text search against extracted
bibliographic data and limits this initial internal result set to a
configurable size. It then investigates the visibility of each result on
several non-bibliographic axes. These visibility tests take up the
preponderance of CPU time spent in search, with full text search of the
bibliographic data generally completing within milliseconds. The main reason
this multi-stage mechanism is used is that there are many visibility axes and
attempting to join all required data sources together in a single query will
cause the search use case to perform very poorly. A previous attempt to
create a pure SQL search mechanism failed for this reason.
A significant drawback of the current approach is that the costs imposed by
visibility filtering search results using normalized non-bibliographic data,
either in-query or separated from the main full-text query as it is today,
make it necessary to place limits on the number of database rows matched by
full-text query constructs. This in turn can cause searches to omit results
in certain situations, such as a large consortium consisting of a few large
libraries and many small libraries.
However, it has been shown possible to overcome this performance issue by
providing an extensible way to collect all visibility related information
together into a small number of novel data structures with a compact in-memory
representation and very fast comparison functions. In this way, we are able
to use pure SQL search strategies and therefore avoid result visibility
problems while also benefiting from improvements to the core PostgreSQL
database engine. Further, this will open the door to indexing improvements,
such as removal of the need for duplicate data storage, or the use of non-XML
data storage schemes, which could reduce resource requirements and have a
direct, positive effect on patron and staff search experience.
=== Overview of existing search logic
. Construct core bibliographic search query
. Collect non-bibliographic filtering criteria
. Pass query and filters to a database function
. Calculate hierarchical location information for visibility testing
. Open cursor over core query, limited to *superpage_size * max_superpages* records
. Core query implements bib-level sorting
. For each result
.. NEXT if not on requested superpage
.. Check deleted flag, based on search type
.. Check transcendence
... Return result if true
.. Check for direct Located URI in scope
... Return result if exists
.. Check copy status + (circ lib | owning lib) based on modifier
.. Check peer bib copy status + (circ lib | owning lib) based on modifier
.. Check copy location based on filter
.. Check peer bib copy location based on filter
.. General copy visibility checks
... If NOT staff
.... Check for OPAC visible copies (trigger-maintained materialization)
.... Check for peer bib OPAC visible copies
... If staff
.... Confirm no copies here
.... Confirm no peer bib map
.... Confirm no copies anywhere
.... Confirm no Located URIs elsewhere
.. Return result if not excluded
. Calculate summary row
=== Overview of new mechanism
Record and copy information (everything checked in *(7)* above) is collected
into a novel data structure that allows all visibility-indicating criteria to
be flattened to integer arrays. This is facilitated by a database trigger in
much the same way that basic OPAC copy visibility is collected for copies
today.
Most identifiers in Evergreen are stored as signed integers of either 32 or 64
bits. The smaller 32 bit space allows for approximately two billion positive
entries, but all identifiers for table rows that are used as visibility axes
fall into a range of between one and one million for all applicable use cases,
and all identifiers of interest are positive. Therefore, we can make use of
the most significant bits in an integer value to create a per-axis namespacing
mask. When applied to the idenfitifer for a visibility axis identifier, this
mask allows two values that are identical across axis to be identified as
unique within a combined set of all values.
Sepcifically, we retain the four most significant bits of the integer space
and create from that 16 potential bitmasks for per-axis segregation of
identifiers. Further, we separate copy-centered axes and bibliographic
record-centered attributes into two separate columns for storage purposes,
which means we can use the same four bits for different purposes within each
copy or bib set.
In order to implement existing visibility tests with this infrastructure, six
copy axes and two record axes are used from the possible 16 from each set.
See the search.calculate_visibility_attribute() for details. By using 32 bit
integers we can collect all of the bitmasked values of each type (copy or bib)
into a single integer array and leverage the Postgres intarray extension to
test all axes at once.
At search time, required and user-requested visibility restrictions are
converted to *query_int* values. Results are directly filtered based on these
calculated *query_int* values. This works in a way analogous to record
attribute filtering, avoiding the need to test statuses, circ and owning
library visibility, copy locations and location groups, copy OPAC visibility,
peer bibliographic record, Located URIs, or bibliographic record sources
directly.
=== Minimum Postgres version requirement
Due to features, particularly functions, available only in 9.4 and newer that
are key to the performance of the new method, Postgres 9.4 will need to be the
new lowest supported version for use with Evergreen. While some of the new
features and functions could be implemented as user-defined functions in
PL/PGSQL, they would not be fast enough to make this pure-SQL search viable.
Among the important improvements that Postgres 9.4 and newer versions bring to
Evergreen are:
* Version 9.4 improved GIN indexes in ways that directly benefit Evergreen, as well as how anti-joins are planned which matters for some Evergreen searches.
* Version 9.5 introduced many general performance improvements, especially for joins and sorting, and brought planner improvements that impact complex queries such as those generated by this code.
* Version 9.6 delivered more general performance improvements, particularly for large servers such as those that Evergreen databases tend to live on, as well as more improvements to GIN indexes, executor changes that can avoid unnecessary work in search queries, new built-in full-text phrase searching, and initial parallel query execution.
=== Performance
The cost of the non-bibliographic filter value caching maintenance process is
10-40% faster than existing partial caching logic which it would replace.
The new code achieves up to 10% faster search times than the old, suboptimal
mechanism time for broad searches. The new code is faster for more selective
searches, often by up to 90% faster. In both broad and narrow search cases
the new mechanism performs with complete accuracy and does not miss
small-collection hits in large consortia as the existing code does.
Unsurprisingly, and in addition to the above improvements, performance is
improved marginally as each successive Postgres version at and beyond 9.4.
=== Page rendering changes
Previously, Evergreen would request the record details for a user-visible page
of results in parallel, and then, serially, request the facet data for the
result set. Now, the facet data is requested asyncronously in the background
and then a single feed containing all records on a result page is requested
syncronously. By parallelizing the result and facet metadata, page rendering
time is cut down significantly. Concurrent requests of the same bibliographic
record are shared between apache backends to reduce result request time, and by
making one request instead of ten simultaineously, database load is reduced. A
performance improvement of up to 20% in post-search page rendering time is seen
from this change.
Additionally, cross-apache caching of ancillary data, such as the coded value
map and other data, via memcache significantly reduces the average page
rendering time not just for result pages, but most pages generated by
Evergreen. An additional performance improvement of up to 50% in post-search
page rendering time is seen from this change.
While these changes are not directly related to the removal staged search, they
touch areas impacted by core search changes and provided enough improvement
that implementing them concurrently with the elimination of staged search
seemed optimal.
=== User visible configuration changes
The stock configuration now provides an increased value for *max_superpages*
in opensrf.xml. The default is now 100, and the *superpage_size* remains
1000, for a total limit of 100,000 hits per search. This is not a limit on
visibility per se, as all records are visibility tested and ranked before
limiting, but simply a limit on the number of pages a user could click through
before reaching the end of the presented result list.
=== Tuning sensitivity
User-level timeouts are still possible with both the old and new code, given a
large enough dataset, a broad enough query, and a cold cache. However, the
*gin_fuzzy_search_limit* GUC can be used to set a time cap on the new
mechanism. See https://www.postgresql.org/docs/9.6/static/gin-tips.html for
background, though the suggested values in the documentation are significantly
lower than would be readily useful for a large Evergreen instance.
Because it uses a more complex query structure, the new mechanism is somewhat
more sensitive to Postgres tuning in general. In particular, lowering
*random_page_cost* from the default of *4.0* to a more reasonable *2.0* is
important for proper query planning. For Evergreen use cases where the search
indexes and relevant tables are kept in RAM or SSDs are used for storage, this
value is acceptable and useful in general.
=== Funding and development
This project was funded by MassLNC and developed by Equinox Open Library
Initiative.
Currently, editing and deleting of users must be performed on a user-by-user
basis. There are workflows that would benefit from the ability to act on a
set of users, where the changes to all users in the set are the same.
This commit provides a new interface analogous to the Copy Bucket interface
to record the selection and grouping of a set of users into a User Bucket.
The addition of users to a User Bucket is possible from the Patron Search
interface by the use of a new grid Action, and directly on the User Bucket
interface by user barcode. It is also possible to add users by uploading
a text file that contains a list of user barcodes.
From this interface it is possible to perform a set of specific batch update
operations against users generally.
Editing users
-------------
In order to facilitate the update of user data fields, specifically:
* Active flag
* Primary Permission Group (group application permissions consulted)
* Juvenile flag
* Home Library (UPDATE_USER checked against both old and new value)
* Privilege Expiration Date
* Barred flag (BAR_PATRON permission consulted)
* Internet Access Level
This commit contains a new set of business logic allowing staff to supply new
values for these fields. Creation and immediate processing of a change set
will be made available through a grid Menu item. If the staff user does not
have the UPDATE_USER permission, this option will be disabled.
Each change set requires a name. Buckets may have multiple change sets. All
users in the Bucket at the time of processing will be updated when the change
set is processed, and change sets are processed immediately upon successful
creation. The interface will deliver progress information regarding the
processing stage and percent of completion.
While processing the users, the original value for each field edited will be
recorded for potential future rollback. Users can examine the success and
failure of applied change sets.
The user will be able to rollback the entire change set, but not parts thereof.
The rollback will affect only those users that were successfully updated by the
original change set and may be different from the current set of users in the
Bucket. Users can manually discard change sets, removing them from the
interface but preventing future rollback.
As a batch process, rather than a direct edit, this mechanism explicitly skips
processing of Action/Trigger event definitions for user update.
Deleting users
--------------
In order to facilitate the batch deletion of users, this commit creates a new
set of business logic allowing staff to set the Deleted flag on users.
Creation and immediate processing of a batch delete is made available through
a grid Menu item. If the staff user does not have both the UPDATE_USER and
DELETE_USER permission, this option is disabled. Because of the potential for
damage and the additional required permission, this field change is
specifically segregated from the general Editing functionally described above.
Each delete set requires a name. Buckets may have multiple delete sets. All
users in the Bucket at the time of processing will be marked as deleted when
the delete set is processed. The interface will deliver progress information
regarding the processing stage and percent of completion.
While processing the users, the original value for the "deleted" field will be
recorded for potential future rollback. Users will be able to examine the
success and failure of applied delete sets in the same interface used for the
above described change sets.
As a batch process, rather than a direct edit, this mechanism explicitly skips
processing of Action/Trigger event definitions for user deletion.
This mechanism does not use the Purge User functionality, but instead simply
marks the users as deleted. Future enhancement could add such functionality.
In order to facilitate the batch editing, addition, and removal of
Statistical Category Entries for users, this commit creates a new set of
business logic allowing staff to either remove or add & update Entries for
Statistical Categories to which the staff member has access. Processing of
Statistical Category Entry modifications will are available through a grid
Menu item.
All users in the bucket will have their Statistical Category Entries
modified. Unlike user data field updates, modification of Statistical
Category Entries is permanent and cannot be rolled back. No named change
sets are required. The interface will deliver progress information regarding
the processing stage and percent of completion.
As a batch process, rather than a direct edit, this mechanism explicitly skips
processing of Action/Trigger event definitions for user update.
New service requirement
-----------------------
This new functionality makes use of the QStore service, which was previously
unused in production. If this service has been removed from the configuration
of a live Evergreen instances, it will need to be added back in order for
batch user editing to succeed.
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Scott Thomas <scott.thomas@sparkpa.org> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>
Conflicts:
Open-ILS/src/templates/staff/circ/patron/index.tt2
Open-ILS/web/js/ui/default/staff/circ/patron/app.js
McCanna [Fri, 25 Aug 2017 13:53:14 +0000 (09:53 -0400)]
LP#1712840 Ebook tabs always visible in My Account
Corrects a problem in My Account where the ebook tabs
on the checkouts and holds pages were always visible
regardless of whether the ebook_api.enabled value was
set to true or false.
Transfer checkout history rows to the destination user during patron
merge.
To Test:
1. Enable circ history tracking for 2 users, ideally 2 with same
last name for easy searching.
2. Check out items to both patrons.
3. Load the 2 patrons in the patron search UI and merge one into the other.
4. action.usr_circ_history rows previously linked to the deleted patron
will now be linked to the active/lead patron.
Signed-off-by: Bill Erickson <berickxx@gmail.com> Signed-off-by: Jason Etheridge <jason@EquinoxInitiative.org>
Cesar Velez [Fri, 11 Aug 2017 15:00:29 +0000 (16:00 +0100)]
LP#1685929-Adds more XUL parity to Webstaff checkIn
Checkin Grid context actions like Add Items to Bucket, Show Holds on Bib, Show
Last Few Circulations, Edit Item Attributes, Mark Item Missing Pieces,
Print Spine Label, were missing from CheckIn in webstaff.
Jason Boyer [Thu, 24 Aug 2017 21:34:02 +0000 (17:34 -0400)]
LP1712922: Exclude Deleted ACPL in Vol/Copy Editor
Just what it says on the tin. When loading the list of ACPL
in the editor only retrieve the non-deleted locations.
Tester's note: there's no database contraint that strictly
prevents a copy from linking to a deleted location, so for
items like that, the copy location selector will be blank. This
is an uncommon situation, but Evergreen admins can identify
such items by running the following query:
select acp.id, acp.barcode, acpl.name
from asset.copy acp
join asset.copy_location acpl on (acpl.id = acp.location)
where not acp.deleted
and acpl.deleted
order by acp.id;
Signed-off-by: Jason Boyer <jboyer@library.in.gov> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>
Michele Morgan [Wed, 9 Aug 2017 15:36:20 +0000 (11:36 -0400)]
LP 1708728 - Fix Stripe penny errors introduced by perl int() function
Fixes the issue where payment amounts sent to Stripe can be one cent less
than the actual Evergreen payment due to use of the perl int() function.
To test
-------
A Stripe account is required to view transactions on the Stripe side.
To enable test payments, Stripe testing API keys need to be entered
in the Evergreen ou settings:
- Add a bill to a patron record with the following amounts: $8.20
- Login to the opac as the patron and pay the bill.
- View the transaction on the Stripe side and see that it is one cent
less than the paid bill in Evergreen.
- Apply the patch.
- Repeat the steps above.
- On the Stripe side, see that the Stripe amount and Evergreen amount
now match.
Signed-off-by: Michele Morgan <mmorgan@noblenet.org> Signed-off-by: Dan Pearl <dpearl@cwmars.org> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>
Galen Charlton [Wed, 23 Aug 2017 19:22:28 +0000 (15:22 -0400)]
LP#1708485: (follow-up) improve dest_courier_code support
This patch ensures that dest_courier_code is added to
the printer context; it also displays the courier code (if set)
on the transit modal and mentions dest_courier_code in the
inline documentation for transit and hold slips.
Dan Scott [Tue, 15 Aug 2017 14:19:22 +0000 (10:19 -0400)]
LP#1710747: Absolute URL for media_prefix in templates
If OILSWebMediaPrefix is set in the Apache configuration, then
the ctx.media_prefix TT2 template variable uses that value as the
hostname; otherwise it is null, resulting in many relative URLs for
images, CSS, and JavaScript files.
Normally this is not a problem, but the Open Graph image property
requires a full absolute URL rather than the relative URL that would
previously result on the record summary page in the absence of the
OILSWebMediaPrefix variable having been set in the Apache config.
This patch tweaks the EGWeb handler to fall back to the base hostname in
the absence of the OILSWebMediaPrefix variable, thus ensuring that all
uses of ctx.media_prefix result in an absolute URL.
Test Plan:
Pre-patch - Visit a record summary page in the catalog. View the source of the
page. In the head section, find the og:image meta property. The content will
display a relative URL to the record's book jacket cover image.
Post-patch - When viewing the source of the page, og:image will display the
full URL.
Signed-off-by: Dan Scott <dscott@laurentian.ca> Signed-off-by: Kathy Lussier <klussier@masslnc.org>
Galen Charlton [Wed, 23 Aug 2017 15:54:32 +0000 (11:54 -0400)]
LP#1694577: tweak searching for words in report templates
Use \m to recognize beginning-of-word boundaries; this fixes
an issue where you couldn't use "clone" to retrieve templates
whose name was of the form "foo (clone)".
Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org> Signed-off-by: Jason Etheridge <jason@EquinoxInitiative.org>
Adds new API call open-ils.reporter.search.templates allowing search of
reporter template names and/or descriptions. Searching is
case-insensitive, any order, with left-anchored words. Searching can be
for specific folders or all folders visible to the calling user.
Adds paging support (limit / offset) for retriving templates, reports,
and outputs.
Signed-off-by: Bill Erickson <berickxx@gmail.com> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org> Signed-off-by: Jason Etheridge <jason@EquinoxInitiative.org>
Dan Scott [Wed, 12 Jul 2017 14:07:23 +0000 (10:07 -0400)]
LP#1703678 Display foreign item location and status
We were using copy_info instead of the foreign item's data to try to display
location and status of foreign items. As copy_info had not been initialized,
it displayed nothing. Use the foreign item data instead for location and
status.
Signed-off-by: Dan Scott <dan@coffeecode.net> Signed-off-by: Mike Rylander <mrylander@gmail.com>
Cesar Velez [Tue, 8 Aug 2017 20:13:15 +0000 (16:13 -0400)]
LP#1624443 - TPAC 500 error after adding duplicate title to Temp List
Credit to gmcharlt, prevents the my list (temporary list) page from
crashing when a user has added a title to the list more than once.
This can happen if they add a title then login, then redo search and
add same title. Per Galen, it looks like an issue with
OpenSRF::MultiSession parallel record retrieval causing some kind of
race condition when there are duplicate entries in the list.
Signed-off by: Cesar Velez <cesar.velez@equinoxinitiative.org> Signed-off-by: Chris Sharp <csharp@georgialibraries.org> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>
[1] In the web staff client, perform a catalog search. From search
results, choose Place Hold.
[2] In the form that displays, click the 'Patron Search' button.
[3] Verify that a modal with a patron search form is displayed.
[4] Search for a patron, then select one and click the 'Select'
button.
[5] Verify that the patron's barcode is inserted into the patron
barcode input.
[6] Verify that submitting the form successfully places the hold.
[7] Verify that the feature works from a bib record details page.
[8] Verify that the Patron Search button does not show up when
using the place hold form in the public catalog.
[9] Verify that normal patron search, retrieval, and registration
functionality continues to work, as this patch series does some
refactoring to create a reusable Angular patron search service
and templates.
Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org> Signed-off-by: Chris Sharp <csharp@georgialibraries.org> Signed-off-by: Jason Etheridge <jason@EquinoxInitiative.org>
This patch teaches the web staff client's catalog app how
to activate the patron search button in the embedded catalog's
place hold form. It also adds a handler for the button action
to display a modal to allow the staff member to search
for and select a patron, then injects the patron's barcode
into the form.
Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org> Signed-off-by: Chris Sharp <csharp@georgialibraries.org> Signed-off-by: Jason Etheridge <jason@EquinoxInitiative.org>
Galen Charlton [Fri, 26 May 2017 20:41:38 +0000 (20:41 +0000)]
LP#1701001: carve out a reusable patron search service
This patch moves the patron search service and the base
patron search controller into a separate, reusable
file. The core patron search service is available for
injection as patronSvc from the new egPatronSearchMod, while
BasePatronSearchCtrl now exists as a base controller for the
patron search form that can be extended as needed by doing
something like this:
module.controller('DerivedPatronSearchCtrl', [
'$scope', '$controller',
function ($scope, $controller) {
// Initialize the super class and extend it.
angular.extend(this, $controller('BasePatronSearchCtrl', {$scope: $scope}));
...
Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org> Signed-off-by: Chris Sharp <csharp@georgialibraries.org> Signed-off-by: Jason Etheridge <jason@EquinoxInitiative.org>
The item service currently living inside the item status app does not know how
to fetch multiple barcodes at once. So, we'll loop over them and refresh the
grid when they're all retrieved.
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>
Chris Sharp [Fri, 7 Jul 2017 17:04:35 +0000 (13:04 -0400)]
LP#1702968 - Add missing error string - mark item damaged.
When marking an item damaged for a circulation that has been
archived/aged, the patron receives an error that the string
associated with staff.cat.util.mark_item_damaged.item_no_linked_patron
is not there. This branch adds it.
Signed-off-by: Chris Sharp <csharp@georgialibraries.org> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>
1. Provide an admin-friendly summary of changes at the top of the release notes.
2. Change quoting of optional post-upgrade SQL echoing in the upgrade script.
3. Fix preexisting issue with variable interpolation inside an alert modal.
4. Protect against null or empty date fields when formatting.
Signed-off-by: Mike Rylander <mrylander@gmail.com>
5. Added if (date == 'now') check.
Bill Erickson [Thu, 3 Aug 2017 15:35:31 +0000 (11:35 -0400)]
LP#1705524 Closed dates editor handles no timezones
Fix issue in closed dates editor where it failed creating new closed
dates when an org unit had no value applied for the lib.timezone org
unit setting.
Signed-off-by: Bill Erickson <berickxx@gmail.com> Signed-off-by: Mike Rylander <mrylander@gmail.com>
Here we'll use moment.js to format all dates that want to use the angular date
filter, for consistency and standards compliance. The primary benefit is the
ability to use a proper timezone (region) rather than just a simple GMT offset.
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Bill Erickson <berickxx@gmail.com>
Now that due dates are globally stored in the configured timezone of the
circulating library, the automatic adjustment to day-granular due dates needs
to take those timezones into account.
An optional SQL command is provided by the upgrade script to retroactively
adjust existing due dates after library configuration is complete.
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Tina Ji <tji@sitka.bclibraries.ca>
Mike Rylander [Wed, 21 Jun 2017 18:03:29 +0000 (14:03 -0400)]
LP#1705524: Honor timezone of the acting library where appropriate
This is a followup to the work done in bug 1485374, where we added the ability
for the client to specify a timezone in which timestamps should be interpreted
in business logic and the database.
Most specifically, this work focuses on circulation due dates and the closed
date editor. Due dates, where displayed using stock templates (including
receipt templates) and used for fine calculation, are now manipulated in the
library's configured timezone. This is controlled by the new 'lib.timezone'
YAOUS, loaded from the server when required. Additionally, closings are
recorded in the library's timezone so that so that due date calculation is more
accurate. The closed date editor is also taught how to display closings in the
closed library's timezone. Closed date entries also explicitly record if they
are a full day closing, or a multi-day closing. This significantly simplifies
the editor, and may be useful in other contexts.
To accomplish this, we use the moment.js library and the moment-timezone addon.
This is necessary because the stock AngularJS date filter does not understand
locale-aware timezone values, which are required to support DST. A simple
mapper translates the differences in format values from AngularJS date to
moment.js.
Of special note are a set of new filters used for formatting timestamps under
certain circumstances. The new egOrgDateInContext, egOrgDate, and egDueDate
filters provide the functionality, and autogrid is enhanced to make use of
these where applicable. egGrid and egGridField are also taught to accept
default and field-specific options for applying date filters. These filters may
be useful in other or related contexts.
The egDueDate filter, used for all existing displays of due date via Angular
code, intentionally interprets timestamps in two different ways WRT timezone,
based on the circulation duration. If the duration is day-granular (that is,
the number of seconds in the duration is divisible by 86,400, or 24 hours worth
of seconds) then the date is interpreted as being in the circulation library's
timezone. If it is an hourly loan (any duration that does not meet the
day-granular criterium) then it is instead displayed in the client's timezone,
just as all other timestamps currently are, because of the work in 1485374.
The OPAC is adjusted to always display the due date in the circulating
library's timezone. Because the OPAC displays only the date portion of the due
date field, this difference is currently considered acceptable. If this proves
to be a problem in the future, a minor adjustment can be made to match the
egDueDate filter logic.
This work, as with 1485374 was funded by SITKA, and we thank them for their
partnership in making this happen!
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Tina Ji <tji@sitka.bclibraries.ca>
This commit removes the OpenILS::SIP::clean_text utility function and
all references to it in the OpenILS::SIP modules. Its job is now done
in SIPServer's write_msg routine.
Ben Shum [Mon, 17 Apr 2017 21:20:25 +0000 (17:20 -0400)]
LP#1681864: Add pocommentclean for db.seed cleanup prior to updatepo
By adding a segment to run pocommentclean against the db.seed locale file
prior to doing updatepo against the file from the PO template, we clear
any unwanted old and outdated comment IDs prior to applying clean newly
synchronized comment IDs from the PO template.
Signed-off-by: Ben Shum <ben@evergreener.net> Signed-off-by: Chris Sharp <csharp@georgialibraries.org> Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>
Galen Charlton [Thu, 10 Aug 2017 16:45:58 +0000 (12:45 -0400)]
LP#1709932: recognize more strings from oils_i18n_gettext()
This patch makes db-seed-i18n.py more flexible about
where commas between strings in invocations of oils_i18n_gettext()
can appear, reduces the chances that strings fail to be grabbed
for translation. It also improves the error message shown
when parsing errors occur.
To test
-------
[1] Apply patch and run
cd build/i18n && make sql2pot
[2] Verify that no error messages are produced during
this step.
[3] Inspect the changes to po/db.seed/db.seed.pot and
verify that additional strings are added, including
"Item Print Label Font Family".
[4] (optional) Deliberately remove a comma from an
oils_i18n_gettext invocation in 950.data.seed-values.sql
and run make sql2pot again. The error message shoudl
now include the failing chunk of text.
Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org> Signed-off-by: Chris Sharp <csharp@georgialibraries.org>
projects / working / Evergreen.git / log