[FOLIO-1044] Separate reference and sample records Created: 31/Jan/18  Updated: 10/Feb/20

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Marc Johnson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: for-next-sprint, madrid
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to CIRCSTORE-36 Separate reference and sample records Closed
relates to MODINVSTOR-57 Separate reference and sample records Closed
relates to MODINVSTOR-443 Move locations and location-units fro... Closed
relates to UXPROD-1508 Populate reference data as part of in... Closed
Sprint:
Development Team: Core: Platform

 Description   

At the moment, the sample data provided by modules (or folio-ansible) is a mixture of reference and sample records.

It is intended that backend modules provide both the necessary reference data and a set of sample records versioned alongside the code.

Reference records are needed for the system to operate (e.g. resource types, item states), and it is desired that this is created by default during (or close to) tenant activation.

All existing reference records will initially be classified as fixed (in that they are loaded by default, and not intended to change). Later, we may distinguish between fixed and variable (optional, and can be changed) reference records.

There are no existing controls in the system at present to stop the editing of reference records.

Sample records are optional, and intended to provide examples of common records to ease demonstration of the system's behaviour (e.g. items, loans, users)

The intention was to load this at tenant activation (using the RAML module builder mechanism, which I believe is internal), however this may need to be reviewed following the decision to capture records for reporting via a filter in the the Okapi proxy).

This was discussed in Madrid, see https://docs.google.com/document/d/1OxrdovzMnWJsxtic4zbC5fbUz68ME9j2tBO6t0Ar0Wc/edit for more information



 Comments   
Comment by Marc Johnson [ 13/Feb/18 ]

I'm proposing the first step for this is to create two separate directories and scripts for these (and defer the loading reference records via the RAML module builder due to the potential that reporting needs these records loaded via HTTP requests via Okapi for them to be included).

Reference data directory: /reference-data
Sample data directory: /sample-data

Each directory contains sub-directories which organise the records by type, and a import.sh script (we may want to discuss windows support).

The top level directory of the module will include two separate scripts: import-reference-data.sh and import-sample-data.sh

Does this sound like a reasonable next step?

Generated at Thu Feb 08 23:10:25 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.