143 results found

1. Ability to integrate our Ingest tool with Rosetta

   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.

   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… more

   1 vote

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Environment & Infrastructure  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Support the ability for Rosetta to request IEs in batches

   We would like Rosetta to work more efficiently when the storage layer is tape based, particularly for exports. Could Rosetta request IEs in batches from the storage layer. when exporting large collections from tape a file is retrieved from tape one at a time.

   11 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Data Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Support Oracle Internet Directory

   Support OID as an alternative to tnsnames.ora in Oracle Installation. OID is the DNS like service for Oracle that we use heavily in our institution.

   1 vote

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Environment & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Recalculate fixity SHA2 and insert into Rosetta

   We have around 22,000,000 files that we would like to recalculate a new fixity hash, but this time it would be SHA256. We need a good way of getting this fixity back into Rosetta. We would like to store it along with the SHA1 value we previously generated. We are aware that the SHA1 fixity is located in xml clob data in the hdemetadata table. We are wondering if there is another location for this SHA1 value in another table.

   2 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   3 comments  ·  Data Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Make IE Viewer share button configurable

   The share button in the IE Viewer currently always shows the browser URL. Often the IE has an OID or some persistent URL that is preferred over the transient viewer URL. Rosetta should allow the URL that is displayed to be configurable. Preferably with an XSLT per institution similar to the IE metadata XSLT.

   It is also desirable to allow for more than 1 URL in the share window. That would allow to add URLs for standalone vs embedded viewers, thumbnail view, CMS metadata view, etc.

   4 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   3 comments  ·  Publishing & Delivery  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Bitstream information in Bitstreams Tab

   Researchers often use zip or tar files in order to upload large amounts of research data in various formats. Bytestream extraction is a useful tool for analyzing the content of these container files. The resulting bitstream information is written in the METS and displayed in the BitStreams Tab in the Web Editor. The information includes BS ID, file name, file original path, extension, mime type and format ID (if successfully identified).

   We would like to suggest the following improvements for the BitStreams Tab and the bitstream information in general:

   1) Include Bitstream size. The relevant values can be found in the table “HDBITSTREAMREF” in the field “FILESIZEBYTES”.

   2) Display bitstreams in order of path/filename: the bitstream list should reflect the order of the files in the zip or tar file. Currently they are displayed in random order.

   3) Make bitstream information searchable

   Researchers often use zip or tar files in order to upload large amounts of research data in various formats. Bytestream extraction is a useful tool for analyzing the content of these container files. The resulting bitstream information is written in the METS and displayed in the BitStreams Tab in the Web Editor. The information includes BS ID, file name, file original path, extension, mime type and format ID (if successfully identified).

   We would like to suggest the following improvements for the BitStreams Tab and the bitstream information in general:

   1) Include Bitstream size. The relevant values can be found in… more

   •  

   16 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Data Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. untangle format identification/validation/MDextraction

   In the course of the discussion on the "File Extension Mismatch - Change Notice" posted on BaseCamp by Opher Kutner (ExL), I noticed that some aspects of file identification/validation/MDextraction in Rosetta need improvement. What got me thinking was the statement that format identification was done by the extractor, which isn't the case. Instead, the actual behaviour is that the MdExtractionPlugin also does the format validation, while the format identification is run separately in DROID. However, the job of extractors is neither format identification nor format validation. Instead, it's metadata extraction only. Usually, a preservation repository can't even know which extractor to apply without having successfully completed identification and validation before. The fact that format validation and metadata extraction are run in the same step introduces problems that could be avoided by dividing them up in separate steps.

   From my point of view, the correct workflow would be as follows:
   1. Run format identification against FL/PRONOM/YourFormatRegistryHere, get list of recognized formats (sorted descending by certainty of identification)
   2. Run format validation routine for elements from the list from step 1, only treat format IDs that were identified with a identification certainty above a certain percentage.
   2.a. If two elements from the list have the same identification probability, then both validators need to be executed. Human intervention is necessary to decide which format should be used. However, this should never occur, because PRONOM maintains a distinct prioritisation of format signatures.
   2.b. If validation successful, continue with 3.
   2.c. If validation fails, go back to 2. and try next element in list.
   2.d. If validation fails for all elements of the list, move file to TA.
   3. Choose the correct MD extractor, extract MD.

   This leaves us with the following classes of errors:
   1. Format identification fails, because:
   1.a. No recognized formats at all (empty list). This might be caused due to a missing signature in the format registry.
   1.b. No formats with sufficient certainty identified.
   1.c. One format identified with sufficient certainty, but file extension doesn't match. This might be either caused by:
   1.c.1. An extension that is actually wrong for that file type, and needs to be corrected.
   1.c.2. A wrong signature that misidentifies a file. (We had that problem in an older FL version, where TIFFs were misidentified as .NEFs due to an overly general signature for the NEF format.)
   1.d. Multiple formats identified with sufficient certainty, but no file extension matches.
   1.e. Internal error / Format identification plugin crashes.
   2. Format validation fails, because:
   2.a. If exactly one format was identified with sufficient certainty:
   2.a.1. One validator called, file validation doesn't return successfully.
   2.b. If multiple formats were identified with sufficient certainty:
   2.b.1. Validators for all detected formats were called, none returned successfully. This should never occur.
   2.c. Internal error / Validator crashes.
   3. MD extraction fails, because:
   3.a. No MD extractor plugin for that format available.
   3.b. No significant properties / DNX mapping configured for that plugin/format combination at all.
   3.c. File doesn't contain any of the significant properties that are configured for that plugin/format combination.
   3.d. Internal error / Format extractor plugin crashes.
   ELSE One format identified with sufficient certainty, no file extension mismatch, NO ERROR.

   The most important part here is that a format is only identified with certainty if a) the signature, MIMEtype and file extension given in the format registry match what is found in the actual file and b) if the validation has finished successfully. Only if both conditions are matched, we can be sure about the result of our format identification. I want to illustrate this with the example of the TIF format. In cases where one or both of the aforementioned conditions are not met, we DON'T have an invalid TIFF. What we DO have is something that looks suspiciously like a TIFF, but doesn't comply with the format specification, and therefore is NOT a TIFF. In other words: a format is ONLY successfully identified if the identification result is confirmed by the validation result.

   So, if we assume that the changes suggested above are implemented, the whole File Extension Mismatch Handling issue would become a lot easier. Every file that fails one of the stages ends up in TA and, ideally, will be returned to the producer to be repaired (or at least the producer will be notified about 1. the file being rejected 2. the reason for that including error message 3. the necessity to repair the file and re-ingest it). Alternatively, the TA user could run a repair operation on their own, but in the majority of the cases, the file that caused the error will have to be modified until the mismatch doesn't occur any more. This usually requires human intervention and analysis; just treating the error with a rule and ignoring it doesn't solve the underlying problem. As these underlying problems are usually a risk for the data in the repository, ignoring them is not an option.

   The consequences are that:
   - unknown formats can't be moved to permanent (and, as outlined, they shouldn't, because knowledge of the format is strict requirement for risk analysis).
   - format IDs can't be manually assigned to files at all, because that equals ignoring the issue instead and postponing the solution to the future, hoping that "someone will probably find time to do it then" (hint: they won't), thus effectively ignoring it.
   - the structure of plugin types in Rosetta needs to be refined, now strictly separating plugins for identification, validation and MD extraction, and also separating plugins by their intended format use. This probably means that existing plugins will need to be modified.
   - for cases where the files can't be returned to the producer and the repair operations have to be done by Rosetta staff:
   - a new plugin type "RepairPlugin" could be introduced to run very specific repair operations from within the TA workbench. The current manual approach is extremely cumbersome and doesn't scale at all.
   - repair operations in the TA workbench will need to support a higher level of automation to a) classify/group files not only by their IE but also by TypeOfError/numberOfErrors/ingestDate/anythingElseThatMightBeUseful b) run repair operations on all files from the same group or c) initiate repairs via an API (get errorMessages, get broken files from same group, repair outside of Rosetta, replace broken files, NOT using insecure ImportDescriptor.csv files). Also see these public SupportCases in SalesForce:
   - 00128163 bulk file replace in TA Rosetta 4.0.1.1
   - 00340712 enhance TA file replace assistant Rosetta 5.0.1.1
   - MD extractors are no longer assigned to Classification Groups (at least not exclusively). Instead, MD extractors should also be assignable to single format IDs. For practical reasons, formats could inherit their MD extractor setting from their Classification Group to set sensible defaults for all formats as long as no format-specific MD extractor is configured.

   In the course of the discussion on the "File Extension Mismatch - Change Notice" posted on BaseCamp by Opher Kutner (ExL), I noticed that some aspects of file identification/validation/MDextraction in Rosetta need improvement. What got me thinking was the statement that format identification was done by the extractor, which isn't the case. Instead, the actual behaviour is that the MdExtractionPlugin also does the format validation, while the format identification is run separately in DROID. However, the job of extractors is neither format identification nor format validation. Instead, it's metadata extraction only. Usually, a preservation repository can't even know which extractor… more

   7 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   5 comments  ·  Preservation & Format Library  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Allow institutional parameters for (custom) plugins

   In a consortial landscape a plugin may be used by several institutions. However, each institution may need to use different parameters for a shared plugin.

   To give examples, consider these two business cases:
   (1) A plugin utililzes proprietary 3rd party software that is licenced per institution. In such case we must ensure that only the institutions that actually pay the licence fee have access to the functionality. The license key would have to be configured per institution.
   (2) A PDF migration plugin can take different input parameters which determine the output format to be created (e.g. to PDF/A-1b vs. PDF/A-2b). An institution will want to use these input criteria when defining the mirgration process as part of preservation action from within the institution itself.

   While in the case of processes parameters can currently be defined within an institution when scheduling the process (e.g., for fixity task which checksum algorithm should be used), parameters of plugins can currently not be passed to the institutional level. We would like to see this change in order to use plugins in a more flexible and institutional-friendly way. Currently there is no information available if and how this can be achieved for custom plugins. It might also make sense in the case of some bundled plugins, e.g., if an institution would like to use a different DROID max byte scan config than another one.

   In a consortial landscape a plugin may be used by several institutions. However, each institution may need to use different parameters for a shared plugin.

   To give examples, consider these two business cases:
   (1) A plugin utililzes proprietary 3rd party software that is licenced per institution. In such case we must ensure that only the institutions that actually pay the licence fee have access to the functionality. The license key would have to be configured per institution.
   (2) A PDF migration plugin can take different input parameters which determine the output format to be created (e.g. to PDF/A-1b vs. PDF/A-2b).… more

   5 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  APIs & Plug-ins  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Take account of the METS mimetype attribute during file ingest

   The METS standard has a mimetype attribute on files "<file MIMETYPE="application/pdf" ... /> but this information is currently ignored by Rosetta during the file-type identification process on ingest.

   Mimetye should be at least as reliable as file extensions (because mimetype is a standard, is actively maintained and widely use by a good portion of software for identifying file types).

   In particular, recognising mimetypes is likely to greatly increase the ease of ingest of content from internet-facing content management systems where it is very widely used

   See also https://tools.ietf.org/html/rfc6838

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Ingest  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. encrypt all update channels

    After experiencing some problems with Rosetta's Format Library update mechanism (see SC 00423700 "error while updating Format Library [Rosetta 5.1.0.2]", handled by Paul), we got thinking about Rosetta updates in general. Currently, all updates are downloaded through an unencrypted connection. This includes:
    - Rosetta updates (major, minor, service packs, hotfixes) and their checksum files (!)
    - Oracle updates and their checksum files
    - PDS updates (presumably)
    - Format Library updates
    Due to this, there's no way to verify authenticity of ExLibris' servers and the integrity of the update packages/the checksums. All information that are downloaded from ExLibris' servers must be seen as tainted and cannot be trusted, because the transmission is unguarded. Even though ExLibris provides checksums for some (all?) of the updates provided, verifying that information against the calculated fixity from the update packages will not provide any additional security, as both the patches and the checksums could be tampered with in a man-in-the-middle attack. This contradicts current best practices in IT security and is considered a risk for the integrity of the repository software and data. Also, if I understand the comment from SC 00423700 correctly, the current FTP password for Format Library updates is hardcoded into Rosetta when it really shouldn't be.

    A possible update scenario for major/minor/servicepack updates could look as follows: on Rosetta installation, customers provide ExLibris with a PublicKey specific to that Rosetta installation. To reduce administrative overhead, several/all servers of the same multi server environment could share the same key. That key is added to the ExLibris update servers' list of authorized keys, thus allowing the customers' servers to connect. During the update, the "util sp" command queries the user for the key passphrase and connects to ExLibris' update servers via SFTP to download the patch packets and fixity information. The fixity information is then compared against the calculated fixity of the patches downloaded previously.

    A possible update scenario for hotfixes could look as follows: users manually connect to the update server from the Rosetta server CLI using the SSH key. The user then downloads and validates the patch packets and fixity information. Alternatively, the update procedure is unified with the process used for all other updates (btw, is there any technical requirements this hasn't already happened?) and the procedure described above is used.

    Updates for PDS and Oracle could be distributed in a way similar to the one described in the hotfixes paragraph.

    We've noticed that the first step on improving update security is already done by providing Format Library updates via SFTP (set General Parameter "usesftp" to "true"). However, this is foiled by Rosetta checking for FL updates via plain unencrypted FTP on every reload of the "Home => Preservation => Manage Format Library Version" page. Apparently, that step fails if "usesftp" is set to "true" in Rosetta 5.1.x.

    Please keep in mind that publishing and enforcing (!) a policy against short keylengths/weak crypto algorithms/weak kex algorithms is highly recommended when using SFTP/SCP.

    After experiencing some problems with Rosetta's Format Library update mechanism (see SC 00423700 "error while updating Format Library [Rosetta 5.1.0.2]", handled by Paul), we got thinking about Rosetta updates in general. Currently, all updates are downloaded through an unencrypted connection. This includes:
    - Rosetta updates (major, minor, service packs, hotfixes) and their checksum files (!)
    - Oracle updates and their checksum files
    - PDS updates (presumably)
    - Format Library updates
    Due to this, there's no way to verify authenticity of ExLibris' servers and the integrity of the update packages/the checksums. All information that are downloaded from ExLibris' servers must be… more

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. view only- user who cannot break anything

    For error-detection and workflow documentation it is sometimes necessary to be able to view all configurations in Rosetta - even all in the Administration area.
    But not all users should be able to edit configuration elements in Rosetta, especially not in the Administration Area.
    In our (ZBW/Germany) opinion, a view-only-user would be very handy. This person would be able to see all the configuration details and the view-option would be available to her/him, but not the edit-button.
    She/he would not be able to break anything, but would be able to see all the details needed for documentation or other purposes.
    This is escpecially important as sometimes configuration elements seem "to change themselves" when more than one tab in the browser is opened, even if only the view-option is selected.
    Thank you

    For error-detection and workflow documentation it is sometimes necessary to be able to view all configurations in Rosetta - even all in the Administration area.
    But not all users should be able to edit configuration elements in Rosetta, especially not in the Administration Area.
    In our (ZBW/Germany) opinion, a view-only-user would be very handy. This person would be able to see all the configuration details and the view-option would be available to her/him, but not the edit-button.
    She/he would not be able to break anything, but would be able to see all the details needed for documentation or other purposes.… more

    25 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  User Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. provide Rosetta developer previews

    ExLibris' current mode of releasing new Rosetta versions is to announce a rough time slot ("April this year") for that new version/minor-release/servicepack/hotfix, release it and deliver a list of changes along with the new release. Up until the actual release, ExLibris will only give a very general roadmap of the planned changes. While this is an easy approach for ExLibris, it's hard for the customers to prepare for the release. Therefore, I propose for ExLibris to provide pre-release versions of Rosetta in order to enable developers to adapt their software (i.e. Submission Applications) to new features, changed API behaviour etc. These beta releases could also be used to gather customer feedback on the changes and improve features before the final release, just like it has been a best practice throughout the whole industry for many years now.

    If, for any reason, the suggested developer preview releases are not feasible, I suggest that ExLibris at least releases their interface documentation for new APIs in order to enable developers to begin with their work prior to the actual release. API interfaces have to be specified very early in the design process, so they should be available early on. Developers could mock answers and write their routines before the release, and would only have to do some final tests when the actual working API becomes available.

    From my point of view, both ExLibris and the community of customers would benefit from this approach.

    In my opinion, the following prerequisites need to be fulfilled to implement this idea and reap the full benefits:
    - smaller & more frequent patches, massively simplified/automated install process to enable fast on-site implementation
    - rollback over multiple versions including DB schema (In test/dev/staging environments, the Rosetta install script could even take care of backing up the Oracle database using SSH and rman.)
    - detailed change information: What new changes does the beta version contain? Which changes are in alpha/beta/release-candidate status? This includes online documentation of in-development features.
    - detailed compatibility information (Which version can be installed on top of which other version? Which 3rd party tool versions are needed? Etc.)
    - means of communicating development feedback that is separate from the "usual" support cases, so operational content doesn't get mixed up with development issue handling

    ExLibris' current mode of releasing new Rosetta versions is to announce a rough time slot ("April this year") for that new version/minor-release/servicepack/hotfix, release it and deliver a list of changes along with the new release. Up until the actual release, ExLibris will only give a very general roadmap of the planned changes. While this is an easy approach for ExLibris, it's hard for the customers to prepare for the release. Therefore, I propose for ExLibris to provide pre-release versions of Rosetta in order to enable developers to adapt their software (i.e. Submission Applications) to new features, changed API behaviour etc.… more

    13 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Make Standard Upload procedure for 3A configurable (Applet vs. manual upload)

    When adding representations via the 3A workbench, the default procedure is the applet upload. Due to security settings, the applet may not be available in some environments. In this case, the user has to click the "Load the files manually" link located on the left to then switch to the manual upload procedure, which works fine.
    To avoid these extra steps it would be nice to set the default upload procedure (applet or manual) for 3A workflows via a general parameter.

    2 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Ingest  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. In Material Flows: remove option to "automatically extract compressed files" when the Content Structure is changed to METS

    The material flow configuration includes the default option to "automatically extract compressed files". This option works in all workflows except METS content structure work flows, as extracting compressed files leads to mismatches in the METS struct map.
    Material flow configuration screens should blend out the extraction option for METS content structure or make the user aware of a faulty configuration upon saving such a combination.

    2 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    4 comments  ·  Ingest  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. relative paths in IE XML / Storage Migration

    Rosetta 5.2 has brought a new Storage Migration feature that enables institutions to restructure their permanent storage to fit changing requirements. However, the documentation currently warns that "Disconnecting legacy storage is not recommended as it may prevent the possibility of reverting to a previous IE version." (https://knowledge.exlibrisgroup.com/Rosetta/Product_Documentation/Version_5.2, Preservation Guide, page 185). As far as I can see, this limitation is due to the use of absolute paths in the IE XML files. The paths in older versions of these files cannot be updated without forging provenance information, which, of course, isn't an alternative. However, updating these paths would be the prerequisite for reverting to a previous IE version.

    The documentation isn't clear about Rosetta's behaviour concerning older IE versions. These are the scenarios that I see:
    - Rosetta might COPY older IE versions to a new storage to have the complete history stored on the new storage. The original copy on the legacy storage is kept to preserve Rosetta functionality concering version recovery.
    - Rosetta might MOVE older IE versions to a new storage to have the complete history stored on the new storage. Reverting to older versions would not be possible anymore, but the legacy storage would be cleared of all files and could be removed. The complete provenance information would be kept in older versions of the IE XML, but with some invalid file paths.
    - Rosetta might KEEP older IE versions on the legacy storage and write only new information to the new storage. Reverting to older IE versions would be possible, but the legacy storage could never ever be removed. You couldn't even clean up the mount points without losing access to older versions.

    From my point of view, a possible way to go would be to change Rosetta's behaviour concerning file paths in the IE XML. Currently, absolute paths are used to point from the IE XML to the payload files/master images. However, using relative paths instead would make more sense here, because (at least on our storage. Comments?) IE XML files and payload files are always kept closely together anyway, so path complexity could be removed. Also, storage migrations would not make a path rewrite necessary, because the files can be addressed by the same relative path. For older IEs, that would mean that only versions created before the first storage migration cannot be reverted to. All subsequent versions would contain relative paths and could potentially be addressed even after a storage migration. For newer IEs (ingested after change to relative paths), that would mean that all versions can be addressed, even after storage migrations.

    As this idea is somewhat storage specific (depending on storage layout, storage plugins etc.), I'd appreciate comments from other customers that see possible caveats. Context about SLUB's storage layout and our plans to redesign the storage can be found in the public SupportCase 00345262 "migrating permanent storage to new path [Rosetta 5.0.1.1]".

    Rosetta 5.2 has brought a new Storage Migration feature that enables institutions to restructure their permanent storage to fit changing requirements. However, the documentation currently warns that "Disconnecting legacy storage is not recommended as it may prevent the possibility of reverting to a previous IE version." (https://knowledge.exlibrisgroup.com/Rosetta/Product_Documentation/Version_5.2, Preservation Guide, page 185). As far as I can see, this limitation is due to the use of absolute paths in the IE XML files. The paths in older versions of these files cannot be updated without forging provenance information, which, of course, isn't an alternative. However, updating these paths would… more

    12 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Preservation & Format Library  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Read-only user

    As we've begun bringing more users into Rosetta we've seen the need for a different type of user, who could basically do these things:
    *view/download IEs/files
    *view the collection tree

    But should not be able to:
    *see/modify processes.
    *delete IEs or purge the recycle bin

    We checked using dummy accounts with 'Viewer/Editor - View' and 'Approver/Assessor/Arranger - View' but neither of these can see the collection tree, either from the data management menu or from the search screen. So, we'd like something similar Viewer-Editor-View but with access to the collection tree.

    10 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  User Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Allow Retention Policy to not delete automatically

    Besides of having the option to delete or delete permanently, a retention policy should also allow not to delete at all. Many institutions want to assign a retention period to their objects, but do not want to delete the IEs when the retention period is over. Instead they expect to receive a report where they can decide themselves which objects should be deleted.

    18 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Preservation & Format Library  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. Allow full-text searching of all objects in an IE, not just one at a time.

    There is a way to have Primo index the full text of PDFs that are in Rosetta which can help a user find which Rosetta IE has a document containing their term/phrase but then once the user clicks through to the Rosetta viewer there is no way for the user to know where their search term appears. Having the search term come through to the viewer would be great, but that would only work when there are a few PDFs. For IEs that contain dozens of PDFs the user would have to open each one and search for their term. It would be great if there were a way to search the full-text of all files in an IE at once in the viewer.

    There is a way to have Primo index the full text of PDFs that are in Rosetta which can help a user find which Rosetta IE has a document containing their term/phrase but then once the user clicks through to the Rosetta viewer there is no way for the user to know where their search term appears. Having the search term come through to the viewer would be great, but that would only work when there are a few PDFs. For IEs that contain dozens of PDFs the user would have to open each one and search for their term.… more

    35 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    3 comments  ·  Publishing & Delivery  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. make

    As the set of supported operating systems is known and limited, it would be great to have a Rosetta installation path that uses the distributions' packet manager (e. g. yum) for the initial installation and all upgrade processes. This could facilitate disaster recovery, improve availability and reduce the time needed for upgrades (you could just run "yum upgrade"). DB connectivity etc. could be checked during the package installation.

    7 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Support Indexing of Date Range

    Enable indexing of a range between start and end values.

    4 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Data Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Adi Alter responded

    Submitted by Ex Libris PM on behalf of our customers