Modules

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.