Simon Hunt
My feedback
12 results found
-
167 votes
Hi all,
This is planned to be handled in the Primo Next Discovery Experience User Interface.
More details on the new interface planning can be found here -
Best regards,
Yael.
Simon Hunt
supported this idea
·
-
146 votesSimon Hunt
supported this idea
·
-
350 votes
Hi all,
This is to update that we plan to develop this option in the future. It is not in the current roadmap for this year, and we will update as soon as we have more details about the development planning.
Best regards,
Yael.
Simon Hunt
supported this idea
·
-
163 votesSimon Hunt
supported this idea
·
-
196 votes
An error occurred while saving the comment Simon Hunt
supported this idea
·
-
55 votesSimon Hunt
supported this idea
·
An error occurred while saving the comment Simon Hunt
commented
Holdings records in suppressed locations should be automatically tagged as suppressed so these values are indicated in publishing profiles and Analytics. This way, suppression indicators would function the same whether they are being published to Primo or another source.
The presence of the "suppressed record" icon makes this even more confusing, since you can't tell if an individual record is tagged suppressed unless you open it in the MD Editor and look in the Tools menu (or run a report in Analytics).
-
45 votesSimon Hunt
supported this idea
·
-
284 votes
We are considering incorporating the idea and effect both templates and rules editing permission
Simon Hunt
supported this idea
·
An error occurred while saving the comment Simon Hunt
commented
I would expand that request to merge and indication rules as well. All three types can be used in import profiles, and it should be possible to write-protect individual rules.
-
13 votes
-
128 votesSimon Hunt
supported this idea
·
-
260 votes
Changing the existing re-sequencing task would impact all libraries, whether interested in this change or not - but we will look into adding a new re-sequencing task that will handle all fields, so libraries will have a choice on which re-sequencing behavior they want to apply.
Simon Hunt
supported this idea
·
An error occurred while saving the comment Simon Hunt
commented
What appears to be happening - both with a normalization job and when a record is merged while importing - is that "new" fields (those affected by the normalization, or fields being added to a record via import merge) are placed below the "old" or unaffected fields in the record.
For example, if your merge rules preserve the old 597 fields but replace all other 5XX fields, the final version of the bibliographic record displays the 597 field first.
In AACR2, there was a prescribed order of note fields that catalogers applied, including how to order notes in repeated 500 fields. RDA rules simply specify that note fields should be arranged in numeric order.
So, the placement of new/normalized fields at the bottom of the range violates both cataloging standards.
-
145 votesSimon Hunt
shared this idea
·
This idea is from three years ago, but we have just stumbled on this same problem. We would also like to hide a service when there exists an electronic resource in the NZ.