| Criteria | Comments/ Action Items | Responsible | Evaluation result: - ACCEPTABLE
- UNACCEPTABLE
- INAPPLICABLE
| Evidence:
| Status: To Do In Progress Done |
|---|
| 1 | - Upon acceptance, code author(s) agree to have source code canonically in folio-org github
|
| Kalibek Turgumbayev |
|
|
|
| 2 | - Copyright assigned to OLF
|
| | | |
|
| 3 | |
| | | |
|
| 4 | - Third party dependencies use an Apache 2.0 compatible license
|
| | | |
|
| 5 | - Module’s repository includes a compliant Module Descriptor
|
| | | |
|
| 6 | - Modules must declare all consumed interfaces in the Module Descriptor “requires” and “optional” sections
|
|
|
|
|
|
| 7 | https://wiki.folio.org/pages/viewpage.action?pageId=65110683 |
|
|
|
|
|
| 8 | - Back-end modules must define endpoints consumable by other modules in the Module Descriptor “provides” section
|
|
|
|
|
|
| 9 | - All API endpoints are documented in RAML or OpenAPI
|
|
|
|
|
|
| 10 | - All API endpoints protected with appropriate permissions
|
|
| ACCEPTABLE |
|
|
| 11 | - No excessive permissions granted to the module
|
|
|
|
|
|
| 12 | - Code of Conduct statement in repository
|
|
|
|
|
|
| 13 | - Installation documentation included
|
|
|
|
|
|
| 14 | - Contribution guide is included in repo
|
|
|
|
|
|
| 15 | - Module provides reference data (if applicable)
|
|
|
|
|
|
| 16 | - Personal data form is completed, accurate, and provided as
PERSONAL_DATA_DISCLOSURE.md file |
|
|
|
|
|
| 17 | - Sensitive information is not checked into git repository
|
|
|
|
|
|
| 18 | - Module is written in a language and framework that FOLIO development teams are familiar with e.g. Vertx/RMB, Spring Way/folio-spring-base, and React/Stripes
|
|
|
|
|
|
| 19 | - Back-end modules are based on Maven/JDK 11 and provide a Dockerfile
|
|
|
|
|
|
| 20 | https://github.com/folio-org/folio-integration-tests |
|
|
|
|
|
| 21 | - Back-end unit tests at 80% coverage
|
|
|
|
|
|
| 22 | - Data is segregated by tenant at the storage layer
|
|
|
|
|
|
| 23 | - Back-end modules don’t access data in DB schemas other than their own and public
|
|
|
|
|
|
| 24 | - Tenant data is segregated at the transit layer
|
|
|
|
|
|
| 25 | - Back-end modules respond with a tenant’s content based on x-okapi-tenant header
|
|
|
|
|
|
| 26 | https://wiki.folio.org/display/DD/Back+End+Module+Health+Check+Protocol |
|
|
|
|
|
| 27 | - HA (High Availability) compliant (at least 2 replicas)
|
|
|
|
|
|
| 28 | - Module only uses FOLIO interfaces already provided by previously accepted modules e.g. a UI module cannot be accepted that relies on an interface only provided by a back end module that hasn’t been accepted yet
|
|
|
|
|
|
| 29 | - Module only uses existing infrastructure / platform technologies_ e.g. PostgreSQL, ElasticSearch (and Kafka, despite it being still unofficial at present)_
|
|
|
|
|
|
| 30 | - Integration with any third party system (outside of the FOLIO environment) tolerates the absence of configuration / presence of the system gracefully.
|
|
|
|
|
|
| 31 | - Front-end modules: builds are Node 16/Yarn 1
| 32 | - Front-end unit tests written in Jest/RTL at 80% coverage
| 33 | - Front-end End-to-end tests written in Cypress, if applicable -note: these tests aren’t defined as part of the module
| 34 | - Front-end modules have i18n support via react-intl and an en.json file with English texts
| 36 | - Front-end modules have WCAG 2.1 AA compliance as measured by a current major version of axe DevTools Chrome Extension
| 37 | - Front-end modules use the current version of Stripes
| 38 | https://ux.folio.org/docs/all-guidelines/ | 39 | - Front-end modules must work in the latest version of Chrome (the supported runtime environment)
| 40 | - sonarqube hasn't identified any security issues
|
|
|
|
|
|