Lific
Concepts

Concepts

A map of Lific's data model, the identifiers that name each piece, who can change what, and what happens when something is deleted.

Almost everything in Lific lives inside a project. A project owns its issues, pages and plans, the modules and labels used to sort them, the folders its pages sit in, and the list of people allowed to see any of it.

  • An issue is one piece of work. Issues are flat: there are no sub-issues. They can block, duplicate or relate to each other, across projects too.
  • A page is Markdown documentation. Project pages sit in folders; workspace pages belong to no project.
  • A plan is a tree of steps, which is where hierarchy lives. A step can mirror an issue, so finishing the issue checks the step off.
  • A module is an area of a project, and an issue belongs to at most one. A label is a tag, and an issue or project page can carry any number.
  • A comment belongs to exactly one issue or one page. The activity log records every change to all of the above.
  • An attachment is an uploaded file that an issue, page or comment links to from its Markdown.

Identifiers

Issues, pages and plans have short identifiers built from the project's identifier, so you can type them into a prompt or paste them into a commit message.

ThingIdentifierThe number counts within
IssueAPP-42Issues in project APP
Project pageAPP-DOC-3Pages in project APP
Workspace pageDOC-3Pages outside every project
PlanAPP-PLAN-2Plans in project APP
Comment7The whole instance. Link to one with #comment-7 on its issue or page.
Attachment12The whole instance. Bodies reference it as /api/attachments/12.

A project identifier is one to five characters: an uppercase letter, then uppercase letters or digits. DOC is reserved for workspace pages. The project half of an identifier is matched without case, so app-42 finds APP-42; the DOC and PLAN parts must be written in capitals.

Modules, labels and folders have no identifier. Tools refer to them by name within a project. Label names are unique within a project; module and folder names are not, so give them distinct names if you address them by name.

Who can change what

Access is granted per project. Each member holds one role, viewer, maintainer or lead, and instance administrators pass every project check. Whether roles are enforced at all is the instance setting authz_enforced, which is on for new installs. Members and roles explains the roles and what changes when enforcement is off. Each concept page lists the role its own operations need.

Deleting

Issues, pages and comments go to the trash. They vanish from lists, search, boards and public projects at once, and a maintainer can restore an issue or page, with its comments, for 30 days. After that the retention sweep removes them for good. trash_days in the [retention] section sets the window.

Everything else is deleted immediately, with no trash: projects, plans and plan steps, modules, labels, folders and attachments. What each deletion takes with it is described on the page for that thing. None of this replaces a backup.

On this page