General¶

This section explains concepts that are reused across multiple modules. When a Cards, Templates, or Bulletins procedure refers to one of these concepts, follow the linked explanation here.

Access configuration (`access_config`)¶

Cards, Templates, Bulletins, and Visual Resources can restrict who can use or see an item. The saved configuration uses an access_config object.

Access type	Meaning	`allowed_groups`
`public`	Available to users who can access the corresponding module.	Usually empty.
`restricted`	Available only to selected groups.	Contains one or more group IDs.

Example:

{
  "access_config": {
    "access_type": "restricted",
    "allowed_groups": ["group-colombia-editors", "group-guatemala-editors"]
  }
}

Style configuration (`style_config`)¶

The frontend type is named StyleConfig; in saved JSON it normally appears under the key style_config. style_config is the shared styling object used by Templates, Cards, Bulletin content, sections, blocks, headers, footers, fields, lists, and some field-specific elements. It lets the interface store presentation rules without embedding them directly in the content value.

How style inheritance works¶

Styles can be defined at several levels. A lower level can override the value inherited from a higher level.

Typical order: global Template/Bulletin style → section → header/footer or block → field → field-specific sub-element.

For example, a Template may define font: "Arial" globally. A specific section can inherit Arial without storing its own font. A single field can then override that value with font: "Roboto".

When the editor shows an Inherited value, the property comes from a parent style and does not need to be duplicated on the current element.

Text and color properties¶

JSON property	Interface purpose
`font`	Font family. The supplied editor includes Arial, Helvetica, Times New Roman, Georgia, Poppins, Roboto, Open Sans, Lato, Montserrat, Archivo Light, and Archivo Narrow.
`color`	Text color.
`primary_color`	Primary contextual color used by components and icons.
`secondary_color`	Secondary contextual color.
`background_color`	Element background color.
`background_opacity`	Background transparency where supported.
`background_image`	Selected background image URL.
`font_size`	Text size in pixels.
`font_weight`	Font weight, such as `400` or `700`.
`line_height`	Line-height value.
`word_space`	Word spacing.
`font_style`	`normal` or `italic`.
`text_decoration`	`none`, `underline`, or `line-through`.
`text_align`	`left`, `center`, or `right`.

Spacing, border, and size properties¶

JSON property	Interface purpose
`padding`	Internal spacing, entered as a CSS-style value such as `16px` or `10px 20px`.
`margin`	External spacing.
`gap`	Space between child elements or fields.
`border_color`	Border color.
`border_width`	Border width.
`border_style`	Border style where supported.
`border_radius`	Corner radius.
`border_sides`	Border sides to display. The editor can store `all` or a comma-separated combination such as `top,bottom`.
`bulletin_width`	Global bulletin width in pixels.
`bulletin_height`	Global bulletin height in pixels.

Layout properties¶

JSON property	Values / purpose
`fields_layout`	`horizontal` or `vertical`.
`justify_content`	`start`, `end`, `center`, `between`, `around`, or `evenly`.
`align_items`	`start`, `end`, `center`, or `stretch`.
`list_style_type`	`disc`, `circle`, `square`, `none`, or `decimal`.
`list_items_layout`	`vertical`, `horizontal`, `grid-2`, `grid-3`, or `table`.
`show_table_header`	Shows or hides a header when a list uses table layout.
`header_background_color`	Table header background color.
`header_text_color`	Table header text color.
`header_font_size`	Table header font size.
`header_font_weight`	Table header font weight.
`icon_size`	Icon size in pixels.
`icon_use_original_color`	Keeps the icon's original color instead of applying the contextual primary color.

Example:

{
  "style_config": {
    "font": "Arial",
    "color": "#283618",
    "background_color": "#fefae0",
    "font_size": 18,
    "font_weight": "700",
    "padding": "12px 16px",
    "gap": "8px",
    "border_color": "#606c38",
    "border_width": "1px",
    "border_style": "solid",
    "border_radius": "8px",
    "fields_layout": "horizontal",
    "justify_content": "between",
    "align_items": "center"
  }
}

Tip

