Heorhii's Work

ARCH	Priority	Planned Completion date	Notes	Questions
ARCH-36 - Getting issue details... STATUS Updating Authority mapping rules issues when upgrading from one release to another causing duplications with same UUID search issues	P1	ASAP	I think this requires a MG HF and it is needed for Nolana too. Lotus > MG upgrade — is probably okay to use below workaround. MG > Nolana upgrade – we need a plan at minimum Nolana > Orchid upgrade – we need to implement a fix Next steps Workaround > DI > Update Action profile OR delete and re-load Need to discuss with FSE hosting about mapping rules Meet with Sobha, Heorhii, Vijay, Pavlo, Slava, and Kyle Banerjee (IC) > I can schedule this meeting Long term: Investigate approach > a mechanism to update records when mapping rules are updated > update existing JIRA issue. Assign the existing JIRA with Heorhii Namchuk Natalia will schedule a meeting with Heorhii, Pavlo and Vijay
ARCH-32 - Getting issue details... STATUS	P4		High level requirements
ARCH-29 - Getting issue details... STATUS	P8		Next step Radhakrishnan Gopalakrishnan will review tests and determine if we need to continue work in Poppy or QAL. Remains low priority (next week)
ARCH-30 - Getting issue details... STATUS	P2		Report 1: Global Headings Update report (for Orchid) UIMARCAUTH-209 - Getting issue details... STATUS UIMARCAUTH-208 - Getting issue details... STATUS Report 2: Failed updated: Linked bibliographic fields report (for Orchid/Poppy - depends on estimate) UIMARCAUTH-212 - Getting issue details... STATUS UIMARCAUTH-213 - Getting issue details... STATUS Report 3: Blind headings report (for Poppy) MSEARCH-467 - Getting issue details... STATUS UIMARCAUTH-200 - Getting issue details... STATUS UIMARCAUTH-211 - Getting issue details... STATUS UIMARCAUTH-210 - Getting issue details... STATUS	Authority control reporting for Orchid/Poppy releases 1. List of :Support reporting: requirements prioritization. 2. UI wireframes on how it's expected to look like to properly build solution around actual UX expectations. 3. "These reports may be accessible from Inventory app or Authority app or Export Manager or Data export " - which UI component is supposed to be used for this representation and which format it should have? (sketches are welcome to get clear picture of FE - BE way of interaction) 4. "These reports may be available as a csv export " - is this option available after outline of report on View or beforehand? - asking as it is possible to handle request on both FE or Back-end side. - is this csv supposed to be consumed by any other component? 5. "In addition Inventory or Authority app may have additional facets/filters to allow a user To filter Authority records based on whether the record is linked to a bib field/record or not. To filter bib records based on linked status of a bib field/record " - needs UI wireframes and more details as this functionality can be implemented on Front-End (w/o server call) or Back-End side. E.g.: if filtering or facet search is required only within loaded on UI records - then solution could be done on Front-end side only
ARCH-31 - Getting issue details... STATUS	P3		Initial requirements written. See ARCH-31.	Authority control - autolink per quickMARC bib record 1. Details on autolink and expected outcomes from solutions side. Is that about to find authority by provided identifiers during creation / updating? if yes: - will User be able to choose if they want to selected / deselect automatic linkage (when possible)? - in case if autolinkage failed and fields left unlinked should it be reported? How exactly (format)? - details on Data Import process expected changes with autolinking applying (2 phases? - 1 actual entities import; 2 - linkage?)
ARCH-33 - Getting issue details... STATUS	P5		High level requirements
ARCH-34 - Getting issue details... STATUS	P6		High level requirements
ARCH-35 - Getting issue details... STATUS	P7		Next steps Heorhii Namchuk reviews feature and documents questions	non-technical Questions: Currently there is a filtering (facet-like) functionality implemented for Effective location (item) field within Browse call numbers. Does it work sufficiently? How it's supposed to be changed by adding ability to browse by call number type? How this functionality supposed to correlate with existing one conceptually and from UI/UX perspective? Is it possible to have multiple call number types for one item? How this going to be counted in facets (will it be counted multiple times for one item)? What is the difference between Search by Effective call number (item), shelving order and Browse call number functionalities? Is it supposed to get Search by effective call number changed as well as Browsing afterwards? How should look like (mock-ups / wireframes are welcome) browsing with ability of facet selection items by call number types? How current UI/UX will be changed? Is it fixed amount of call number types aggregations or always computed depends on present items with corresponding call number types? "The schema type will be determined by the value of the call number type" - does that mean dynamic computation of call number type all the time? Or is it possible to setup type during data import? "If the call number is not provided the default search will be Other scheme" - is it possible to provide more details here? Browsing by call number types had been developed before. The question is where the development stopped and what conceptual trade-offs were taken? How is call number type currently ingested / computed during the DI? Will it be possible to choose multiple facets / filters by call number type (e.g.: LC and Dewey Decimal) and continue browsing by selected criteria? Any impact on the solution creation / evaluation from the document Classification and Call number handling in Data Import? What should be considered from one (if at all) during the design? Khalilah Gambrell and Christine Schultz-Richert please look through the list of initial questions. Some could seem trivial but lets try to address ones to point the conceptual boundaries.