The IE delivery rule list contains the following fields:
- active
- name
- description
- creation date
- modification date
- commands view, edit and delete

the dates and commands take up half of the screen, not leaving much space for the name and description. Both these fields are rarely descriptive enough to fully understand the implication of the rule and we have had several occasions where an operator added a rule, changed the order or modified a rule without understanding its impact. Resulting in wrong viewers being used or even files not viewable at all.

We think the list can be improved by removing the date fields, which - at east for us - have little value and condense the action columns. The newly gained column space could be used to display the information from the input parameters in a structured way. I believe that would improve the insight on the impact of a rule right from the list.

We have similar thoughts about the SIP routing rules list. Possibly it could be a suggestion that applies to all rules lists in Rosetta and/or all order-dependent lists.

Currently the material flow combines amongst others, a restrictive list of access rights, retention policies and metadata fields. These operate as restrictions on which access rights, retention policies and metadata fields can be supplied by the submitter. We suggest to make it possible to opt-out on any of these restrictions. That would benefit customers that have automated submission workflows outside of Rosetta where the metadata is already checked for validity and fully under control. It would also help solving human errors when new ARs are created, but forgotten to be added to their respective material flows. If it not possible to opt-out, it would be nice to have 'I do not care' or 'Anything' entries in the access right and retention policy list that do basically the same. For us personally, relaxing the access right restrictions would be the biggest win.

As part of the CSV/Zip deposit method, Rosetta verifies that all files in the CSV are in the Zip. It does not, however, check if all files in the Zip are listed in the CSV.

We recently discovered that for 5 of our IEs, the CSVs were incomplete and missing a few thousand files. Even though the Zips contained more files, the deposits went through successfully and the files not listed in the CSVs were not preserved.

I propose that as part of the deposit process, Rosetta checks the number of files in both the CSV and Zip and verify that they match.

Currently, when you export a file, REP or IE from Rosetta you will get an error if there is a problem with exporting the file. However, we have had at least one instance where the file seemed to export without issue but the file couldn't be opened (it was corrupt) and we were able to see that the checksum of the file did not match the checksum stored in Rosetta for that file. This helped us diagnose an issue with the way our storage layer was delivering the file. If Rosetta included an optional checksum calculation on export (the type of checksum could be specified in the export job parameters) this would make the exported files more trustworthy.

Please consider adding this feature.

I would like an easier was to see the size of an IE/REP both in number of files and storage size. Right now, the only way I can see to get the size of the IE in terms of storage is to search at the file level for all files in that IE and then export the results to CSV and add up the size column (in bytes). Same goes for number of files except you can also see them when you’re in the Meditor in the metadata for the Rep. It doesn't seem like adding at least the number of files per REP as an option for a column in the results screen would be that difficult. Thanks!

Save Set information for repeated Processes

When setting up a recurring Process that uses a Set with different values each time, Rosetta does not keep a record of the Set values each time it is generated, so that you cannot Rerun the previous Process instances in History. We propose a change to the recording of Set metadata so that each time a Set is used, its values are stored, thus allowing a Historical Process to be rerun at a later date. An example is rolling fixity checks, wherein a different range of SIPs are checked each day using the same Process. By saving the SIP range each time, any Process instance in the History can be rerun if necessary at a later date.

I know I can add file-level descriptive metadata (DC) individually to a file in the back office or use the web services to do that for many files at once, but I want to be able to add metadata to a batch of files using a process in the back office. In my case, I would be adding the same DC record to a large group of files but I can also see the need to have a different DC per file so I would send Rosetta a bunch of DC XML files - one for each file PID, similar to how you do the updateMetadata job at the IE-level now. Expanding the Update Metadata Job to update file-level metadata would also be a welcome enhancement.