Re: [OPEN-ILS-GENERAL] match point issue/date due problem-altered now
Hi Janice,
I am not sure I understand quite well, whether the „no_matchpoint“ problem
occurs when checking out any book or whether it occurs only for one
particular book with the barcode 123285.
If it happens with the one particular book only, I would guess the problem
might be related to item attributes and probably some of the attributes
defined in the circulation policies are missing or having a wrong value .
For example in our library it happens - according circulation policies -
with items that have „is reference“ flag or when circulation modifier is
missing (but it could be anything else, like wrong or missing user home
library etc.).
Eva
2014-05-21 20:58 GMT+02:00 Janice Huber janice.hu...@asburyseminary.edu:
Okay, I got good thoughts and suggestions for my Hard Due date issue but
when I tried to delete and add a new Hard Due date to start over, I started
to get a message that starts with a no match points message and goes on
to the below message:
Network or server failure. Please check your Internet connection to
evergreen-dev.asburyseminary.edu and choose Retry Network. If you need
to enter Offline Mode, choose Ignore Errors in this and subsequent dialogs.
If you believe this error is due to a bug in Evergreen and not network
problems, please contact your help desk or friendly Evergreen
administrators, and give them this information:
method=open-ils.circ.checkout.full.override
params=[65364592fe99660d932b708ae4ecd961,{barcode:123285,patron:10629},0]
THROWN:
{payload:[],debug:osrfMethodException : *** Call to
[open-ils.circ.checkout.full.override] failed for session
[1400676484.461296.140067648415801], thread trace [1]:\nCan't call method
\duration_rule\ on an undefined value at
/usr/local/share/perl/5.14.2/OpenILS/Application/Circ/Circulate.pm line
1914.\n\n,status:500}
STATUS:
I don't know it someone else made a change in our system or if what I was
trying to do caused this error. The book I am trying to check out gives
that same message for every type of patron. I was only working with a
policy for one type of patronso wise ones, any insight.
*We were able to add a duration rule of default and leave the hard due
date actively in a field also but now we get the message of no match
points and then There was a network failure.*
The consistent issue here is no match points. I have checked everywhere
I can, making sure the default circulation policy has an entry for things
like duration rule and max fines but something is not matching...
Can anyone help? Fishing around all day is not getting it done.
Janice Huber
Information Commons Manager
204 N Lexington Ave
Wilmore, KY 40390
859.858.2230
--
Mgr. Eva Cerniňáková
cer...@jabok.cz
Tel. +420 211 222 409
Knihovna Jabok
http:/knihovna.jabok.cz
Tel. +420 211 222 410
Jabok - Vyšší odborná škola sociálně pedagogická a teologická
Salmovská 8, 120 00 Praha 2
IČO: 45769621, DIČ: CZ45769621
Č. ú. 1993 04/5500 - Raiffeisenbank
Re: [OPEN-ILS-GENERAL] match point issue/date due problem-altered now
It may be a good practice to put in a catch all policy to prevent no_matchpoint errors, and perhaps give it an unusual loan period to give staff a heads-up. -- Jason Etheridge | Support Manager | Equinox Software, Inc. / The Open Source Experts | phone: 1-877-OPEN-ILS (673-6457) | email: ja...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-GENERAL] match point issue/date due problem-altered now
Did you make any changes to your default circulation policy? I received the
no_matchpoint error when I attempted to modify the loan duration in our default
Circulation Policy Configuration. My solution was to restore the original
policies to their defaults and then create a new policy for specific
items(Permission Group, Circulation modifier, Copy location. . .etc).
On May 21, 2014, at 1:58 PM, Janice Huber janice.hu...@asburyseminary.edu
wrote:
Okay, I got good thoughts and suggestions for my Hard Due date issue but when
I tried to delete and add a new Hard Due date to start over, I started to get
a message that starts with a no match points message and goes on to the
below message:
Network or server failure. Please check your Internet connection to
evergreen-dev.asburyseminary.edu and choose Retry Network. If you need to
enter Offline Mode, choose Ignore Errors in this and subsequent dialogs. If
you believe this error is due to a bug in Evergreen and not network problems,
please contact your help desk or friendly Evergreen administrators, and give
them this information:
method=open-ils.circ.checkout.full.override
params=[65364592fe99660d932b708ae4ecd961,{barcode:123285,patron:10629},0]
THROWN:
{payload:[],debug:osrfMethodException : *** Call to
[open-ils.circ.checkout.full.override] failed for session
[1400676484.461296.140067648415801], thread trace [1]:\nCan't call method
\duration_rule\ on an undefined value at
/usr/local/share/perl/5.14.2/OpenILS/Application/Circ/Circulate.pm line
1914.\n\n,status:500}
STATUS:
I don't know it someone else made a change in our system or if what I was
trying to do caused this error. The book I am trying to check out gives that
same message for every type of patron. I was only working with a policy for
one type of patronso wise ones, any insight.
We were able to add a duration rule of default and leave the hard due date
actively in a field also but now we get the message of no match points and
then There was a network failure.
The consistent issue here is no match points. I have checked everywhere I
can, making sure the default circulation policy has an entry for things like
duration rule and max fines but something is not matching...
Can anyone help? Fishing around all day is not getting it done.
Janice Huber
Information Commons Manager
204 N Lexington Ave
Wilmore, KY 40390
859.858.2230
Trevor Johnson
Information Technology
Alabama Public Library Service
Re: [OPEN-ILS-GENERAL] staff client dev 2014-05-19 / feedback
I would like to comment on a couple of the things Dan said. We are taking something which is fundamentally a website concept (a link between pages) and applying it to an application, and we need to very careful that we don't misapply a web-centric mindset to any areas where that thinking isn't appropriate. - Dan (Please excuse me if this isn't the right time or place for this comment - I am not trying to hijack the thread, nor start a debate.) I would just like to extend that a bit to also say don't misapply a mouse-centric approach where it might not be appropriate. I'm an end-user, a cataloger, and entering marc records is, at its most basic, very much like data entry. That means hands are on the keyboard most of the time, so going to the mouse to move around or save the bib slows down the process. So I use the alt/ctrl shortcuts, and the tab key, but these aren't always faster, or not available. (I can provide examples if anyone is interested.) Entering patron data is similar, so I think my comment applies. Again, please disregard if this is not relevant or useful to the conversation. Instead of thinking of things as links and then trying to make one rule for a bunch of disparate things, I'd propose that we should have distinctive interface elements for which we can then define usage appropriate behaviors. Doing so would create a tremendous opportunity for improving the overall usability of the staff client as a whole. - Dan This sounds to me like creating consistency - things would behave the same in multiple places. +1 [going back to lurking mode] Vickie Vickie Turcotte Head of Technical Services Chelmsford Public Library 25 Boston Rd. Chelmsford, MA 01824 978-256-5521 x106 Fax: 978-256-8511 vturco...@mvlc.org
Re: [OPEN-ILS-GENERAL] staff client dev 2014-05-19 / feedback requests
Dan, Thanks for all of this. Pushing everyone to think about the broader context of user interaction types and expectations is /very/ important. My thoughts on this basically boil down to a few simple rules of thumb we could follow: *) if the interface component brings you to a screen that shows a related but different object type, or expose actions whose focus is something other than the currently displayed object - use a link that looks like a link (and is just a link, with all native click/modifier combinations) ... Example: going from the patron items out list to the item detail UI *) if the interface component shows more/less detail for the displayed object, exposes actions whose focus is the displayed object, saves or cancels data entry actions, or brings you from a list of objects to a UI focused on an instance of the listed objects - use a button (or image) ... Example: going from the patron alert screen to the patron edit screen. Now, in-UI tab headings, like in the patron UI, are something in between these two. In that case, using a link that goes bold (instead of underlined) on mouse-over -- or a similar visual cue -- makes sense to me. Obviously these don't cover everything, and my rules of thumb might be wrong in may ways, but I offer them in the hopes of seeding a set of guidelines as you suggest. Thoughts, anyone? On Wed, May 21, 2014 at 7:00 PM, Dan Wells d...@calvin.edu wrote: Hello Bill, Thanks for the update. I have some thoughts about both of your questions, but will focus on the link issue for now. I’m not quite sure how to answer because I feel like we’re not asking the right question. Rather than ask how links should behave, we might instead ask, what should be a link? And also perhaps the inverse; in our interface, what should a link be? As an experiment, I tried to look very critically at a familiar and popular interface: Gmail. In the parts I would consider to be the everyday interface, you’d be hard-pressed to identify anything as a link. In fact, the only things I could find which actually are links are the main sidebar options (Inbox, Starred, etc.), and even those don’t present themselves as links. On the other hand (and recognizing the current code is a work in progress), consider our use of links in the patron search. We have links both for column sorting, and also a link on the row numbers. Neither of these currently do anything useful when right-clicking and opening in a new tab. The row number links could, I imagine, but the column header links make little sense in that context. The simplest argument, then, is that those shouldn’t be links, but that gets to the heart of what I am trying to say. We are taking something which is fundamentally a website concept (a link between pages) and applying it to an application, and we need to very careful that we don’t misapply a web-centric mindset to any areas where that thinking isn’t appropriate. Back to Gmail, in my experience, every link *within* an email opens in a new tab. This prevents you from losing your Gmail context. I think this is a very sensible behavior, and would even say it is the correct behavior for external links. In my opinion, we should do the same, at least by default. My sense, though, is that you were not really asking about external links which might exist in our content, but rather “internal” links (which I will define as a link to a new context in the staff client). These are trickier. To help our thinking, I wish to posit that on any given screen, we have both a context and a state. The URL always captures the context, and sometimes some aspects of the state, but we cannot expect it to always capture every aspect of the current state. Because of this fact, every time you switch contexts, you risk losing some state. Therefore, we should be very careful to offer any interface element, link or otherwise, which switches context without a clear indication to the user of that intention. To help illustrate the idea, I don’t feel the linked barcode in the “Items Out” table passes this test. It isn’t clear that that link is going to change my current context. It might not matter much in the patron context, since there isn’t much state to lose, but that won’t always be the case in every context. Also, why link on barcode? What is the analog in, say, a list of serial items attached to a unit? Instead of thinking of things as “links” and then trying to make one rule for a bunch of disparate things, I’d propose that we should have distinctive interface elements for which we can then define usage appropriate behaviors. Doing so would create a tremendous opportunity for improving the overall usability of the staff client as a whole. I could say more, but I’ve said a lot already. I’d love to hear reactions to what I’ve said so far (which I know is very uneven given the time and space limitations). Am I way
Re: [OPEN-ILS-GENERAL] staff client dev 2014-05-19 / feedback requests
On Wed, May 21, 2014 at 7:00 PM, Dan Wells d...@calvin.edu wrote: Hello Bill, Thanks for the update. I have some thoughts about both of your questions, but will focus on the link issue for now. I’m not quite sure how to answer because I feel like we’re not asking the right question. Rather than ask how links should behave, we might instead ask, what should be a link? And also perhaps the inverse; in our interface, what should a link be? As an experiment, I tried to look very critically at a familiar and popular interface: Gmail. In the parts I would consider to be the everyday interface, you’d be hard-pressed to identify anything as a link. In fact, the only things I could find which actually are links are the main sidebar options (Inbox, Starred, etc.), and even those don’t present themselves as links. On the other hand (and recognizing the current code is a work in progress), consider our use of links in the patron search. We have links both for column sorting, and also a link on the row numbers. Neither of these currently do anything useful when right-clicking and opening in a new tab. The row number links could, I imagine, but the column header links make little sense in that context. The simplest argument, then, is that those shouldn’t be links, but that gets to the heart of what I am trying to say. We are taking something which is fundamentally a website concept (a link between pages) and applying it to an application, and we need to very careful that we don’t misapply a web-centric mindset to any areas where that thinking isn’t appropriate. Back to Gmail, in my experience, every link **within** an email opens in a new tab. This prevents you from losing your Gmail context. I think this is a very sensible behavior, and would even say it is the correct behavior for external links. In my opinion, we should do the same, at least by default. My sense, though, is that you were not really asking about external links which might exist in our content, but rather “internal” links (which I will define as a link to a new context in the staff client). These are trickier. To help our thinking, I wish to posit that on any given screen, we have both a context and a state. The URL always captures the context, and sometimes some aspects of the state, but we cannot expect it to always capture every aspect of the current state. Because of this fact, every time you switch contexts, you risk losing some state. Therefore, we should be very careful to offer any interface element, link or otherwise, which switches context without a clear indication to the user of that intention. Agreed. To help illustrate the idea, I don’t feel the linked barcode in the “Items Out” table passes this test. It isn’t clear that that link is going to change my current context. It might not matter much in the patron context, since there isn’t much state to lose, but that won’t always be the case in every context. Agreed this is unclear. More below... Also, why link on barcode? What is the analog in, say, a list of serial items attached to a unit? Hmm, why not link on barcode? We should link on serial items, too, if a URL exists which uniquely represents the item. I'd like to see every occurrence of objects like copies, records, users, etc, .etc. which have a dedicated page of some sort presented as links so staff can easily ctrl-click to pull that information up in a new tab a la Wikipedia. Instead of thinking of things as “links” and then trying to make one rule for a bunch of disparate things, I’d propose that we should have distinctive interface elements for which we can then define usage appropriate behaviors. Doing so would create a tremendous opportunity for improving the overall usability of the staff client as a whole. Indeed, I didn't do a great job of explaining what types of link I was mainly referring to in my post. Here's a small brain dump to add some context. 4 general categories of link come to mind: 1. Links with href values which refer to pages within the same application. The a tags will have no target, which tells Angular the links should be activated as push-state URL swaps (no server page load). A typical example would be tab navigation links, whose behavior I think is pretty obvious, but I could also imagine bare-text links, which are non-obvious, referring to in-app resources as well. Such links should be designed to function when loaded directly from the server, but also benefit from being able to maintain state (via Angluar services) when navigating within the application. 2. Links with href values which refer to pages within the staff client as a whole, but to a different sub-application. These a tags have a target=_self value, which tells Angular to load them from the server and not as a push-state URL swap. As developers, we should make every attempt to ensure that these two types of links
Re: [OPEN-ILS-GENERAL] staff client dev 2014-05-19 / feedback requests
On Wed, May 21, 2014 at 5:47 PM, McCanna, Terran tmcca...@georgialibraries.org wrote: UI Planning: I looked through the items listed in Sprint #1 and the only interfaces I noticed missing were: Patron - Surveys (Will this not be added until the Local Admin sprint?) Right, practically everything under the Local and Server Admin menus will come with the Admin sprint. Workstation Admin items will be added as the relevant features are added (e.g. we already have the initial print config interface). Patron - Acquisition Requests (Will this not be added until the Acq sprint?) Yes, I left this for the ACQ sprint. I added a note to the Acq sprint about ensuring the link from the patron account UI was added. I've asked some of our staff that are more familiar with the other interfaces to take a look at what you have detailed so far for the other sprints. Thanks! -b -- Bill Erickson | Senior Software Developer | phone: 877-OPEN-ILS (673-6457) | email: ber...@esilibrary.com | web: http://esilibrary.com | Equinox Software, Inc. / The Open Source Experts
