Right now when you use the Create Derivative Copy task you have to select a plug-in type (either Transformation Profile or Stream Handler) even in cases where you are not transforming anything - we create derivative copy representations that are exact copies of the preservation master representation with no transformations. I would like to have a 3rd radio button - something like "None" - added. Since we're not selecting any file formats and we are choosing "Copy other extensions" the system is doing what we need it to do and we think it's odd to have to choose a plugin type when it's not being used. Low priority, but worth mentioning I thought. Thanks!

For compliance purposes and as a lesson learned from SC 00560356, I suggest improving the documentation and configurability of passwords throughout subsystems of Rosetta installations.

I suggest creating and maintaining a KB article on how and where to change passwords for:
- System user "dps"
- System user "oracle"
- Oracle user "sys"
- default Rosetta user "admin1" (John Smith)
- Cantaloupe Image Server user "admin" (changeable by configuring ".../system.dir/thirdparty/tomcat/rosetta-webapps/cantaloupe.war/cantaloupe.properties")
- Solr user
- Rosetta console UI user

The passwords for Solr and the Rosetta console UI cannot be changed at the moment (Rosetta 5.5.0.0); I suggest considering changes to enable institutions to set their own passwords.

Furthermore, I suggest that ExLibris set up suitable infrastructure for exchanging passwords securely. GPG-encrypted mail or a public write-only (!) storage would be suitable candidates, SupportCase comments (that might be publicly readable) and encrypted mobile instant messaging services like Signal (that often involve personal accounts/devices) are certainly not.

Increasingly libraries and consortia are using counter / sushi to measure usage of digital and electronic resources across disparate parts of their holdings.

If holdings being held in Rosetta are to be valued by the broader institutions funding and maintaining those resources, we need to be able to report usage using the counter and sushi protocols (which ExLibris has already demonstrated knowledge of in their support in ALMA and 265 services).

Key features would be basic counter and sushi reporting; use of IP ranges and user groups already defined in Rosetta for reporting; and grouping or content by already defined sets and/or collections for reporting.

submitted on behalf of Michele Lindlar

Sometimes it's neccessary to update our cms metadata. if a librarian changes a record in the external cms-system, we want to update the record in rosetta too, but there's no task that works accordingly. we'd be really happy if there would be a task chain or a process that re-harvest existing cms-records.

We currently integrate two catalogue systems via SRU in Rosetta: Aleph and Pica. Both systems are integrated uni-directoinal, as in a Rosetta flag is not available in either cataloguing system. As we are integrating the union catalogues which are held by third parties, we are not at liberty of including any Rosetta-specific fields in the catalogue.

The initial CMS enrichment works without a problem. However, at times it becomes necessary to update the CMS information stored in Rosetta. This can be the case when either the catalogue was updated or when we have detected an error in our mapping.

While two tasks are available which suggest a working update - namely, "Re-Assign CMS" and "CMS Metadata Record Update" - these tasks will not re-harvest from the source CMS included in the SRU integration but will instead always pull from the physical MID copy already stored in the /metadata storage of Rosetta.
Actual re-harvesting is only possible by first manually deleting the MID record in the file storage and then re-harvesting.

ExL has provided us with a script which can be run across the file system. The script requires a list of CMS Ids first and then deletes the records from the storage. The script needs to be run by the administrator from the shell.

We do not consider the script solution sufficient. Instead, we require a functionality of re-enriching with updating CMS records from the integrated CMS system from within Rosetta.

Rosetta knows two CMS integration options: unidirectional and bi-directional. The bidirectional integration requires a Rosetta flag to be set in the CMS system. Via the flag, all Rosetta-relevant records from the CMS can be gathered and the metadata pool within Rosetta updated in bulk on a regular basis. However, institutions may be using a CMS for enrichment which belongs to a different / external institution, making the addition of a Rosetta-flag within the CMS system impossible.
This is where the unidirectional enrichment comes to play. The CMS is queried via SRU integration and records are pulled into Rosetta. The pre-requisite is that a CMS section is present within the ie.xml, containing a system name and identifier to automatically query the CMS. This works well exactly once - duirng the first enrichment of the IE from within Rosetta. While all required information to re-query the CMS is present within Rosetta, any re-enrichment attempts via Task Chains such as "Re-assign CMS" or via manual "remove" / "link" will not requery the CMS system but always pull the information from the rosetta-side shared metadata directoy containing the initial harvest. Not only is this behavior counter-intuitive, it also prohibits the update of CMS data for those institutions who do not have control over the source CMS they are enriching from.
Ex Libris has provided a script via which the re-enrichment of these records is possible. The script takes a list of CMS identifiers as an input parameter and returns newly harvested CMS records into the shared metadata folder. However, running the script requires shell access to the application servers and can therefore only be done by system administrators.
It seems that all the basic functionatily for re-enrichment is there, it's just not available in the UI. The users who typically conduct re-enrichment of CMS data, however, do not work via the shell, they work in the UI and expect the functionality to be included there.

Our idea proposed here is to make the re-enrichment mechamism avaiable via the script actionable via the UI. We urgently require this functionalilty as the experience of the past years has shown that CMS records DO change and that these changes are monitored by Rosetta staff users such as participating institutions in a consortia, who do not have sufficient rights to run shell scripts for updates.

We do not wish to have all of our institutional users in Rosetta, leaving that for administrators and publishers.

When a user has signed in successfully through SSO (in our case ADFS) we know that they are from our institution, so we should be able to do access rights rules based on this.

We are also able to pass through extra parameters through SAML to identify the type of user, and where they have come from, it would be great to be able to assign such users to basic user accounts so we can have granular access rights to IE's and Reps within Rosetta.

We at the BSB have different types of material to be displayed with the General IE Viewer (Version 5.4). We suggest to make the configuration of the General IE Viewer more flexible.

1. Configurable display of panes
In general it would be very useful to be able to configure the standard display of panes. For each the content structure pane and the descriptive metadata pane there should be three different modes of display:
Display as standard (the panes are displayed when the viewer is opened and can be closed if the viewer clicks on the grey area of the frame on the pane)
display on demand (the panes are not displayed when the viewer is opened and can be opened if the user user clicks on the grey area of the frame of the pane)
no display (one or both panes are not displayed and cannot be opened)

As the content structure may often contain confusing information like labels from the structmap set automatically by Rosetta it is necessary to be able to completely hide this pane from the user.

2. Configurable bars above the panes
As the information in the bars above the panes are also derived from the labels in the struct map and can therefore contain confusing information we suggest to allow that this information can be hidden as a configuration parameter

3. Configurable search field in content structure pane
As the search field can be confusing in terms what exactly is searched, i.e. it can be assumed that the displayed object is searched, it would be good, if there was a possibility to hide the search.

4. Allow Viewer Configuration in the Delivery Rules
As is it might be necessary to have different configurations for different types of IEs it seems useful to have the possibilty to set the configuration parameters in the corresponding delivery rules and not in one single standard configuration.