we are using the Rosetta-Aleph-Integration in both directions:
1. creating the CMS-record in Rosetta and
2. setting the Rosetta-flag in Aleph as well as updating the Aleph record with the URN created in Rosetta.
In the past there was only one target field for the URN and the assignCMS task with updateURNTask worked without problems.

Due to changes in the cataloging rules - we are using now the international RDA-rules - we have to deal now with different target fields in Aleph for the URN depending on the type of material: e-only e-books, digital reproductions of printed books, online versions of printed books, etc.

The target field is configurable in the Rosetta-Aleph-Sync, but this is not sufficient with the new situation. We want to be able to configure profiles for the updateURNTask depending on the material type: to specify the target MARC-field, to populate subfields with fixed information depending on the material type and with the URN.

(It is not possible at the moment to update the URN in a subfield of an already existing field, a new field is created (case 00510676)).

Astrid Schoger on behalf of the Bavarian State Library

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.

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.

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.

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!

we are using access restriction on file level for some of our items. For PM REP we can assign this automatically via task chain, but this approach does not work for AD REP (tasks cannot be used). Unfortunately when there are files in PM REP with access restriction, this access restriction is not inherited/copied to AD REP during the enrichment process. So we need to go to AD REP and manually add/change the AR for the files which need to have it.
It would be great if we have either have a task chain which would copy the file restrictions from PM or MM REP to AD rep OR enrichment routine would be able to do this (another task in enrichment?)
cheers

Since the organization levels in Rosetta are limited to consortium and institution, we often have to ingest objects of different origin an type into a single institution. This poses problems as for certain sources you want to activate more or less extraction and/or file extension rules that for other sources. Currently we have to leave the more permissive rules off, make the SIPs fail and end up in the TA, enable the permissive rules, rerun the SIPs and finally disable the permissive rules.

This is a pain and requires many manual interventions that are error-prone and can influence other ingests that happen at the same time.

Rules can be selected based on Producer name, but it is far more work to set up and maintain a number of Producers that it is to create multiple material flows. We therefore would like to suggest to add an extra selection parameter for selecting a number of material flows.

We are looking at supporting the ability to add a new format to our Ingest tool, in conjunction with this we would like that to trigger some type of API call to Rosetta and add the file format as an allowed format as well.

In Rosetta you can add a new file extension in the Submission Format area of the UI. We have provided the option to add a new format in our Ingest tool, So once they do this, we would like this to trigger an some type of API call to Rosetta and add the new file extension as an allowed file extension without having to go into the UI and add the file extension manually in the Submission Format location.