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 set accessible for others using three techniques.

Static Modules

Static Modules are modules delivered with ApiOmat (statically). They are per 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 to see and access it. 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. Then, all customers can use the module.

Module Roles

If only a subset of customers should have access to a module, roles can be used. This is done the very same way like setting roles to applications, with the difference 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 instead of releasing the module give him the DEPLOY role on this module.

Speaking in data structures, the role for an 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 role WRITE has automatically the READ role and a customer with role DEPLOY has automatically 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)
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