Module access is defined by various ways. While everbody is allowed to create modules and use or modify these, modules of other customers can be made accessible for others using three techniques.

Static Modules

Static Modules are modules delivered with ApiOmat (statically). They are by definition usable by all other customers. All other non-static, or, "dynamic" modules are only accessible by the owner - unless one of the following settings are done.

Released/Unreleased Modules

The release state of an module defines if the development has finished or not. That is, during creation and coding of a module, its state is initially set to UNRELEASED which will prevent other customers from seeing or accessing. If module development is finished or the module should be seen by all other customers, the release state can be set to RELEASED via the ant task or REST. The module will then be available for all customers to use.

Module Roles

Roles can be used If only a subset of customers should have access to a module. This is done the same way as setting roles to applications, with the difference being that only the READ,WRITE and DEPLOY role are used. That is, if you want only a special customer to use the module X, you can give them the DEPLOY role on this module instead of releasing the module.

Speaking in data structures, the role for a module is stored within a map in the customer with a key

module _ systemname  --> [ set of roles ]

Roles are organized hierarchically, which means that a customer with the role WRITE automatically has the READ role and a customer with the role DEPLOY automatically has the WRITE and READ roles.

Module role limitations

The following table describes the limitations of possible module roles in detail.

Module Role	Description	Effects (yambas)	Effects (dashboard)
GRANT	Customer who can give all roles except ADMIN to that module to further customers	Rights of DEPLOY, plus: Can add and remove roles for other customers
DEPLOY	The owner of the module or Customer who can modify the module, including classes and code, and in addition has the right to deploy the module	Rights of WRITE, plus: Can deploy module	classEditor Rights of WRITE, plus: can deploy
WRITE	Customer who can modify the module, including classes and code	Rights of READ, plus: Can create classes or attributes Can modify ServerCode Can modify NativeModule code	classEditor can add, edit and remove metaModels of module can add, edit and remove attributes of metaModel can download and upload native Modules from MyModules data rights depend on Application Role
READ	Customer who can use a module, but not modify it	See and use the module, even if unreleased	classEditor can not add, edit and remove metaModels of module can not add, edit and remove attributes of metaModel can not download and upload native Modules from MyModules data rights depend on Application Role

Note:

Static Modules like Facebook, Twitter or Basic Module have no special rights. Every Customer has READ rights for them.
Non static and non Native Modules ( for example: ...Main) can have rights (see table above)
Native Modules (for example: SAP) can have rights (see table above)
In Dashboard 3 the deploy mechanism is called "compile" and every native module can be compiled alone, without compiling all other modules, which are added to the app