| Table of Contents |
|---|
Important Upgrade Considerations
...
| Functional Area | Change or Addition | Considerations | Action required | Action timing | Contact person | Comments | Related JIRA issues | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Affected app or module | What has been changed or added that should be noted for this release | What challenges may arise related to this change or addition | If applicable, detail what action(s) must be taken here | When can the action be taken (before, during or after upgrade) | User name of person that can provide additional detail | Name of user leaving comment: comment on what you encountered or ask a question @mention Contact person | Include issue link for bug fix, story or feature that applies | ||||||||||||||||||||||||||||||||
| mod-inventory-storage | The module now depends on Kafka message broker. Kafka should be up and running before module install. | Inventory-storage APIs (instances/holding-records/items - create, update, delete actions) will fail with 500 status code if Kafka is unreachable. | Make sure KAFKA_PORT and KAFKA_HOST environment variables are set and propagated to the mod-inventory-storage container before module installation. Example: for rancher dev environments we set following values - KAFKA_HOST: kafka, KAFKA_PORT: 9092 | Before upgrade | The same approach as for mod-pubsub may be used here. We tried to follow the same naming for the properties. | ||||||||||||||||||||||||||||||||||
| mod-inventory-storage | Statistical code name needs to be unique | The upgrade process will fail when there are two or more statistical codes with the same name prior to the upgrade | Change the name of any existing statistical codes that are the same as another statistical code | Before upgrade |
| ||||||||||||||||||||||||||||||||||
| mod-inventory-storage | The id property of the circulationNotes array property in the Item object is mandatory | The id property got added to the item schema in Honeysuckle. If data added in, it will break things. | With Iris, this id is now mandatory, and the UI and the API will hang if not present. | Before upgrade | This is an unexpected impact of
This issue was likely present in previous distributions of FOLIO |
| |||||||||||||||||||||||||||||||||
mod-source-record-manager | Changes to the default MARC Bib-to-Instance map:
| If library has customized the default MARC bib-to-Instance map, review these changes and decide if they should be added to the library's custom map. If changes are made, you may need to trigger a refresh of the existin gInstances that are based on the SRS MARC records, so that the changes are reflected in the Instance | |||||||||||||||||||||||||||||||||||||
| mod-source-record-storage | An end point has been added to allow searching MARC records. | The end point will only return results from MARC records added after the upgrade. A script to retroactively process pre-existing records has been developed, see MODSOURCE-276: Add existing records to the SRS Query API table | To add records that existed prior to upgrade to the query search see MODSOURCE-276: Add existing records to the SRS Query API table Script: https://github.com/folio-org/mod-source-record-storage/blob/master/mod-source-record-storage-server/src/main/resources/migration_scripts/fill_marc_indexers.sql | After upgrade |
| ||||||||||||||||||||||||||||||||||
| mod-circulation | The age to lost processes (ageing borrowed items to lost and issuing fees / fines for those items) are no longer automatically scheduled to run periodically | No items will be aged to lost and no fees / fines will be issued unless these processes are scheduled by the hosting provider | Organisations who need these processes to run will have to schedule them from outside the system Configuration needed by the hosting provider
Organisations will likely need to schedule these processes separately meaning two separate tasks and schedules are likely to be needed (separate users may be used for each process) New External Endpoints
No body needs to be provided to make requests to either of these endpoints. Further documentation is available at How to Schedule Age to Lost Processes | During or after the upgrade |
| ||||||||||||||||||||||||||||||||||
| mod-kb-ebsco-java | New feature "Usage Consolidation" is now supported | Configuring Usage Consolidation settings | In order to configure "Usage Consolidation" → apart from the settings on UI, middle layer service needs to be configured by making a query directly to DB like the below: ``` INSERT INTO <tenant_id>_mod_kb_ebsco_java.usage_consolidation_credentials(client_id, client_secret) VALUES (?, ?); ``` User stories have been created to make this configurable from UI. | After upgrade to Iris |
| ||||||||||||||||||||||||||||||||||
| mod-ncip | New permission required to call NCIP services: | During or after upgrade | |||||||||||||||||||||||||||||||||||||
| mod-oai-pmh | This is not a required step but we noticed during tests that if the mod-oai-pmh performance is poor, re-indexing and vacuuming indexes located in mod-inventory-storage resolved the issue. |
| During or after upgrade | ||||||||||||||||||||||||||||||||||||
| mod-data-import, mod-source-record-manager, mod-source-record-storage, mod-inventory, mod-invoice | All modules involved in data import process are now communicating through Kafka directly. Kafka should be configured and running before modules are installed and additional parameters should be set for modules. | New setup and configurations required | Follow the instructions to set all the necessary parameters for Kafka and the modules | Before and during the upgrade | |||||||||||||||||||||||||||||||||||
| mod-search | Since 1.3.0 version OKAPI_URL environment variable is required for the module. | Data ingestion won't work. | Set/pass OKAPI_URL to the application container. | On module startup. |
| ||||||||||||||||||||||||||||||||||
| mod-pubsub | Environment variables SYSTEM_USER_NAME and SYSTEM_USER_PASSWORD can be used to set up credentials for PubSub system user. Otherwise, default values (username pub-sub, password pubsub) will be used. | Not providing these variables will result in using default credentials which is considered a security issue. | Set SYSTEM_USER_NAME and SYSTEM_USER_PASSWORD environment variables. | On module startup. |
| ||||||||||||||||||||||||||||||||||
| mod-agreements | When upgrading from Goldenrod consider running the Supplementary Document cleanup job on initialising the module in the tenant. | The Supplementary Document cleanup job fixes an issue that could lead to a single supplementary document being linked to multiple agreements. The cleanup job will detect this situation and duplicate the document so each agreement is linked to it's own copy of the document | On installing/starting the module in the tenant, include cleanSupplementaryDocs%3Dtrue in the tenantParameters. e.g. /_/proxy/tenants/diku/install?tenantParameters=cleanSupplementaryDocs%3Dtrue | On module startup. |
| ||||||||||||||||||||||||||||||||||
| mod-patron-blocks | Events which took place before first mod-patron-blocks deployment are NOT taken into account while calculating automated patron blocks. | This is an inherent limitation of mod-patron-blocks which is an event-based system. | If tenant plans on using Automated Patron Blocks feature AND full event synchronization has not been performed before, follow steps outlined in Q3 2020 (Honeysuckle) Release Notes. | After upgrade |
| ||||||||||||||||||||||||||||||||||
| mod-source-record-storage | Cleanup of invalid snapshot statuses | Data Import update of records associated with snapshot (with invalid status) will fail | Table snapshots_lib records should only contain status values of 'ERROR' or 'COMMITTED' for jobs which are no longer executing - the following manual script can be run to adjust values: This script should NOT be run if DI jobs are currently actively in progress | Before or After Upgrade (DI Jobs not running) |
| ||||||||||||||||||||||||||||||||||
| mod-source-record-storage | Populate missed instance_hrid | Run following manual script to populate missed instance_hrid in records_lb table. ``` DO $$ BEGIN RAISE notice 'Script for populating missing Instance HRIDs in SRS started'; UPDATE <tenant>_mod_source_record_storage.records_lb rec SET instance_hrid = arr.item_object->>'001' FROM <tenant>_mod_source_record_storage.marc_records_lb ind, jsonb_array_elements(content->'fields') with ordinality arr(item_object, position) WHERE rec.id = ind.id and rec.instance_id is not null and rec.instance_hrid is null and arr.item_object ? '001'; RAISE notice 'Script for populating missing Instance HRIDs in SRS finished'; END; $$; ``` | Before or After Upgrade |
| |||||||||||||||||||||||||||||||||||
| mod-circulation | All Service Points must be associated with a Fee/Fine Owner at Settings>Users>Fee/Fine: Owners for overdue fines and lost item fees to work properly. If an overdue fine/lost item fee is calculated for an item with a Location whose Primary Service Point is not associated to a Fee/Fine Owner, the overdue fine/lost item fee will NOT be charged to the patron. | In the future we will have a Default Fee/fine Owner to be charged. (See UXPROD-2278 for details.) | |||||||||||||||||||||||||||||||||||||
| mod-circulation | Upon deployment make sure that automatic fee/fine types were added to the mod-feesfines database. Otherwise overdue fine creation functionality will not work. | To check, make a call to /feefines?query=automatic==true. The response should contain 4 entries: "Overdue fine", "Lost item fee", Lost item processing fee" and "Replacement processing fee." | |||||||||||||||||||||||||||||||||||||
| mod-circulation | Overdue fine policies must be set up and circulation rules have to refer to policies that exist. | If you do not charge overdue fines, you need to create one overdue fine policy that is for an overdue fine of 0 and use that overdue fine policy for every circulation rule. | |||||||||||||||||||||||||||||||||||||
| mod-circulation | Lost item fine policies must be set up and circulation rules have to refer to policies that exist. | If you do not charge lost item fees, you need to create one lost item fee policy that is for a lost item fee of blank and use that lost item fee policy for every circulation rule. |
...
This feature will allow a user to export filtered data in the Circulation log to a CSV file. Accessed through the Circulation Log app > Run a search > Open the “Actions” drop-down list > Select “.CSV export”
Cornell Library's go-live requirements to transfer fees/fines to the Cornell bursar system
Automated Transfer of fees/fines to bursar or other account. Accessed through Settings > Tenant > General: Bursar (to run a Bursar export manually or set the scheduling parameters for the export)
Permissions Updates
| App | New Permissions | Deprecated Permissions | Product Owner |
|---|---|---|---|
| Data import | Renamed UI: ui-data-import module is enabled to Data import: all permissions, to make it clearer. Scope of the permissions did not change. | ||
| Data import | Renamed Settings (data-import): display list of settings pages to Settings (Data import): Can view, create, edit, and remove, to make it clearer. Scope of the permission did not change. | Ann-Marie Breaux (Deactivated) | |
| Inventory | The option to add tags to Inventory record types (instance, holdings, item) now has the consequence that anyone with inventory permissions should have their permissions edited to add either the Tags on records: View only or Tags: All permissions Important: If the user permissions are not updated as described above, then the Inventory app will not display in the top menu bar for the user with the Inventory app permissions. | ||
| Inventory | We have implemented the possibility to move holdings and item in Inventory, but any transfers are not yet being reflected in dependent apps; e.g. Orders, Request, and Courses. In order to prevent corrupt data it's highly recommended that all libraries limit the ability to move holdings and item by limiting the number of staff having the appropriate user permission to move holdings and item. | Charlotte Whitt | |
| Remote Storage | Remote storage integration has one level of permissions - Remote storage: Create, read, update, delete. A user with these permissions can create and configure remote locations. Any user with Inventory: View, create, edit instances has the ability to change the location of holdings and items to remote storage, and from remote storage to main locations. | ||
| Check out | New Permissions: ui-checkout.viewRequests (Check out: View requests), ui-checkout.viewLoans (Check out: View loans), and ui-checkout.viewFeeFines (Check out: View fees/fines) UI-only permissions that control whether the Loans, Requests, and FeeFine information in the user pane of Check out are active hyperlinks to their respective information. Important: these permissions are not included in any other permission set by default, including ui-checkout.all (Check out: All permissions), and they are required to enable the indicated hyperlinks in Check out. | Brooks Travis(formerly Emma Boettcher) | |
| quickMARC | quickMARC: Derive new MARC bibliographic record - this permission allows one to derive a new MARC bib record from an existing MARC record | Khalilah Gambrell | |
| eholdings |
| Khalilah Gambrell | |
| Agreements |
| ||
| Licenses |
| ||
| Local KB Admin |
|
...
- Most front-end modules don't fetch exact search result count from backend (
).Jira Legacy server System JiraJIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key RMB-673 - Estimated search result count has a wording that incorrectly suggests it is a precise number ("8081 records found"). Only numbers below 1000 are precise (details: RMB Estimated totalRecords). (WIP
UXPROD-2623 - Wait for POC of Elastic Search - Round estimated search result hit count (totalRecords) Blocked )
- Some modules fail in Pgpool-II replication (
,Jira Legacy server System JiraJIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key FOLIO-2447
).Jira Legacy server System JiraJIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key FOLIO-2978
...
Upgrade might fail for mod-source-record-storage while executing “2020-09-09--15-00-fill-instance-hrid” migration script. It is caused by the presence of MARC_Bib records with multiple “001” fields in the DB. In order to successfully upgrade, such records should be revised and corrected (use check_001_field_duplicates.sql to find such records). Otherwise, upgrade to Juniper HF#1 version once it is available.
| App | Known issue | Workaround | JIRA issue | Product Owner | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Orders and Receiving | Data corruption. When holding/item data are moved in Inventory the connected Order lines are not updated accordingly. The PO remains linked to the original instance and items but location IS NOT updated. This could result in receiving of unreceived pieces generating new holding records or moving back to the original instance. | The current workaround is to be very judicious in allowing users to move items and holdings in Inventory when there are open orders related to item records. We suggest ONLY granting certain users this ability for now. All short term fix we attempted to put in place while we wait for a more systemic resolution to the underlying issue would introduce problems of its own. |
| |||||||||||||||||||||||||
| Orders and receiving | If users "Unopen" orders that have "Manually add pieces for receiving" = true. If they had created any pieces they will not be able to open the order again without deleting pieces from the receiving area. System will force user to delete as part of open order process. | You can recreate the necessary records after the opening the order again. |
| |||||||||||||||||||||||||
| Orders | Possible to save POL with no location even though location is a "required" field. This can happen when you use an order template to add a location field set with only quantity populated | When order fails to open edit POL and select a location. Save POL and Open when desired. |
| |||||||||||||||||||||||||
| Orders | When using save and open button on POL. If Funds have no budget the UI may tell you that it could not save the POL when it actually did save the POL. This could result in the user unknowingly creating multiple POLs and needing to delete them after. | Make sure your Funds have current budgets before applying them to purchase orders. If error occurs "Unopen" order and delete extra POLs. | Already resolved for the Juniper release. | Dennis Bridges | ||||||||||||||||||||||||
| mod-orders-storage | If OKAPI_URL contains a path after the hostname like https://example.com/okapi the upgrade always fails. | no known workaround |
| |||||||||||||||||||||||||
| Organizations | When fields within a closed accordion are invalid the UI does not force them open when trying to save the record. This may confuse users as to why they cannot save edits to an organization record | Click "Expand all" accordions and look for the validation errors. This may be empty required fields or invalid data added during a migration. |
| |||||||||||||||||||||||||
| Orders | When order includes only 1 Fund distribution, deleting it from the AND not adding a new one to the POL before clicking save and close. Results in a lingering encumbrance that is not released appearing on the budget | If you wish to remove the last Fund distribution from a POL such that it will no longer have any encumbrance. Edit the POL and then navigate to the encumbrance in the finance app and use the "Release encumbrance" action. Note it requires a permission.it will no longer have any encumbrance. Edit the POL and then navigate to the encumbrance in the finance app and use the "Release encumbrance" action. Note it requires a permission. |
| |||||||||||||||||||||||||
| Orders/Invoices | When orders with "Manually add pieces for receiving" = false are received and after that has been do a user moves the related item records from the inventory app. Approving and paying an invoice against that order line can generate new pieces and holdings/items in inventory. | Rather than moving the items in inventory use the receiving app to receive them to the correct location (Holding). |
| |||||||||||||||||||||||||
| Data export | Holdings' permanent location or item's effective location not always populated during the export while using a custom mapping profile. | Not known at this point. We believe this is the data corruption issue as we were not able to recreate it on other than Bugfest environments. | MDEXP-391 | |||||||||||||||||||||||||
| OAI-PMH | Holdings data is not discoverable when item record is suppressed | Not known at this point | MODOAIPMH-317 | |||||||||||||||||||||||||
| Requests | Out of sync data: When holding/item data are moved, or other updates made to items, in inventory, any connected requests are not updated accordingly (eg. new barcodes, title, or instance identifiers) | Take care when modifying items with open hold requests. |
| |||||||||||||||||||||||||
| Circulation log | Loan details from the Action dropdown in the Log will sometimes show an error message BEFORE loan details actually load. | Give the record a little time to load, or get Loan details from another source, like the Item record | Stephanie Buck | |||||||||||||||||||||||||
| Claimed returned fees/fines | There were two bugs discovered in the Iris BugFest after the test cases had been passed and just before Iris was to be released. They were caused by changes to the code in BugFest that adversely impacted what had already been tested. As there are easy workarounds, the two bugs will not be fixed until the Juniper (R2 2021) release. Bug 1: When checking in a claimed returned item, the "suspended" lost item fees are not being cancelled (UICHKIN-252) Bug 2: When resolving a claimed returned situation, the lost item fees are not cancelled if they have had a transfer made before they were claimed returned (UICIRC-570) We also have a bug that was found earlier that we were unable to fix for the Iris Release. Bug 3: For aged to lost items that are claimed returned, and then returned by patron, if the Lost Item Processing Fee is not refunded the Payment Status should be updated to "Outstanding" (UIU-2129) | Bug 1: The "suspended" Lost Item Fee and Lost Item Processing Fee (if there is one) remain suspended after claimed returned item is check in. Given they are "suspended", the patron is not being held liable for the fees. The library is able to waive the "suspended" lost fees to remove them from the "suspended" status. Bug 2: The "suspended" Lost Item Processing Fee appears in the Closed Fees/Fines tab, so the patron is not being held liable. This should not be a problem at all for libraries that don't transfer fees/fines or don't do it quickly. Bug 3: This only impacts you if your institution is using aged to lost processing and do not refund the Lost Item Processing Fee if a lost item is returned. The Lost Item Processing Fee will remain as "Suspended claim returned." It can be paid with this status, but more likely you will want to waive the original Lost Item Processing Fee and create a new one as a manual charge. | Holly Mistlebauer | |||||||||||||||||||||||||
| Overdue fines | Overdue fines not charged when charging overdue fines by the minute over periods when library is opened then closed | This bug only impacts you if your institution bills overdue fines by the minute and does not charge overdue fines when the library is closed. You will need to update your "Overdue fine" policies to use hours (or anything other than minutes) as the "Interval". | CIRC-1135 | Holly Mistlebauer | ||||||||||||||||||||||||
| Manual fees/fines | When creating a new manual fee/fine, if you enter a comma in the "Fee/fine amount" field the value will not be saved properly despite looking correct (for example, "1,000.00" will be saved as "1.00"). | Do not enter a comma in the "Fee/fine amount" field on the "New fee/fine" page. | UIU-2156 | |||||||||||||||||||||||||
| Mod-finance-storage | Transaction table upgrade failure when purchase order record is missing. Discovered when upgrading from mod-finance-storage-6.0.1 to mod-finance-storage-7.0.2 | Delete orphaned encumbrance transaction records. Retry migration. See script in comment here from Wayne for more information. |
| |||||||||||||||||||||||||
| Data Import | MARC record field protection is not yet working correctly |
| ||||||||||||||||||||||||||
| Data Import | EDIFACT invoices can be imported, but invoice and invoice-line adjustments still need additional work. Also, if an incoming invoice line does not link to a corresponding purchase order line, there is no manual way to link them in Iris (will be available in Juniper). If the EDIFACT invoice file has an upper-case file extension (e.g. EDI), it much be changed to lower-case (e.g. edi) before uploading and importing. | For invoice and invoice-line adjustments, enter them manually after the rest of the invoice has been imported. For invoice lines that do not match to purchase order lines, 1) delete the invoice line, and add the invoice line manually, based on finding and linking the purchase order line manually. Or 2) review the matchpoints in the invoice data, and manually edit each purchase order lines to include those matchpoints manually, Then delete the imported invoice, and re-import it. This time the incoming invoice-lines should match to the corresponding purchase order lines. |
| Ann-Marie Breaux (Deactivated) | ||||||||||||||||||||||||
| Data Import | EDIFACT invoice field mapping profiles | If a default EDIFACT field mapping profile is copied, and then the Vendor Reference Number field mapping is completely removed, that results in a bug. Temporary workarounds: 1) If removing the field mapping for Vendor Reference Number, create a new field mapping profile instead of duplicating an existing one. 2) If duplicating an existing field mapping profile, instead of entirely removing the Vendor Reference number field, leave some value in it, even if the field will not be used to match to the relevant POL. |
| Ann-Marie Breaux (Deactivated) | ||||||||||||||||||||||||
| Local KB Admin Settings | The "LOCAL" knowledgebase appears as editable in the settings. Only external data sources should be visible and editable in this screen. Editing the LOCAL knowledgebase could cause issues or the creation of an addition LOCAL knowledgebase (if the name is changed) | Do NOT edit the LOCAL knowledgebase in the settings |
| |||||||||||||||||||||||||
| Mod-invoice and mod-finance | Credit invoice results in a credit of $0 being charged to the fund. Meaning $0 is added back to the Fund. | No current workaround. Suggesting libs avoid creating credit invoices. This should be resolved in a hotfix release |
| |||||||||||||||||||||||||
| Courses | An error in the "Courses: All Permissions" system-defined permission set was inadvertently introduced as part of the Iris release and not discovered until Iris implementer sites began testing. Users with the permission set "Courses: All Permissions" and no other Courses permissions cannot edit courses. | The workaround is not use the Courses: All Permissions set, and instead assigned Courses app users a mix of the segmented permissions that allows them to have desired create/edit functionality: The Courses: All Permissions set is fixed as of the Juniper release, so permissions can be reverted at that point. |
| N/A |
...
Deployment Considerations:
- If you want to benefit from permission migration you need OKAPI v4.6.0 or greater (v4.7.2 or greater is highly recommended) and mod-permissions v5.13.0.
- Contrary to earlier communications, it is NOT required to upgrade mod-permissions first or last. It is also NOT required that you upgrade to the latest Honeysuckle Hot Fix release prior to upgrading to Iris.
...
- Performance Task Force analysis (as of Iris Hotfix 3): 0- Recommended Maximum File Sizes and Configuration
- Supported in Iris:
- Create and update Inventory Instances, Holdings, and Items
- MARC record modifications to add, remove, and change constant data within the incoming file
- MARC-MARC matching on 001 and 999 ff fields, but not any other MARC fields
- EDIFACT invoice loading
- For importing EDIFACT invoices, the User needs these permissions
- Data import: all permissions
- Settings (Data import): Can view, create, edit, and remove
- Invoice: Assign acquisitions units to new record
- Invoice: Can view, edit and create new Invoices and Invoice lines
- Invoice: Can view, edit and delete Invoices and Invoice lines
...
- Override blocks on requests:
- UXPROD-2910 - Added the ability to override patron and item blocks on requests
- Warning modals when an item with pending requests is marked missing, withdrawn, claimed returned, or declared lost:
- UXPROD-2411 - When changing an item's status to missing or withdrawn in Inventory or claimed returned or declared lost in Users, a modal stating the number of open requests (with a link to the request queue) will be presented to staff with the option to cancel the status change
- Patron comments on requests:
- UXPROD-1800 - Added a patron comments field to requests that can be entered by staff or via the edge-patron API (discovery) and is available as a token in staff slips and the Requests interface
...
Tickets list
| Jira Legacy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Modules list
| Jira Charts | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Module mod-aes removed from the Iris release platform by request of the dev team (Hongwei Ji and Matt Reno). Was added by mistake
Hot fix release #2 -
| Status | ||||||
|---|---|---|---|---|---|---|
|
Tickets list
| Jira Legacy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Modules list
| Jira Charts | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Tickets list
| Jira Legacy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Modules list
| Jira Charts | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Tickets list
| Jira Legacy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Modules list
| Jira Charts | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
New Features by Epic (Sub-Project)
| Jira Legacy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Closed Bugs
| Jira Charts | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
All Closed Bugs and Stories
| Jira Charts | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Remaining Open Bugs at Time of Release
| Jira Charts | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...