Initial support for serials including prediction patterns and issue generation
(UXPROD-4437)
|
|
| Status: | Open |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Quesnelia (R1 2024) | Parent: | Initial support for serials including prediction patterns and issue generation |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Owen Stephens | Assignee: | Owen Stephens |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | LC-priority2, loc, serials | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Release: | Quesnelia (R1 2024) |
| Epic Link: | Initial support for serials including prediction patterns and issue generation |
| Development Team: | K-Int |
| PO Rank: | 0 |
| Description |
|
Current situation or problem: Feature to add support for specifying enumeration and chronology rules for serials and use them when generating expected pieces to create appropriate labels for each predicted piece Given a set of predicted issues (generated through the recurrence, omission and combination rules) then a set of rules for labelling the issues should be supported. Chronology labels are concerned with labelling serials issues with chronological labels (such as month, or date) Enumeration labels are concerned with labelling serials issues with structured numbering/labelling (such as volume and issue numbers) Typically a serial will have a single enumeration sequence, but there are also examples of serials which have multiple enumeration sequences. A typical example might be that there is a Volume/Issue enumeration where the volume number ticks up every X issues and the issue numbering resets with each volume up tick, and then another single continuous issue number sequence which starts at 1 for the first issue and then just goes up by one with every issue. These labels can have different behaviours when issues are omitted or combined (e.g. combined issues can be a single physical piece that is counted as a single issue in terms of numbering, or as multiple issues). Different enumeration schemes for the same serial can have different rules for combined and omitted issues! Typically several components of enumeration and chronology combine to express a single user readable label for an issue such as:
The individual aspects of the enumeration and chronology can be important as well as the resulting label (e.g. to support correct ordering of issues) Proposed solution/stories We propose that within a publication pattern the user will be able to set up multiple labels. Each label will have a "type" - chronology or enumeration - and then options depending on that type An enumeration label could have multiple levels (e.g. for Volume, issue) and each level will have it's own style of numbering (numeric, ordinal, alphabetical, roman numerals) and rules for whether it is continuous or it resets on a cycle A chronology label will need to specify the level at which the chronology is used (e.g. just year, season + year, month + year, full date) Finally these labels will be combined into a single human readable label using a templating approach where the user can write a template that incorporates the labels generated Outstanding questions We need to work out how the templating will draw on the labels - e.g. a template like: Volume @L1.1, Issue @L1.2 might indicate that "Label 1, first enumeration" is used for the volume and "Label 1, second enumeration" is used for the issue. However, the label will need to draw on all aspects of enumeration and chronology - but we want the templates to be relatively simple to write. Some aspects of enumeration and chronology are language dependent - month names in German are on the same as English - so we need to work out how the language dependent aspects are handled We need to work out how to express combined issue labelling and how the user enters this. Could this be done at the template level? Or should it be at the Label rule level? |