Blog-Core framework

Fork me on GitHub

Data model

The system consists of users, roles, entry types, entries, comments and files. These are managed through the application code and through the HTTP API. The provided Admin UI uses the HTTP API and all the HTTP API permission restrictions also apply to the Admin UI. Inside the application code, users, entries and comments are accessed and managed using the Docstore API directly.

Users

Users have the following attributes:

  • $id - autogenerated uuid v4 identificator.
  • username - the user's username. Must be an email address.
  • password - the user's password. Stored as a salted hash value.
  • salt - the salt used in hash of the password.
  • type - the user's role. See roles below.
  • link - a link associated with the user.

Users are stored in the user collection in the Docstore. In the Admin UI/HTTP API, users can only be managed by users with the role admin. It is not possible to remove/demote the last admin. Users cannot change their own attributes. User with an existing entry cannot be removed.

Upon the first run, the default administrative user is created:

user{
    fullname: 'Admin',
    username: 'admin@example.com',
    password: 'admin',
    type: admin,
    link: "" }

Roles

A role consists of:

  • name - the role name. User's type refers to this.
  • label - the role label displayed in the admin UI.
  • login - flag whether the role allows log-in or not.

Roles are configured inside the application code with the bc_register_role(Name, Label, Login) predicate.

An user can have a single role only. There is a special role with the name admin which overrides all permissions.

These are the default roles:

:- bc_register_role(admin, 'Admin', true).
:- bc_register_role(author, 'Author', true).
:- bc_register_role(anon, 'Anonymous', false).

Entry types

Entry types define which kind of posts are handled by the application. They also define which roles have access to them.

An entry type consists of:

  • name - the type name. Entry's type refers to this.
  • label - label in the type selector.
  • menu_label - label in the main menu.
  • roles - list of roles that have access to entries with the type.

Entry types are configured inside the application code using the bc_register_type(Name, Label, MenuLabel, Roles) predicate.

Role-based access makes difference between the following actions:

  • create
  • read_own
  • update_own
  • remove_own
  • publish_own
  • read_any
  • update_any
  • remove_any
  • publish_any
  • files

Meaning of these permissions is described below.

These are the default entry types:

:- bc_register_type(post, 'Post', 'Posts', [
    admin(create, read_any, update_any, remove_any, publish_any, files),
    author(create, read_any, update_own, remove_own, publish_own, files)
], true).

:- bc_register_type(page, 'Page', 'Pages', [
    admin(create, read_any, update_any, remove_any, publish_any, files),
    author(create, read_any, update_own, remove_own, publish_own, files)
], false).

:- bc_register_type(block, 'Block', 'Blocks', [
    admin(create, read_any, update_any, remove_any, publish_any, files),
    author(create, read_any, update_own, remove_own, publish_own, files)
], false).

Entries

Entries are the main content elements of the system. They have the following attributes:

  • $id - autogenerated uuid v4 identificator.
  • author - reference to the author's user $id.
  • title - the entry title.
  • slug - title converted for usage in URLs.
  • tags - list of tags (atoms)
  • date_published - Unix timestamp of the publish date.
  • date_updated - Unix timestamp of the latest update date.
  • commenting - indicates whether commenting is enabled (true/false).
  • published - indicates whether the entry is published (true/false).
  • content - the entry contents.
  • content_type - indicates the content type of the content (markdown/raw).
  • description - the entry description.
  • type - the entry type, refers to one of the Entry types above.
  • language - IETF language identifier.

Entries are stored in the entry collection in the Docstore. In the Admin UI/HTTP API, the user must have these permissions to create an entry:

  • The user's role has create access to the entry type.

To update (remove):

  • The user's role has update_own (remove_own) access to the entry type.
  • The user is the author of the entry.

Or

  • The user's role has update_any (remove_any) access to the entry type.

And to read/list an entry:

  • The user's role has read_own access to the entry type.
  • The user is the author of the entry.

Or

  • The user's role has read_any access to the entry type.

The admin role on the user overrides the access rules.

Comments

Comments are associated with entries and other comments. Comment attributes.

  • $id - autogenerated uuid v4 identificator.
  • post - reference to the entry.
  • author - name of the author (string).
  • content - comment's content (processed as span-level Markdown).
  • reply_to - reference to the parent comment. Can be not set.
  • email - author's email. Can be not set.
  • site - link to author's site. Can be not set.
  • notify - boolean whether the comment author accepts notifications. Can be not set.

Comments can be added through HTTP API by anyone, provided that the entry and the entry type has commenting set. A comment tree can be read by anyone. A comment and its replies can be removed by the user that has the associated entry update permission.

Files

Files are associated with the given entry through its slug. They are put into the directory public/Slug when uploaded. Subdirectories cannot be created.

To upload a file onto the entry, the user must have the following access:

  • The user's role has files permission for the type.
  • The user has update access for the entry.

The admin role on the user overrides the access rules.

All files and directories in the public directory are publicly served and thus all uploaded files are publicly served under the URL pattern /Slug/FileName.