Expand `types.json` with display name and suggestion options

Feature requests
1

Use case or problem

With the introduction of the Bases feature in version 1.9, it’s now possible to define a custom display name for properties in table headers. This helps improve readability, particularly for property keys with spaces or specific aesthetic requirements.

However, this feature is currently limited to the table view. When the “Properties in document” option is enabled, property keys are still displayed verbatim. This creates an inconsistency between how properties appear in tables versus inside notes.

Moreover, the current types.json format is underutilized and could serve as a centralized schema definition for additional metadata such as display names or constrained value suggestions.

Proposed solution

Expand the types.json file with the following structure:

{
  "types": {
    "status": {
      type: "multitext",
      display: "Completion Status",
      suggest: ["Completed", "Todo", "Dropped"]
    },
    ...
  }
}

This would enable:

  1. Display name unification – The display field would apply to both table views and in-note property rendering.

  2. Controlled vocabulary – The suggest field could offer predefined options for multit-select types, reducing entry errors and improving consistency.

4 Likes
2

In addition to this, properties could have a hidden boolean option, to hide them inside of the property table. This is a common use case of the Metadata Hider plugin:

{
  "types": {
    "cssclasses": {
      type: "multitext",
      hidden: true
    },
    ...
  }
}

This new syntax would allow for easy addition of new features regarding properties in the future.

2 Likes
3

Support! :purple_heart: Bases could treat these display names as a default column name, while still allowing the user to rename them on individual views.

For example: If you use a simple ✅ Finished property across a media-tracking vault, you might want that column to appear as ✅ Watched in a table of movies, or ✅ Listened in a table of albums.

1 Like
4

This would also solve the following problem I experience:

Currently, I’m using a simple status property, with the values Completed, To Read and To Watch, for both of my movies and book database. Obsidian will show suggestions for all three values, meaning that I also get suggested To Watch for my books, and To Read for my movie notes because they share the same property name.

I could solve this by renaming the properties to book-status and movie-status, at the expanse of aesthetics (because I’d like it to show just “Status” as a property). With this feature, I could easily rename the properties while keeping the display name, to allow for better multi-select suggestions.