Skip to end of banner
Go to start of banner

[Draft] Edge-dcb Module submission self-evaluation

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

  • Step 1 - select one of the 3 results below against each criteria:
  • ACCEPTABLE
  • UNACCEPTABLE
  • INAPPLICABLE
  • Step 2 - provide evidence 

CriteriaComments/ Action ItemsResponsible

Evaluation result: 

  • ACCEPTABLE
  • UNACCEPTABLE
  • INAPPLICABLE

Evidence:


Status:

To Do

In Progress

Done

1

 Uses Apache 2.0 license


Kalibek Turgumbayev 


2

 Module build MUST produce a valid module descriptor





3

 Module descriptor MUST include interface requirements for all consumed APIs





4

 Third party dependencies use an Apache 2.0 compatible license





5

 Installation documentation is included





6

 Personal data form is completed, accurate, and provided as PERSONAL_DATA_DISCLOSURE.md file





7

 Sensitive and environment-specific information is not checked into git repository





8

 Module is written in a language and framework from the officially approved technologies page





9

 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





10

 Module gracefully handles the absence of third party systems or related configuration





11

 Sonarqube hasn't identified any security issues, major code smells or excessive (>3%) duplication





12

 Uses officially supported build tools





13

 Unit tests have 80% coverage or greater, and are based on officially approved technologies





14



15

 Module includes executable implementations of all endpoints in the provides section of the Module Descriptor





16

Environment vars are documented in the ModuleDescriptor





17

 If a module provides interfaces intended to be consumed by other FOLIO Modules, they must be defined in the Module Descriptor "provides" section





18

 All API endpoints are documented in RAML or OpenAPI





19

 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.





20

 Module provides reference data (if applicable), e.g. if there is a controlled vocabulary where the module requires at least one value





21

 If provided, integration (API) tests must be written in an officially approved technology





22

 Data is segregated by tenant at the storage layer


Magzhan Artykov


23

 The module doesn't access data in DB schemas other than its own and public


Magzhan Artykov


24

 The module responds with a tenant's content based on x-okapi-tenant header





25

 Standard GET /admin/health endpoint returning a 200 response





26

 High Availability (HA) compliant

    • Possible red flags:
      • Connection affinity / sticky sessions / etc. are used
      • Local container storage is used
      • Services are stateful

Magzhan Artykov


27

 Module only uses infrastructure / platform technologies on the officially approved technologies list.

    • e.g. PostgreSQL, ElasticSearch, etc.

Magzhan Artykov


  • No labels