13 results found

1. 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

2. 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

3. CMS Update

   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.

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

   6 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  ·  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

4. Publishing Sync Job - View Log

   hen running a Publishing Sync Job and looking at the assciated 'View' we get the following information

   Mon Jan 07 09:06:40 AEST 2019 INFO sync all configurations for IE publishing
   Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614
   Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 18981613
   Mon Jan 07 09:06:41 AEST 2019 INFO Handling new IEs
   Mon Jan 07 09:06:41 AEST 2019 INFO Handling Removed IEs
   Mon Jan 07 09:06:41 AEST 2019 INFO Handling updated IEs
   Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 18981613
   Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for configurationId: 18981614
   Mon Jan 07 09:06:41 AEST 2019 INFO sync the configurationId: 20975335
   Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975337
   Mon Jan 07 09:06:41 AEST 2019 INFO Skipping Profile: 20975337 because it is inactive.
   Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 20975337
   Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975338
   Mon Jan 07 09:06:41 AEST 2019 INFO Skipping Profile: 20975338 because it is inactive.
   Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 20975338
   Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975389
   Mon Jan 07 09:06:41 AEST 2019 INFO Handling new IEs

   This is Ok but the additional information 'name/label' would be helpful

   For example in the above -

   Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614

   the informatin would be better dispayed as follows

   Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614 (Handle Publishing)

   where 'Handle Publishing' relates to the 'Data Management: Publishing Configuration | Details | General Details | Name'

   Another example

   Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975337

   the infomation would be better displayed as

   Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975337 (Rosetta2Alma)

   where Rosetta2Alma is the filed located in 'Data Management: Publishing Configuration | Details | Profile Details | Name'

   hen running a Publishing Sync Job and looking at the assciated 'View' we get the following information

   Mon Jan 07 09:06:40 AEST 2019 INFO sync all configurations for IE publishing
   Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614
   Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 18981613
   Mon Jan 07 09:06:41 AEST 2019 INFO Handling new IEs
   Mon Jan 07 09:06:41 AEST 2019 INFO Handling Removed IEs
   Mon Jan 07 09:06:41 AEST 2019 INFO Handling updated IEs
   Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 18981613
   Mon Jan 07 09:06:41 AEST… more

   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…)
   1 comment  ·  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

5. 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

6. UI interface - Repository | General Settings | Events Configuration

   It wouls be greate if we could sort the display by 'Event Type' as this will allow easier matching to the Rosetta Configuration manul Appendix C whch lists events by ID number

   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  ·  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

7. Default IE Export Location

   Would it be possible to change the default export path for DRPS Prod to ...
   /opt/drps/export/dept/CHD/WIP/Exports/[USER]
   instead of ...
   /opt/drps/pipeline/shared/operationalshared/staffwork_area/[USER]/export/ies
   or perhaps just /opt/drps/export/dept/CHD/WIP/Exports if including the [USER] is too much trouble
   It would also be nice if the default path in DCMS Prod could be ...
   /opt/dcms/pipeline/dept/CHD/WIP/Exports

   We are aware of the IE export web service. We want to be able to click on the export IE link in advanced search and have it immediately start exporting to a specific path

   See case: 00474798

   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  ·  Other  ·  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

8. Rosetta UX

   I am currently working in Rosetta 5.4 and there are a couple of UX isues that would make using the prodiuct a lot easier.

   One of these is on the pull down list. It pwiuld be good if the pull-down lists were sorted alphabetically - for example when adding a New Deposit Material flow when I access the 'Select conent structure' the list that is display is in some sort of order but it is definettly not alphabetical

   • 

   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  ·  Other  ·  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

9. UI interface - Deposits: Delivery XSL Files | Details xsl viewer

   i have been working in the XSL viewer / editor -- to make it readable i have to copy and paste the information out of the XSL window -- reformat the information to make it readable -- however when I paste the reformatted XSL file into the Rosetta XSL editor the formatting gets lost -- for example <xsl:for-each> all of the information is wrapped back to a single line -- it would be great if the formatting is maintained in the Rosetta XSL editor

   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  ·  Other  ·  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

10. Counter / SUSHI support in 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.

    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… 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  ·  Other  ·  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

11. Profiles for Rosetta-Aleph-Integration

    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 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… 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  ·  Other  ·  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

12. Rosetta UX - scheduled Jobs management

    I am not sure what the default sort sequence is for the 'Scheduled Jobs Management' but it would be good if the default sort sequence is by 'Name'

    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  ·  Other  ·  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

13. Rosetta SIP Producer ID

    Carried out a search for SIP ID in the 'Rosetta Management | Submissions:Search for SIPs' -- the results returned provides the 'Producer Id' -- you can grab the ID and use it to find the producer name -- it may be useful to not only include the producer ID but to also include the producer name - this may save that additional step of checking producer ID t get the producer's name

    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  ·  Other  ·  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