Apply broad styling at the highest useful level, then override only the exceptions. This produces smaller, easier-to-maintain JSON and keeps the visual system consistent.

Content hierarchy¶

Templates, Cards, and Bulletins reuse the same content concepts.

Header and footer¶

A global header or footer contains optional styles and a list of fields. Templates can also define a section-specific header or footer. When a section is customized, its local header/footer takes priority over the global one for that section.

Section¶

A section is a top-level page or content area in a Template or Bulletin. A section can contain:

section_id and display_name;
background images and a section icon;
order;
style configuration;
blocks;
a section-specific header and footer;
repeatable, which allows the Bulletin author to create multiple pages from the same section;
skippable, which allows the section to disappear from review, export, and publication when every editable field is left empty.

Block¶

A block groups related fields. It has a block_id, display_name, optional icon, optional print configuration, a style configuration, and fields.

Field¶

A field defines what the author enters and what the final bulletin can display. Common properties include:

Property	Meaning
`field_id`	Stable field identifier.
`display_name`	Human-readable name shown in the editor.
`type`	Field type.
`description`	Guidance for the person entering content.
`label`	Label displayed with the value when configured.
`form`	Whether the field is editable in the Bulletin form.
`bulletin`	Whether the field is shown in the final bulletin.
`print`	Optional print behavior.
`style_config`	Field-level style configuration.
`validation`	Required/min/max rules.
`field_config`	Type-specific configuration.
`value`	The actual Bulletin or fixed Card value, when applicable.

Field types¶

The supplied frontend supports the following field types. The exact configuration controls shown by the editor depend on the selected type.

Type	Typical use
`text`	Short or long text.
`text_with_icon`	Text with an icon selected from configured icon options.
`climate_data_puntual`	Structured climate parameters with labels, units, data types, and optional per-parameter styles.
`list`	Repeatable rows/items, with optional CSV import and vertical, horizontal, grid, or table display.
`select`	Selection from fixed options, optionally multiple.
`searchable`	Searchable choice list.
`select_with_icons`	Fixed options paired with icons.
`select_background`	Fixed options paired with background images.
`number`	Numeric value with numeric validation.
`date`	Single date with configurable display format.
`date_range`	Start/end dates with optional moon-phase behavior.
`image_upload`	Image supplied while completing the bulletin.
`page_number`	Page numbering, normally auto-generated.
`card`	Inserts one of the Cards available for the configured card type/tags.
`image`	Chooses from a configured list of images.
`moon_calendar`	Moon-calendar visual field.

Validation rules¶

Fields can store these validation rules:

{
  "validation": {
    "required": true,
    "min_length": 10,
    "max_length": 500,
    "min_value": 0,
    "max_value": 100,
    "decimal_places": 1
  }
}

Only rules that make sense for the selected field type are normally used. Bulletin navigation and export can be blocked when required fields or list minimums have not been satisfied.

Master and version records¶

Templates and Bulletins separate long-lived identity from versioned content.

Master¶

The master stores identity and lifecycle information: name, machine name, description, access, status, current version ID, thumbnails, and audit information.

Version¶

A version stores the editable structure/content for one revision and includes a version number, commit message, previous version ID, and audit log.

The key difference is important:

Template version → version.content
Bulletin version → version.data

A Bulletin also stores base_template_master_id and base_template_version_id, so its origin can be traced back to the exact Template version used when it was created.

When a Template is edited and saved, the frontend creates a new Template version instead of overwriting the previous version. The master then points to the newest version.

Audit information (`log`)¶

Most saved records include a log object. The backend normally supplies this information; users do not type it manually.

{
  "log": {
    "created_at": "2026-08-12T09:00:00-05:00",
    "creator_user_id": "user-102",
    "creator_first_name": "Ana",
    "creator_last_name": "Gomez",
    "updated_at": "2026-08-12T09:20:00-05:00",
    "updater_user_id": "user-102",
    "updater_first_name": "Ana",
    "updater_last_name": "Gomez"
  }
}

The list screens use this information to show creator/updater details and modification dates where applicable.