Background

Where a setting lives

“I set this and now it’s gone again” and “I set this once and now it’s like that everywhere” are the same question from two directions. The question is: where does this setting live?

The answer depends on whether a setting contains field names, and on who set it last.

Scopes

Everything that contains field names applies per user and project: which file, text and calendar fields the previews show, the full-text search, the filters, sorting and grouping, “pinned only”. These settings cannot be global, because a field name means nothing in another project.

Everything to do with display and formatting applies per user and globally: card density and sizes, date and number format, the labels for yes and no, the replacement text for empty values.

The split is not a matter of taste; it follows from this property: field-related means per project, display-related means global. If you remember that, you can place almost any setting yourself. The one exception is the view mode.

Levels and their precedence

A single value comes from the built-in default, the instance default or your own setting. They override each other in this order:

built-in default  <  instance default (administrator)  <  your own setting

The built-in default applies when nothing else is there, so for a fresh account in a fresh project. An administrator sets the instance default under Settings › View, so that new users do not start with US number formats and empty previews. Your own setting overrides both as soon as you change something yourself.

What matters is that precedence applies per key and not per block. If you only change the date format, you still get the number format from the instance default. A change to the instance default therefore keeps affecting every key that nobody has touched.

The view mode belongs to the project

Gallery, table or kanban contain no field name and could apply globally. Even so, each project remembers its own mode, because the right view depends on the content: you read a bibliography as a citation list, loans as a kanban, an exhibition in the wall planner. If you switch to the table in one project, you find the other projects in their own view.

A project in which you have not chosen a view yet starts in your previous default view or in the instance’s default view, otherwise in the gallery. A saved view does not carry the mode with it.

Saved views are snapshots

A saved view is a frozen bundle of the same settings. When saving, you choose which parts go into it.

It is a copy, not a reference. Changing the current settings does not change the saved view. That is why the icons show, when you hover over them, which parts match the current state.

And you can load it in any project. Field-related parts are filtered in the process: field names that do not exist in the target project silently drop out. A view Title and image only therefore works everywhere without producing errors.

Why this sometimes surprises people

The model has effects that regularly lead to questions.

Changing fields changes the quick search. It only searches the fields chosen in the view settings. If you take a field out of the preview, you take it out of the quick search as well. The full-text search is not affected; it searches everything.

And the calendar only shows the date fields chosen as calendar fields. If none is chosen, it takes the project’s first date field. If the project has no date field at all, the view stays empty even though nothing is wrong. Which calendar fields apply is stored per project, like the other view fields, even when you switch them directly in the calendar.

Further reading