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.
| Thing | Identifier | The number counts within |
|---|---|---|
| Issue | APP-42 | Issues in project APP |
| Project page | APP-DOC-3 | Pages in project APP |
| Workspace page | DOC-3 | Pages outside every project |
| Plan | APP-PLAN-2 | Plans in project APP |
| Comment | 7 | The whole instance. Link to one with #comment-7 on its issue or page. |
| Attachment | 12 | The 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.
Upgrade from 2.0 through 2.10
Back up a Lific 2.x instance, read the notes for each newer version, replace the binary, and check the result, with release notes from 2.10 back to 2.1.
Projects
What a project holds, how its identifier is built, what each member role can do, and what deleting a project destroys.