Utility Views

All Fields

The All Fields view is a flat, read-only table of every field in the project, regardless of which bundle it belongs to. Open it from the project sidebar.

Columns

Each row shows:

• Bundle — the parent bundle the field belongs to, along with its type (e.g. Content Type, Media Type, Paragraph Type)
• Label — the human-readable field name
• Machine Name — the Drupal machine name, plus sharing badges (see below)
• Field Type — the Drupal field type (Text, Entity Reference, Image, etc.)
• Widget — the form widget assigned to the field
• Required — whether the field is required
• Cardinality — the number of allowed values (1, a specific number, or unlimited)

Searching and sorting

Use the Filter fields search box to narrow the table by label, machine name, bundle name, or field type. Click any column header to sort ascending or descending.

Sharing classification

When two or more fields share the same machine name on the same entity type, Drupal forces them onto a single field storage config object. Strata classifies each field into one of three states:

• Unique — no other field uses this machine name. No badge is shown.
• Shared (blue badge) — this field was deliberately reused from another bundle via the Reuse field action. The reuse relationship is recorded with a reused_from marker that points to the group's root field — it is never inferred from machine names alone.
• Collision (amber badge) — another field uses the same machine name but is not part of the same reuse group. This is an accidental clash: Drupal will force both fields onto the same storage even though no one intended it. Collisions should be investigated and resolved by renaming one of the fields or converting one to an explicit reuse.

A field can carry both badges at once. For example, if field_body is deliberately shared between Article and Page, but a third, unrelated field_body was typed by hand on Blog Post, the first two fields are both shared and in collision with the third.

Field detail dialog

Click any row to open a detail dialog that shows every configured property for that field. From the dialog footer you can jump directly to the field's parent bundle to edit it.

All Permissions

The All Permissions view aggregates the per-bundle permission entries into a single read-only matrix. It pulls permissions from three entity types:

• Content Types — permissions on node bundles
• Media Types — permissions on media bundles
• Taxonomy Vocabularies — permissions on vocabulary bundles

Reading the matrix

Each row represents a single role’s permissions on a single bundle. The first two columns identify the row:

• Bundle — the bundle name and its type (e.g. Content Type, Media Type)
• Role — the user role these permissions apply to, resolved from the project's User Roles tab

The remaining columns are boolean permission flags. For content types and media types the columns are:

• Create, Edit Own, Edit Any, Delete Own, Delete Any
• View Revisions, Revert Revisions

For taxonomy vocabularies the columns are:

• Create Terms, Edit Terms, Delete Terms

Filtering and searching

Use the type dropdown to filter by permission type (Content Type, Media Type, or Vocabulary). The search box filters across bundle name, role name, permission type, and bundle type. Column headers are sortable.

Field Audit

The Field Audit runs automated consistency checks against every field in the project and reports findings grouped by severity. It is read-only and runs on page load — there is nothing to configure.

Severity levels

Each finding is classified at one of three severity levels:

Findings are sorted by severity (errors first, then warnings, then suggestions) so the most critical issues appear at the top.

Audit categories

The audit checks nine categories of field quality:

Filtering and expanding findings

Use the severity and category dropdowns to narrow the findings list. A summary bar at the top shows how many errors, warnings, and suggestions were found. Click any finding to expand it and see the affected fields with their specific values.

Acting on findings

The audit is read-only — it does not modify your fields. To resolve a finding, navigate to the bundle where the field lives (use the sidebar or the All Fields detail dialog) and edit the field directly. Re-open the Field Audit page after making changes to confirm the finding is resolved.

When the audit finds no issues it displays a clean No issues found summary, confirming that all fields pass every check.

Architecture quality

Together, these three views form a quality layer over your content model:

• All Fields answers “what do we have?” — a single place to search, sort, and review every field without navigating into each bundle individually. The sharing badges surface accidental machine-name collisions before they reach Drupal.
• All Permissions answers “who can do what?” — a consolidated matrix that makes it easy to spot missing permissions or overly broad access across all bundles and roles at once.
• Field Audit answers “is it consistent?” — automated checks catch naming mistakes, type mismatches, and inconsistent configuration before you export and sync to Drupal.

Running the audit before committing a changeset or exporting your manifest is a good habit. It is especially valuable on larger projects where multiple team members are adding fields in parallel and cross-bundle consistency is harder to maintain by hand.