[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: |
|
||||||||||||||||||||
| 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 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? |