Settings and activity
96 results found
-
3 votes
Jeremy Goldstein
shared this idea
·
-
36 votes
The product team will review this idea for consideration for a future release.
An error occurred while saving the comment 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
·
-
10 votesJeremy Goldstein
supported this idea
·
-
3 votesJeremy Goldstein
supported this idea
·
-
6 votesJeremy Goldstein
supported this idea
·
-
13 votesJeremy Goldstein
supported this idea
·
-
8 votesJeremy Goldstein
supported this idea
·
-
14 votesJeremy Goldstein
supported this idea
·
-
7 votesJeremy Goldstein
supported this idea
·
-
7 votesJeremy Goldstein
shared this idea
·
-
9 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
·
-
8 votesJeremy Goldstein
supported this idea
·
-
7 votesJeremy Goldstein
shared this idea
·
-
6 votesJeremy Goldstein
shared this idea
·
-
5 votesJeremy Goldstein
shared this idea
·
-
8 votes
An error occurred while saving the comment Jeremy Goldstein
commented
Are you interested in item level details or title?
By item if you can use the year to date circ fields (we actually can't because they're based on fiscal year instead of calendar year in our system) you can search for items with a count > some reasonably high number to provide you with a limited list and then sort the results on that field.
By title, none of the tools within Sierra itself allow for summing up the counts from attached items so yeah you'd have to export the data to excel or rely on SQL or Decision Center. Maybe this is something that would be achievable in Vega Reports to come.
-
12 votesJeremy Goldstein
supported this idea
·
@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.