Record ownership is one of the most powerful and commonly used security patterns in Tadabase. It allows you to link records to specific users, ensuring that users can only access and modify their own data. In this article, you'll learn to implement comprehensive ownership-based security for user-specific data access.

Record ownership creates a relationship between a record and a user, giving that user special permissions for that specific record.

Ownership Concept

Think of it like owning a file on your computer:

• You can view files you own
• You can edit files you own
• You cannot see files owned by others (unless given permission)
• Admins can see and edit all files

How Ownership Works

1. Link Records to Users - Add a connection field to Users table
2. Auto-Assign Owner - When user creates record, they become owner
3. Filter by Owner - Users see only their own records
4. Restrict Editing - Users can only edit their own records
5. Admin Override - Admins can see/edit all records

Let's implement ownership step by step.

Step 1: Add Owner Field

1. Go to Data Builder
2. Open the table where you want ownership (e.g., "Tasks")
3. Click "Add Field"
4. Select "Connection" field type
5. Name it "Owner" or "Created By"
6. Connect to: Users table
7. Connection type: Many to One (many tasks can have one owner)
8. Enable "Auto-fill with logged in user"
9. Save

Step 2: Filter by Owner

Create pages that show only owned records:

1. Create or edit a page (e.g., "My Tasks")
2. Add a Table Component
3. Data source: Tasks table
4. Add a Filter:
   • Field: Owner
   • Operator: =
   • Value: Logged In User
5. Save

Now users only see tasks they own.

Step 3: Restrict Editing

Ensure users can only edit their own records:

1. Create or edit a details/form page
2. Add page rule or component filter:
   • Show edit form only if: Owner = Logged In User
   • OR Role = Admin (admins can edit everything)
3. If condition fails, show read-only details or redirect

Step 4: Test Ownership

1. Create test users (User A, User B, Admin)
2. Log in as User A, create some records
3. Log in as User B, verify they don't see User A's records
4. Create records as User B
5. Log in as Admin, verify admin sees all records

Different ways to implement ownership for various scenarios.

Pattern 1: Created By

User who created the record owns it permanently.

Implementation

