core.modules.email¶

Attributes¶

KINDNAME

Classes¶

`EmailSkel`	This is a container-object holding information about one database entity.
`Email`	List module prototype.

Module Contents¶

core.modules.email.KINDNAME = 'viur-emails'¶

class core.modules.email.EmailSkel(*args, **kwargs)¶

Bases: viur.core.skeleton.Skeleton

This is a container-object holding information about one database entity.

It has to be sub-classed with individual information about the kindName of the entities and its specific data attributes, the so called bones. The Skeleton stores its bones in an OrderedDict-Instance, so the definition order of the contained bones remains constant.

Variables:

key (server.bones.BaseBone) – This bone stores the current database key of this entity. Assigning to this bones value is dangerous and does not affect the actual key its stored in.
creationdate (server.bones.DateBone) – The date and time where this entity has been created.
changedate (server.bones.DateBone) – The date and time of the last change to this entity.

kindName = 'viur-emails'¶: Specifies the entity kind name this Skeleton is associated with. Will be determined automatically when not explicitly set.

creationdate = None¶

changedate = None¶

name = None¶

sendDate¶

creationDate¶

sender¶

subject¶

body¶

dests¶

cc¶

bcc¶

isSend¶

errorCount¶

transportFuncResult¶

class core.modules.email.Email(*args, **kwargs)¶

Bases: viur.core.prototypes.list.List

List module prototype.

The list module prototype handles datasets in a flat list. It can be extended to filters and views to provide various use-cases.

It is undoubtedly the most frequently used prototype in any ViUR project.

kindName = 'viur-emails'¶

Name of the datastore kind that is handled by this module.

This information is used to bind a specific viur.core.skeleton.Skeleton-class to this prototype. By default, it is automatically determined from the module’s class name, so a module named Animal refers to a Skeleton named AnimalSkel and its kindName is animal.

For more information, refer to the function _resolveSkelCls().

default_order¶

Allows to specify a default order for this module, which is applied when no other order is specified.

Setting a default_order might result in the requirement of additional indexes, which are being raised and must be specified.

adminInfo()¶

This is a dict holding the information necessary for the Vi/Admin to handle this module.

name: str
Human-readable module name that will be shown in the admin tool.

handler: str (list, tree or singleton):
Allows to override the handler provided by the module. Set this only when really necessary, otherwise it can be left out and is automatically injected by the Module’s prototype.

icon: str
(Optional) Either the Shoelace icon library name or a path relative to the project’s deploy folder (e.g. /static/icons/viur.svg) for the icon used in the admin tool for this module.

columns: List[str]
(Optional) List of columns (bone names) that are displayed by default. Used only by the List handler.

filter: Dict[str, str]
(Optional) Dictionary of additional parameters that will be send along when fetching entities from the server. Can be used to filter the entities being displayed on the client-side.

display: str (“default”, “hidden” or “group”)
(Optional) “hidden” will hide the module in the admin tool’s main bar. (itwill not be accessible directly, however it’s registered with the frontend so it can be used in a relational bone). “group” will show this module in the main bar, but it will not be clickable. Clicking it will just try to expand it (assuming there are additional views defined).

preview: Union[str, Dict[str, str]]
(Optional) A url that will be opened in a new tab and is expected to display the entity selected in the table. Can be “/{{module}}/view/{{key}}”, with {{module}} and {{key}} getting replaced as needed. If more than one preview-url is needed, supply a dictionary where the key is the URL and the value the description shown to the user.

views: List[Dict[str, t.Any]]
(Optional) List of nested adminInfo like dictionaries. Used to define additional views on the module. Useful f.e. for an order module, where you want separate list of “payed orders”, “unpayed orders”, “orders waiting for shipment”, etc. If such views are defined, the top-level entry in the menu bar will expand if clicked, revealing these additional filters.

actions: List[str]
(Optional) List of actions supported by this modules. Actions can be defined by the frontend (like “add”, “edit”, “delete” or “preview”); it can be an action defined by a plugin loaded by the frontend; or it can be a so called “server side action” (see “customActions” below)

customActions: Dict[str, dict]
(Optional) A mapping of names of server-defined actions that can be used in the actions list above to their definition dictionary. See …. for more details.

disabledActions: List[str, dict]
(Optional) A list of disabled actions. The frontend will inject default actions like add or edit even if they’re not listed in actions. Listing them here will prevent that. It’s up to the frontend to decide if that action won’t be visible at all or it’s button just being disabled.

sortIndex: int
(Optional) Defines the order in which the modules will appear in the main bar in ascrending order.

indexedBones: List[str]
(Optional) List of bones, for which an (composite?) index exists in this view. This allows the fronted to signal the user that a given list can be sorted or filtered by this bone. If no additional filters are enforced by the listFilter and filter is not set, this should be all bones which are marked as indexed.

changeInvalidates: List[str]
(Optional) A list of module-names which depend on the entities handled from this module. This allows the frontend to invalidate any caches in these depended modules if the data in this module changes. Example: This module may be a list-module handling the file_rootNode entities for the file module, so a edit/add/deletion action on this module should be reflected in the rootNode-selector in the file-module itself. In this case, this property should be set to ["file"].

moduleGroup: str
(Optional) If set, should be a key of a moduleGroup defined in …. .

editViews: Dict[str, t.Any]
(Optional) If set, will embed another list-widget in the edit forms for a given entity. See …. for more details.

If this is a function, it must take no parameters and return the dictionary as shown above. This can be used to customize the appearance of the Vi/Admin to individual users.

roles¶

Allows to specify role settings for a module.

Defaults to no role definition, which ignores the module entirely in the role-system. In this case, access rights can still be set individually on the user’s access bone.

A “*” wildcard can either be used as key or as value to allow for “all roles”, or “all rights”.

# Example
roles = {
    "*": "view",                # Any role may only "view"
    "editor": ("add", "edit"),  # Role "editor" may "add" or "edit", but not "delete"
    "admin": "*",               # Role "admin" can do everything
}

canAdd()¶

Access control function for adding permission.

Checks if the current user has the permission to add a new entry.

The default behavior is: - If no user is logged in, adding is generally refused. - If the user has “root” access, adding is generally allowed. - If the user has the modules “add” permission (module-add) enabled, adding is allowed.

It should be overridden for a module-specific behavior.