Settings and activity
99 results found
-
5 votes
Jeremy Goldstein
supported this idea
·
-
5 votes
An error occurred while saving the comment Jeremy Goldstein
supported this idea
·
-
9 votes
An error occurred while saving the comment Jeremy Goldstein
commented
Having an actual id value and not just a row number feels like basic database design and would go a long ways towards preventing determiner related errors from occurring when rules may be deleted.
Jeremy Goldstein
supported this idea
·
-
8 votes
An error occurred while saving the comment Jeremy Goldstein
commented
As a consortia with a few hundred rules, this would be incredibly helpful to assist in managing the whole table.
Jeremy Goldstein
supported this idea
·
-
4 votesJeremy Goldstein
shared this idea
·
-
37 votes
The product team will review this idea for consideration for a future release.
An error occurred while saving the comment Jeremy Goldstein
commented
@Jennifer I'm almost certain the default setting would allow the current scenario to work as is. Presently holds are allowed on bibs with only orders attached, because it doesn't take orders into consideration at all...this is the identical scenario to having a bib with nothing attached.
It's only when items are attached that the loan rule determiner comes into play at present.
An error occurred while saving the comment Jeremy Goldstein
commented
We encounter this quite a bit in our system as well and it is a cause of problems for patrons and confusion for staff.
Jeremy Goldstein
supported this idea
·
-
14 votesJeremy Goldstein
supported this idea
·
-
3 votesJeremy Goldstein
supported this idea
·
-
6 votesJeremy Goldstein
supported this idea
·
-
15 votesJeremy Goldstein
supported this idea
·
-
8 votesJeremy Goldstein
supported this idea
·
-
21 votesJeremy Goldstein
supported this idea
·
-
12 votesJeremy Goldstein
supported this idea
·
-
9 votesJeremy Goldstein
shared this idea
·
-
14 votesJeremy Goldstein
shared this idea
·
-
26 votes
The product team will review this idea for consideration for a future release.
An error occurred while saving the comment Jeremy Goldstein
commented
I do seriously like the idea of a retro Millennium skin for the anniversary.
Jeremy Goldstein
supported this idea
·
-
3 votes
An error occurred while saving the comment Jeremy Goldstein
commented
So this is a weird way to do exactly this currently, but only for serial records with a paid status of d or f. So there is some pre-existing functionality that could be built on in theory.
-
5 votes
An error occurred while saving the comment Jeremy Goldstein
commented
I've run up against this issue with other systems as well and never entirely understood why the API was implemented in such a fashion. I vaguely recall from some old ticket we had that this was explained as a way for the system to inherit details from that login...such as the stat group...which of course is what we're trying to assign via the separate parameter so who needs the login. If a login absolutely must exist as part of the call, at least throw together some sort of default apiuser for it that can exist on the backend if it's not specified...but that still feels unnecessary.
Jeremy Goldstein
supported this idea
·
-
11 votesJeremy Goldstein
supported this idea
·
-
10 votesJeremy Goldstein
shared this idea
·
This is quite important information that we would love to see in item records for all sorts of statistical purposes. Just calculating cost per circ by fund alone would be a game changer.
My one big concern with it however, which would need to be addressed, is to make sure that items wouldn't have to become bound to accounting units, similar to orders and checkin records. Items must remain accessible to libraries beyond the accounting unit owner.