110 results found

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

2. Add Error Logs to Preservation Plans and Preservation Executions/ Technical Issues

   while working with preservation plans, testing alternatives I would appreciate to have more information about problematic IEs. Error Logs like in Submissions/Technical Issues/ would be helpful. Please add "View Errors".

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

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

4. Support Publishing Scheduling on an Institutional Level

   Possibility to run publishing jobs on the Insitutional level rather than on the consortia level.

   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  ·  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
   Adi Alter responded

   Submitted by Ex Libris PM on behalf of our customers

5. Allow export of all instances of an element from Search for Objects

   When you use the "Search for Objects" from the Data Management menu you can customize the columns and then export those columns easily to a CSV file. One issue we have is that only the first instance of an element is displayed and exported. For example, if we have multiple occurrences of dc:identifier only the first one will show and be exported. We would like all instances of each element to be included - perhaps with a separator like a semi-colon (or something else).

   9 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

6. BagIt-Validation based on 1.0 standart

   By manuel ingest, the validation of Bag according to 1.0 standard, is not fully supported. It does not check the tag manifest file checksums for their correctness. Maybe there are some other holes which you can add in a comment.

   9 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

7. Bulk delete of Processes

   We can have 100s of processes located under the Data Management tab and we would like the ability to mark some or all of the processes and then delete them in bulk

   9 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
   Planned  ·  AdminDaniel Greenberg (Product Manager, Ex Libris) responded

   Included in 6.0

8. Clean-up job for operational repository file system

   Currently the clean-up job removes old data from deposit storage. Clean up job should clean also Operational Repository / Storage Repository Group file system. Data related to finished SIPs or committed IEs should be remove after some period from the FS path which is configured for operational repository.

   The job should not remove data in TA area.

   best regards
   Milan

   8 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  ·  Administration  ·  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. Use .LOCKED file or similar while IE export is still in progress

   When exporting large IEs with multiple REPs, it is hard to tell whether the export is finished or not. This becomes especially problematic when running an external automatic job which pulls IEs from the export directory before export has actually been completed.
   It would be beneficial to flag a partially exported IE, e.g. via a .LOCKED file which is deleted once the export is complete.

   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…)
   4 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

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

11. IIIF Universal Viewer - download options - mixed content

    Looking at using the IIIF viewer for digitised manuscripts. Diaries and letters.
    For this type of material we would like to create
    1. multi-page tif (master)
    2. multipage pdf (delivery)
    3. thumbnail
    4. transcript
    When this material is displayed in the viewer we will by default like to display the multipage pdf.
    For the download options we would like the ability for customers to
    1. download the multipage pdf
    2. download the current page(s) being displayed (PDF or TIF options)
    3. full transcript

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

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

13. Changes to "Find duplicates job"

    Right now the "Find duplicates job" only checks a handful of elements for duplicate values. I would like to either ask Ex Libris to make the fields that it is searching configurable or to add original file name to the list of elements that are searched.

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

14. print image files in batch

    now on IE viewer users/librarians have to print every single image files under one IE. I hope there is a print all/in part function.

    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…)
    0 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

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

16. Solr Startup Checker Plugin

    After having had some issues with the new default Solr port in Rosetta 5.4.0.0, I suggest creating a startup checker plugin for Rosetta to test for Solr availability. Possible error scenarios involve:
    1.) network down
    2.) Name resolution down/misconfigured
    3.) Solr default port closed in the local firewall / Solr not listening

    1. & 2. could be checked by pinging the other servers' DNS names (NOT the IPs), which would test network availability and DNS resolution in one step. As Rosetta servers usually are located in the same subnet, we don't have to worry about ICMP firewall restrictions.
    2. could be tested by using "$> telnet $HOSTNAME $PORT", like "$> telnet rosetta-host-1 8983" and SSH-ing into the remote systems to list processes listening on specific ports, like "netstat -tulpn | grep 8983" or "ss -tulpn | grep 8983".

    After having had some issues with the new default Solr port in Rosetta 5.4.0.0, I suggest creating a startup checker plugin for Rosetta to test for Solr availability. Possible error scenarios involve:
    1.) network down
    2.) Name resolution down/misconfigured
    3.) Solr default port closed in the local firewall / Solr not listening

    1. & 2. could be checked by pinging the other servers' DNS names (NOT the IPs), which would test network availability and DNS resolution in one step. As Rosetta servers usually are located in the same subnet, we don't have to worry about ICMP firewall restrictions.
    2. could be tested… 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

17. Producer Mandatory Fields shall be controlled by a code table

    As of now (version 5.3) there is no code table to control which fields are optional or mandatory when adding a producer.

    We provide Rosetta as a service and the details (name, email, telephone etc.) of producers can be seen across the installation. This means that staff user 1 from institution A can see the details of the producers of all the other institutions. The workaround is to enter 123 as telephone.

    Basically we would like Rosetta to be fully compliant with the concept of multi-tenancy.
    Until this can be reached we would like to see code tables in use for any place where user-information is entered, stored and shown in Rosetta.

    We opened a ticket with Ex Libris but since this is not a bug we were asked to request a feature enhancement.

    As of now (version 5.3) there is no code table to control which fields are optional or mandatory when adding a producer.

    We provide Rosetta as a service and the details (name, email, telephone etc.) of producers can be seen across the installation. This means that staff user 1 from institution A can see the details of the producers of all the other institutions. The workaround is to enter 123 as telephone.

    Basically we would like Rosetta to be fully compliant with the concept of multi-tenancy.
    Until this can be reached we would like to see code tables in use… 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  ·  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

18. Events for DNX Validation

    with version 6.0 DNX validation was introduced for METS deposits and any AIP update. Furthermore the .xsd will be versioned. As for now I cannot find any event describing the validation process, the name and version of .xsd used for validation, the agent, the event outcome (success). I would appreciate events documenting this validation. In my opinion this is worth a provenance event, like file format identification event 25.

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

19. View preservation history of IE

    posted on behalf of Amy Joseph, NLNZ

    As a researcher, I want to be able to understand the history of an IE including preservation actions.

    As an admin, I want to be able to configure the system to display versions of a representation by EventType, so that a user can navigate between different versions of a preservation master or other rep

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

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