Settings and activity
92 results found
-
14 votes
Jeremy Goldstein
supported this idea
·
-
9 votesJeremy Goldstein
shared this idea
·
-
15 votesJeremy Goldstein
shared this idea
·
-
38 votes
An error occurred while saving the comment Jeremy Goldstein
supported this idea
·
-
6 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.
-
11 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
·
-
25 votesJeremy Goldstein
supported this idea
·
-
11 votesJeremy Goldstein
shared this idea
·
-
21 votesJeremy Goldstein
shared this idea
·
An error occurred while saving the comment Jeremy Goldstein
commented
These two fields can be incorporated into searches performed within create lists but are not available among the fields that can be exported. Best title normalized is particularly helpful for data brought into a spreadsheet as the removal of special characters and diacritics can greatly improving sorts and searching.
These fields are available via SQL, where I make frequent use of them, but for most of our users Create Lists is the only option for extracting data from the system.
-
8 votesJeremy Goldstein
shared this idea
·
-
11 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.
-
13 votesJeremy Goldstein
supported this idea
·
-
6 votesJeremy Goldstein
supported this idea
·
-
20 votes
An error occurred while saving the comment Jeremy Goldstein
commented
Repost of idea https://ideas.iii.com/forums/951745/suggestions/48310874, which aged out of the system. This idea is still very important to us.
Jeremy Goldstein
shared this idea
·
An error occurred while saving the comment Jeremy Goldstein
commented
We have had a number of instances recently in which a vendor has requested SQL access in order for us to utilize there services. We are hesitant to allow for that (and have policies against it) due to the quantity of secure data that would also provide access to.
What we need is a way to provide lesser SQL access to particular users to allow them to tap into only the relevant tables (bibs & items for some. Circ_trans and patrons for others).
Beyond the vendor scenario it would also be fantastic to provide limited access to more of our library staff. As a consortia, we have many of our member libraries who could truly benefit from being able to work with their record data but as long as doing so also provides access to things like staff account usernames and the limit network access table we can't open that access up to more of our own users.
-
19 votesJeremy Goldstein
supported this idea
·
An error occurred while saving the comment Jeremy Goldstein
commented
This idea is essentially to address a design flaw that goes all the way back to the migration from Millennium to Sierra. The record view property setting was originally designed for the context of Millennium, where there would be entirely separate logins for circ, cataloging, acquisitions, etc...and adjusting the setting would only impact a single search function. But in Sierra when a single user may have multiple workflows available to them that breaks.
When a Sierra SDA login is first created the system utilizes individual summary view properties for the various search functions. By default in cataloging if you open up the summary view of a record you see item records, in search/holds you see holds, in place orders you see orders and in serials checkin you see checkin records.
If you opt to change that setting however from the record view properties menu (say to change this to view all) it can impact all 4 search functions. It would be better to split this menu out, so that the setting for each of the search functions can be selected individually.
An error occurred while saving the comment Jeremy Goldstein
commented
When a Sierra SDA login is first created the system utilizes individual summary view properties for the various search functions. By default in cataloging if you open up the summary view of a record you see item records, in search/holds you see holds, in place orders you see orders and in serials checkin you see checkin records.
If you opt to change that setting however from the record view properties menu (say to change this to view all) it can impact all 4 search functions. It would be better to split this menu out, so that the setting for each of the search functions can be selected invividually.
-
26 votes
An error occurred while saving the comment Jeremy Goldstein
commented
I like this idea for many of the templates but not universally. Spine labels in particular need to be something that end users can work with on the client side of things and shouldn't be walled off to admins, though for most other use cases I can see this proposal working decently well.
Jeremy Goldstein
supported this idea
·
-
14 votesJeremy Goldstein
shared this idea
·
-
40 votesJeremy Goldstein
supported this idea
·
-
9 votes
An error occurred while saving the comment Jeremy Goldstein
commented
I can absolutely see the value in writing a script to make these sorts of adjustments when necessary.
Jeremy Goldstein
supported this idea
·
-
13 votesJeremy Goldstein
supported this idea
·
I do seriously like the idea of a retro Millennium skin for the anniversary.