Modules
4 minute read
Under Construction
This page is under construction.Modules are blueprints for the main data entries, called “entities”. You can define a module for “invoices”, for example, whose entities, the individual invoices, all conform to this blueprint. Modules are therefore basically like database schemas. In fact, each module has its own database table in Brezel.
Modules mainly consist of a name, the fields, and a type. The fields are the properties of entities, and can be thought of columns in a database table. In practice, fields often correspond to a database column, but for some types of fields, the data may be stored in separate tables.
Fields
The different field types will be listed here.
Type
Most modules you will use are just of type module, which means that they are normal entities without special function.
Some modules are treated differently by Brezel, and their entities are therefore often stored and accessed in a specialized way.
For example, modules of type users always have email and password fields, and these can be used to log into Brezel.
Entities in modules of type files appear in the Brezel file manager, and can be read and written to by workflows
.
Entities are stored in a module base table, and in a module fields table.
Custom fields add columns in the fields table, while basic fields required by the module type are stored in the base table.
Whereas normal modules of type module have their entities stored in the resources and the resource_<name> tables, user entities are stored in users and resource_<name> tables.
Types
module (default)
The default module type. No special functions.
users
Represents users that can log in to the API and use Brezel.
files
Entities that can store arbitrary file data.
views
Entities that can be used by workflows to render mails, PDFs or other data using templating engines like Twig.
Options
| Option | Type | Usage |
|---|---|---|
| shared | bool = false | If true, all entities in this module are accessible across all clients. Permissions are still respected |
| global | bool = false | If true, all entities in this module owned by the global client will be available for other clients, but resources created by them are only visible to the creating client (and global as it can see everything). Permissions are still respected |
| webauthn | bool = false | (Only in User modules) Enables webauthn support |
| two_factor | object = null | (Only in User modules) Controls if and how two factor is required / handled |
| capabilities | Array<string> = [] | Automatically adds fields for bases on the requirements of the specified capabilities. See Capabilities for more details. |
| emailNeedsVerification | string = null | Whether or not the email needs to be verified before logins are allowed. A template called verifyEmailView is required. |
| returnUrl | string = null | Used in conjunction with emailNeedsVerification and allows custom verify urls. |
| global_login | string | Controls how and if login requests for the global client are handled/accepted |
Capabilities
Sometimes, Brezel must be sure that certain conditions are fulfilled by entities, but is indifferent to what type they are.
For example, a workflow element may require to work with an entity that has a name field to provide a certain service.
In OOP terms, while module types are like parent classes, capabilities are like interfaces, because a module of any type can fulfill the requirements.
Another useful feature of assigning capabilities to modules is that the Bakery Planner can make sure that your configuration has the required fields and adds them, should you do not explicitly specify them.
Example:
[
{
"resource_module": "pages",
"resource": {
"identifier": "pages",
"type": "module",
"icon": "file",
"title": "name",
"options": {
"capabilities": [
"PageDepotPage"
]
}
}
}
]
You can also add fields, or overwrite fields defined by the capabilities you use.
SiteBuilderTemplate
See SiteBuilderTemplate .
PageDepotTemplate
See PageDepotTemplate .
PageDepotLayout
See PageDepotLayout .
PageDepotPage
See PageDepotPage .
PageDepotSection
See PageDepotSection .