Customising

Most changes need no code at all: your own fields, your own lists, added from the form that needs them. The ones that do need code have an obvious place to go.

Custom fields

Settings → Custom fields adds fields of your own to the records you keep — an account tier on a customer, a purchase order number on an invoice, a billing code on a project. The screen lists every kind of record that accepts them, each with its fields: the Label (a red star when it is required, and its help text under it), the Type, the Key it is stored under, and badges for In lists, On PDFs, Client visible and Inactive.

Fields can be added to twenty-one kinds of record:

Adding a field

1. Press Add field.
2. Fill in the form (below) and press Add field. The list reloads with the new field under its record type.

A checkbox field reads Yes or No wherever it is shown.

Changing a field

The button opens the same form. Everything can be changed except Attach to and the key, which the form shows under the label (Stored under the key …, which does not change): every value already recorded is filed under them, and changing either would quietly detach those values. Renaming the label therefore changes only what people see. Press Save changes.

Deleting a field

The button, then confirm. Deleting a field also deletes every value already recorded against it, on every record, and that cannot be undone. To stop using a field but keep what it holds, untick Active instead.

Where the fields appear

An active field appears on its record's form, and on the record's page where it has one. For the newer record types:

Printing custom fields

Tick Show on PDF documents on a field to print it. Invoices, estimates, proposals and credit notes print their own fields beside the dates at the top; contracts print theirs with the contract details; item fields print under the lines they were added as. On the other records the switch has no effect, because they have no PDF.

The lists you file things under

Seven lists decide how records are grouped, and every one of them is chosen from a dropdown somewhere in the application:

Adding one without losing your place

Every one of those dropdowns has a + beside it (its tooltip says, for example, Add project category). It opens a short form over whatever you were already filling in:

• Name — required, up to 100 characters, and not one the list already has.
• Colour — only for the lists that carry one: project categories, contract types, leave types and knowledge base categories. It starts on the list's usual colour.

Press Add. The new entry appears in the dropdown, already chosen, with the form underneath exactly as you left it. Nothing is lost and nothing has to be started again. Cancel closes the short form and changes nothing. Manage the whole list in Settings., at the foot of the short form, is a link that opens the screen where the whole list is kept, in a new tab, so the form you were filling in stays as it was.

The short form is deliberately short, and says so at its foot: Manage the whole list in Settings. Descriptions, ordering, whether a leave type is paid (a leave type added here is paid and needs approval), which department is the default (one added here never is) — all of that stays on the list's own Settings screen.

Removing one

A list entry that still has records filed under it cannot be removed. The records would keep their work but lose their grouping, quietly dropping out of every report that totals by category — and, for project categories, out of every role limited to certain ones. Move them first, then remove it.

Appearance

Settings → Appearance sets the accent colour, light or dark default and every colour around them, keeps named themes, dresses the sign-in page and adds your own CSS and JavaScript; the logos and favicon are uploaded under Settings → Company. See Appearance. The whole interface is driven by CSS custom properties, so changing the accent recolours everything consistently — including the charts.

The custom properties are declared at the top of public/assets/css/app.css. Rather than editing that file, which an update replaces, put your own rules under Appearance → Custom code.

The config files

A lot of behaviour lives in plain PHP arrays rather than in code:

Language

Every string in the interface goes through Laravel's translation helper, and the translations are JSON files in lang/. The workspace language, the languages on offer and right-to-left layout are set under Settings → Localization; adding a language of your own is described in Languages.

Adding your own module

The application is deliberately made of reusable pieces. A new module usually needs:

1. A migration with a tenant_id column.
2. A model using BelongsToTenant, and ScopedByPermission if it should respect scopes.
3. An entry in config/permissions.php.
4. An entry in config/navigation.php.
5. A controller and views, following any existing module as a template.

Traits worth knowing about:

Addresses on this page

For reference and for anyone scripting against the panel. Everything here needs somebody signed in to the workspace whose role allows it; anybody else is refused.