• Field: "Created By" (connection to Users)
• Auto-fill: Logged in user
• Not editable (can't change owner)
• Used for: Audit trails, permanent ownership

Example: Expense Reports

• Employee creates expense report
• They own it permanently
• They can edit their expense report
• Manager can view/approve but not change owner
• Finance processes approved expenses

Pattern 2: Assigned To

Ownership can be transferred/reassigned.

Implementation

• Field: "Assigned To" (connection to Users)
• Initially auto-filled with logged in user
• Editable by managers/admins
• Used for: Tasks, tickets, work items

Example: Support Tickets

• Customer creates ticket (assigned to themselves)
• Support admin assigns to support agent
• Agent now owns the ticket
• Agent can work on and close ticket
• Can be reassigned to another agent if needed

Pattern 3: Multiple Owners

Record can have multiple owners/collaborators.

Implementation

• Field: "Team Members" (connection to Users)
• Connection type: Many to Many
• Can select multiple users
• Used for: Projects, shared documents

Example: Projects

• Project has multiple team members
• All team members can view/edit project
• Filter: Team Members includes Logged In User
• Collaborative access

Pattern 4: Hierarchical Ownership

Ownership follows organizational hierarchy.

Implementation

• Field: "Owner" (connection to Users)
• Users table has "Manager" field (connection to Users)
• Filter: Owner = Logged In User OR Owner's Manager = Logged In User
• Used for: Manager oversight

Example: Sales Pipeline

• Sales rep owns their leads
• Sales manager sees their team's leads
• VP Sales sees all sales leads
• Hierarchical visibility

Pattern 5: Department/Group Ownership

Ownership at group level, not individual.

Implementation

• Field: "Department" (connection to Departments table)
• Filter: Department = Logged In User's Department
• All department members can access
• Used for: Shared resources, department data

Example: Department Files

• Files uploaded by department
• All department members can access
• Other departments cannot see
• Admins see everything

Restricting edit permissions to owners.

Method 1: Page-Level Restriction

Use page rules to control access to edit pages.

Edit Page Rule

1. Create edit page for records
2. Add page rule:
   • Condition: Page Criteria's Owner = Logged In User
   • OR: Role = Admin
3. If fails: Redirect to view-only page or show error

Method 2: Component-Level Restriction

Show form only to owners.

Conditional Form Display

1. Add both Details (read-only) and Form (editable) components to same page
2. Details component: Always visible
3. Form component:
   • Display rule: Show if Owner = Logged In User OR Role = Admin
   • Hide if condition fails
4. Result: Owners see edit form, others see read-only details

Method 3: Action Link Restriction

Show edit button only to owners.

Conditional Action Links

1. In table component, add "Edit" action link
2. Link permissions:
   • Show if: Owner = Logged In User
   • OR: Role = Admin
3. Edit button appears only for records user owns

Example: Task Management

My Tasks Page

Table Component:
- Filter: Owner = Logged In User
- Columns: Task Name, Status, Due Date
- Action Links:
  - View (everyone can view their tasks)
  - Edit (only for tasks with Status = "Draft" or "In Progress")
  - Delete (only for tasks with Status = "Draft")

Task Details Page

Page Rule:
- Access: Owner = Logged In User OR Role = Manager/Admin

Components:
- Details Component (always visible)
  - Task Name, Description, Status, Due Date, Owner

- Edit Form (conditional)
  - Display if: Owner = Logged In User AND Status != "Completed"
  - OR: Role = Admin
  - Fields: Task Name, Description, Status, Due Date

Result:
- Owners can edit their open tasks
- Completed tasks are read-only
- Admins can always edit
- Non-owners cannot access the page

Admins should always be able to access all records.

Implementing Admin Override

In every ownership filter, include admin exception:

Filter Logic:
(Owner = Logged In User)
OR
(Role = Admin)

Example Filters with Admin Override

Table Filter

1. Add filter: Owner = Logged In User
2. Add second filter: Role = Admin
3. Combine with OR logic
4. Admins see all records, others see only theirs

Page Rule with Override

Page Access Rule:
Allow access if:
  (Page Criteria's Owner = Logged In User)
  OR
  (Logged In User's Role = Admin)
  OR
  (Logged In User's Role = Manager)

Multiple Override Roles

Sometimes multiple roles need override access:

• Admin - Complete override, sees everything
• Manager - Sees team's records
• Support - Read-only access to all records
• Auditor - Read-only access with no editing

Example: Support Access

Filter for Table:
Show records where:
  (Owner = Logged In User)
  OR
  (Role = Admin)
  OR
  (Role = Support)

Form Display Rule:
Show edit form if:
  (Owner = Logged In User)
  OR
  (Role = Admin)

Note: Support can view all but not edit

Allow owners to share records with others.

Method 1: Share with Specific Users

Implementation

1. Add field: "Shared With" (connection to Users, Many to Many)
2. Owner can select users to share with
3. Filter: Owner = Logged In User OR Shared With includes Logged In User
4. Shared users have view/edit access

Example: Shared Documents

Document Table Fields:
- Name
- Owner (connection to Users)
- Shared With (connection to Users, many-to-many)

Access Filter:
Show documents where:
  (Owner = Logged In User)
  OR
  (Shared With includes Logged In User)
  OR
  (Role = Admin)

Method 2: Share with Role/Department

Implementation

1. Add field: "Share with Department" (yes/no checkbox)
2. Filter: Owner = Logged In User
3. OR: (Share with Department = Yes AND Department = Logged In User's Department)
4. Department-wide sharing

Method 3: Public vs. Private

Implementation

1. Add field: "Visibility" (dropdown: Private, Team, Public)
2. Filters based on selection:
   • Private: Owner only
   • Team: Owner's team/department
   • Public: Everyone

Example: Knowledge Base Articles

Article Fields:
- Title
- Content
- Owner
- Visibility (Private/Team/Public)

Filter Logic:
Show if:
  (Visibility = Public)
  OR
  (Visibility = Team AND Department = User's Department)
  OR
  (Visibility = Private AND Owner = Logged In User)
  OR
  (Role = Admin)

Permission Levels

Different access levels for shared records:

Permission	Owner	Shared (Edit)	Shared (View)	Admin
View	✓	✓	✓	✓
Edit	✓	✓	-	✓
Delete	✓	-	-	✓
Share	✓	-	-	✓
Change Owner	✓	-	-	✓

Implementation

1. Add fields:
   • Shared With Edit (connection to Users)
   • Shared With View (connection to Users)
2. Configure permissions based on which field user is in

Allow changing record owners.

When to Allow Transfers

• User Leaves - Transfer their records to someone else
• Reassignment - Move tasks to different team member
• Workload Balancing - Distribute work evenly
• Escalation - Move to senior team member

Method 1: Admin Transfer

Implementation

1. Make "Owner" field editable only by Admin role
2. In form component, set field permission:
   • Field: Owner
   • Editable by: Admin only
   • Read-only for: Everyone else
3. Only admins can change owner

Method 2: Manager Transfer

Implementation

1. Managers can reassign within their team
2. Form field permission:
   • Field: Assigned To
   • Editable by: Admin, Manager
   • Options limited to manager's team members

Method 3: Self-Transfer

Implementation

1. Add "Transfer Ownership" action link
2. Opens form to select new owner
3. Current owner selects new owner
4. Updates Owner field
5. Current owner loses access (unless shared)

Tracking Ownership Changes

Keep audit trail of ownership transfers:

1. Add fields:
   • Previous Owner (connection to Users)
   • Ownership Changed Date
   • Ownership Changed By
2. Use record rules to populate when Owner changes
3. Maintain history of ownership

Real-world ownership examples.

Scenario 1: Multi-Stage Workflow

Ownership changes as record moves through workflow

Example: Purchase Requests

1. Employee creates request - Owner: Employee
2. Manager reviews - Owner: Manager (for approval)
3. Finance processes - Owner: Finance (for payment)
4. Completed - Owner: Original employee (for reference)

Implementation

• Field: "Current Owner" (changes as status changes)
• Field: "Requester" (original employee, never changes)
• Field: "Status" (Draft, Pending Approval, Approved, Processing, Completed)
• Record rules update owner based on status changes

Scenario 2: Customer Accounts with Rep Assignment

Customers assigned to sales reps, with manager oversight

Structure

• Customers table has "Account Owner" (connection to Users)
• Users table has "Manager" (connection to Users)
• Customers table has "Account Team" (many-to-many to Users)

Access Rules

• Account Owner - Full access to their customers
• Account Team - Can view and collaborate
• Manager - Can see their reps' customers
• Admin - Can see all customers

Filter

Show customers where:
  (Account Owner = Logged In User)
  OR
  (Account Team includes Logged In User)
  OR
  (Account Owner's Manager = Logged In User)
  OR
  (Role = Admin)

Scenario 3: Project Hierarchy

Projects with tasks, owner at both levels

Structure

• Projects table: Project Owner
• Tasks table: Task Owner, Connected to Projects

Access Logic

• Project View:
  • Project Owner can see project
  • OR user owns any task in project
  • OR user is on project team
• Task View:
  • Task Owner can see task
  • OR Project Owner can see all tasks in their project

Scenario 4: Tenant-Based Ownership

SaaS application with complete data isolation

Structure

• Companies table (tenants)
• Users table: Company (connection)
• All data tables: Company (connection)

Ownership Layers

1. Company Level - All users in company see company data
2. User Level - Within company, users see only their records
3. Shared Level - Company members can share with each other

Filter

Show records where:
  (Company = Logged In User's Company) [Company-level access]
  AND
  (
    (Owner = Logged In User) [User-level]
    OR
    (Shared With includes Logged In User) [Shared]
    OR
    (Role = Company Admin) [Company admin override]
  )
  OR
  (Role = Super Admin) [Platform admin override]

Covered in detail in next article.

Follow these guidelines for effective ownership:

1. Always Include Owner Field

• Even if not used immediately for filtering
• Valuable for audit trails
• Can enable ownership features later
• Helps with reporting and analytics

2. Auto-Fill Owner

• Enable "Auto-fill with logged in user"
• Prevents users from creating records for others
• Ensures accurate ownership
• Reduces errors

3. Separate Created By and Owner

• "Created By" - Never changes, audit field
• "Owner" / "Assigned To" - Can be transferred
• Both are useful for different purposes
• Maintain complete history

4. Always Include Admin Override

• Every ownership filter should include admin exception
• Prevents admins from being locked out
• Essential for maintenance and support
• Include in all ownership logic

5. Consider Hierarchical Access

• Managers typically need to see team's records
• Plan org structure carefully
• Include in filters where appropriate
• Test hierarchy thoroughly

6. Test Thoroughly

• Create test users and records
• Verify isolation works
• Try to access others' records
• Test ownership transfers
• Test sharing functionality

7. Handle Deleted Users

• What happens when owner is deleted?
• Reassign their records first
• Or use "Inactive" status instead of deleting
• Maintain data integrity

8. Document Ownership Rules

• Explain ownership logic
• Document transfer policies
• Clarify admin overrides
• Keep documentation updated

Common ownership issues and solutions.

Issue 1: Users See Other Users' Records

Check:

• Is filter correctly set? (Owner = Logged In User)
• Is filter active? (not accidentally disabled)
• Are there other filters overriding?
• Is admin viewing? (admin sees all)
• Is sharing enabled that you forgot about?

Issue 2: Users Can't See Their Own Records

Check:

• Is Owner field populated? (auto-fill working?)
• Is filter too restrictive? (multiple AND conditions)
• Is user's role allowed to access the page?
• Does record actually belong to user?

Issue 3: Owner Field Not Auto-Filling

Check:

• Is "Auto-fill with logged in user" enabled in field settings?
• Is user logged in when creating record?
• Is form component configured correctly?
• Is field included in the form?

Issue 4: Admin Can't See All Records

Check:

• Is admin override included in filter?
• Is role name exactly "Admin"? (case-sensitive)
• Is there a page rule blocking access?
• Is component visibility set correctly?

Issue 5: Ownership Transfer Not Working

Check:

• Is Owner field editable?
• Does user have permission to edit Owner field?
• Is Owner field in the form?
• Are there validation rules preventing the change?

In this article, you learned:

• What ownership is - Linking records to users for access control
• Implementing basic ownership - Owner field, filters, and restrictions
• Ownership patterns - Created By, Assigned To, Multiple Owners, Hierarchical, Department
• Owner-only editing - Restricting modifications to owners
• Admin overrides - Ensuring admins can access all records
• Sharing and collaboration - Allowing owners to share records
• Transferring ownership - Reassigning record owners
• Complex scenarios - Multi-stage workflows, hierarchies, projects
• Best practices - Guidelines for effective ownership
• Troubleshooting - Common issues and solutions

Record ownership is one of the most powerful security patterns in Tadabase. It enables you to build applications where users can only access their own data, creating truly multi-user, secure applications.

In the next article, you'll learn about multi-tenant applications - building SaaS applications that serve multiple companies with complete data isolation.

Hands-On Exercise (To Be Added)

Exercise placeholders will include practical activities such as:

• Implementing basic ownership in a table
• Creating owner-filtered pages
• Setting up owner-only editing
• Implementing admin overrides
• Building a sharing system
• Testing ownership with multiple users

Knowledge Check (To Be Added)

Quiz questions will test understanding of:

• How ownership works
• Different ownership patterns
• Implementing owner filters
• When to use admin overrides
• Sharing vs. ownership
• Best practices for ownership