Feature Request: Location‑Based Row Visibility for Embedded Tables

Edit completely re-written with the help of AI to clarify the needs.

---

Feature Request: Location‑Based Row Visibility for Embedded Tables

Problem Description

Organizations often need to enforce procedures and rules across multiple teams while keeping certain data isolated. Nextcloud already provides strong file‑level permissions for reading and writing, but the Tables app lacks a way to dynamically filter table rows based on where the table is embedded.

Today, when a table is embedded into a file, the embedded view always uses the filter defined in the table’s settings. This forces administrators to create many separate filtered views—one per team, per file, or per folder—just to control which rows appear in each embedded instance.

This becomes unmanageable when the same table must be reused across many locations while showing different subsets of data.

---

Proposed Solution

1. Introduce a New Filter Type: “Location‑Based View”

Add a new type of filtered view that automatically filters rows based on the file or folder in which the table is embedded.

2. Add a New Column Type: “File/Folder Visibility”

Each row would include a new column type where users can assign one or more file or folder locations. These locations determine where the row is visible when the table is embedded.

• If a folder is selected:
  The row becomes visible in any file inside that folder that embeds the table.

• If a file is selected:
  The row becomes visible only in that specific file.

• If no location is set:
  The row is visible only in the full table view inside the Tables app, not in any embedded instance.

3. Behavior When Embedding a Table

When a table is embedded into a file:

• The embedded view automatically applies the “Location‑Based View”.
• Only rows whose “File/Folder Visibility” column matches the file’s location are shown.
• No additional filtered views need to be created manually.

This dramatically reduces the number of filtered views required.

---

Example Use Case

Context

To comply with GDPR, an organization wants to track contacts in a centralized table but ensure that each team only sees its own contacts.

Setup

1. Create a single “Contacts” table in the Tables app.
2. In /Collectives/, create four folders, each containing a file named File A:
   • /project nextcloud/File A
   • /project super top/File A
   • /huh/File A
   • /why not/File A
3. Embed the Contacts table into each File A.

Row Creation

When a user adds a new row from within an embedded table:

• The system automatically sets the “File/Folder Visibility” column to the file’s location.
• Example:
  • Contact 1 created in /project nextcloud/File A
  • Contact 2 created in /project super top/File A
  • Contact 3 created in /huh/File A
  • Contact 4 created in /why not/File A

Each team sees only its own contacts, even though all data lives in one centralized table.

Additional Views

• Create a new file E in /Collectives/ and embed the table.
  → All contacts become visible because the folder /Collectives/ contains all subfolders.

• Create a new file J in /Collectives/ with an additional filter “folder name contains ‘project’”.
  → Only contacts 1 and 2 appear.

---

Benefits

• Massively reduces the number of filtered views needed.
• Allows a single table to serve many teams without exposing data across teams.
• Enables dynamic, context‑aware filtering based on where the table is embedded.
• Supports GDPR workflows by centralizing data while controlling visibility.
• Makes embedded tables far more powerful and flexible.

---

The issue names no files, tests, or code entry points. Start by mapping the existing embedded-table behavior, filtered views, and column types against the proposed location rules. Done would require an agreed design for file and folder matching, row creation, and embedded visibility, followed by implementation and tests.