MODULE_SELF_EVALUATION.md

Shared/Common

• Uses Apache 2.0 license
• Module build MUST produce a valid module descriptor
• Module descriptor MUST include interface requirements for all consumed APIs
• Third party dependencies use an Apache 2.0 compatible license
• Installation documentation is included
  • -note: read more at https://github.com/folio-org/mod-search/blob/master/README.md
• Personal data form is completed, accurate, and provided as PERSONAL_DATA_DISCLOSURE.md file
• Sensitive and environment-specific information is not checked into git repository
• Module is written in a language and framework from the officially approved technologies page
• 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
• Module gracefully handles the absence of third party systems or related configuration
• Sonarqube hasn't identified any security issues, major code smells or excessive (>3%) duplication
• Uses officially supported build tools
• Unit tests have 80% coverage or greater, and are based on officially approved technologies

Backend

• Module's repository includes a compliant Module Descriptor
  • -note: read more at https://github.com/folio-org/okapi/blob/master/okapi-core/src/main/raml/ModuleDescriptor.json
• Module includes executable implementations of all endpoints in the provides section of the Module Descriptor
• Environment vars are documented in the ModuleDescriptor
  • -note: read more at https://wiki.folio.org/pages/viewpage.action?pageId=65110683
• If a module provides interfaces intended to be consumed by other FOLIO Modules, they must be defined in the Module Descriptor "provides" section
• All API endpoints are documented in RAML or OpenAPI
• All API endpoints protected with appropriate permissions as per the following guidelines and recommendations, e.g. avoid using *.all permissions, all necessary module permissions are assigned, etc.
  • -note: read more at https://dev.folio.org/guidelines/naming-conventions/ and https://wiki.folio.org/display/DD/Permission+Set+Guidelines
• Module provides reference data (if applicable), e.g. if there is a controlled vocabulary where the module requires at least one value
• If provided, integration (API) tests must be written in an officially approved technology
  • -note: while it's strongly recommended that modules implement integration tests, it's not a requirement
  • -note: these tests are defined in https://github.com/folio-org/folio-integration-tests
• Data is segregated by tenant at the storage layer
• The module doesn't access data in DB schemas other than its own and public
• The module responds with a tenant's content based on x-okapi-tenant header
• Standard GET /admin/health endpoint returning a 200 response
  • -note: read more at https://wiki.folio.org/display/DD/Back+End+Module+Health+Check+Protocol
• High Availability (HA) compliant
  • Possible red flags:
    • Connection affinity / sticky sessions / etc. are used
    • Local container storage is used
    • Services are stateful
• Module only uses infrastructure / platform technologies on the officially approved technologies list.
  • e.g. PostgreSQL, ElasticSearch, etc.