Per-User Data Audit 2025-12-23 - Complete Documentation Index

Last Updated: 2025-12-23
Status: ✅ Current (All data persistence architecture up-to-date)
Scope: Swimlanes, Lists, Cards, Checklists, ChecklistItems - positions, widths, heights, colors, titles

📋 Documentation Overview

This folder contains the complete, current documentation for Wekan's data persistence architecture as of December 23, 2025.

Key Change: Swimlane height and list width are now per-board (stored in documents, shared with all users), not per-user.

📚 Documents (Read In This Order)

1. CURRENT_STATUS.md 🟢 START HERE

Purpose: Quick status overview of what's been done and what's pending
Read Time: 5 minutes
Contains:

• Key decision on data classification
• What's completed vs pending
• Before/after examples
• Testing requirements
• Integration phases

Best For: Getting current status quickly

2. DATA_PERSISTENCE_ARCHITECTURE.md 📖 REFERENCE

Purpose: Complete architecture specification
Read Time: 15 minutes
Contains:

• Full data classification matrix (per-board vs per-user)
• Where each field is stored
• MongoDB schema definitions
• Cookie/localStorage for public users
• Data flow diagrams
• Validation rules
• Security implications
• Testing checklist

Best For: Understanding the complete system

3. IMPLEMENTATION_GUIDE.md 🛠️ DOING THE WORK

Purpose: Step-by-step implementation instructions
Read Time: 20 minutes
Contains:

• Changes already completed ✅
• Changes still needed ⏳
• Code examples for refactoring
• Migration script template
• Testing checklist
• Rollback plan
• Files modified reference

Best For: Implementing the remaining phases

4. SCHEMA_CHANGES_VERIFICATION.md ✅ VERIFICATION

Purpose: Verification that schema changes are correct
Read Time: 10 minutes
Contains:

• Exact fields added (with line numbers)
• Validation rule verification
• Data type classification
• Migration path status
• Code review checklist
• Integration notes

Best For: Verifying all changes are correct

5. QUICK_REFERENCE.md ⚡ QUICK LOOKUP

Purpose: Quick reference for key information
Read Time: 3 minutes
Contains:

• What changed (removed/added/kept)
• How it works (per-user vs per-board)
• Troubleshooting
• Performance notes
• Which files to know about

Best For: Quick lookups and troubleshooting

🎯 At a Glance

The Core Change

BEFORE (Mixed/Wrong):

• Swimlane height: Stored per-user in user.profile
• List width: Stored per-user in user.profile
• Cards could look different dimensions for different users

NOW (Correct):

• Swimlane height: Stored per-board in swimlane document
• List width: Stored per-board in list document
• All users see same dimensions (shared layout)
• Only collapse state is per-user (private preference)

What's Per-Board ✅ (ALL Users See Same)

Swimlane:
  - title, color, height, sort, archived

List:
  - title, color, width, sort, archived, wipLimit, starred

Card:
  - title, color, description, swimlaneId, listId, sort, archived

Checklist:
  - title, sort, hideCheckedItems, hideAllItems

ChecklistItem:
  - title, sort, isFinished

What's Per-User 🔒 (Only YOU See Yours)

User Preferences:
  - collapsedSwimlanes[boardId][swimlaneId] (true/false)
  - collapsedLists[boardId][listId] (true/false)
  - hideMiniCardLabelText[boardId] (true/false)

✅ Completed (Phase 1)

• Schema Addition

  • Added swimlanes.height field (default: -1, range: -1 or 50-2000)
  • Added lists.width field (default: 272, range: 100-1000)
  • Both with validation and backward compatibility

• Documentation

  • Complete architecture specification
  • Implementation guide with code examples
  • Migration script template
  • Verification checklist

• Verification

  • Schema changes verified correct
  • Validation logic reviewed
  • Code samples provided
  • Testing plans documented

⏳ Pending (Phase 2-4)

• User Model Refactoring (Phase 2)

  • Refactor user methods to read heights/widths from documents
  • Remove per-user storage from user.profile
  • Update user schema definition

• Data Migration (Phase 3)

  • Create migration script (template in IMPLEMENTATION_GUIDE.md)
  • Migrate existing per-user data to per-board
  • Track migration status
  • Verify no data loss

• UI Integration (Phase 4)

  • Update client code
  • Update Meteor methods
  • Update subscriptions
  • Test with multiple users

📊 Data Classification Summary

Per-Board (Shared with All Users)

Per-User (Private to You)

🔍 Quick Facts

• Total Files Modified So Far: 2 (swimlanes.js, lists.js)
• Total Files Documented: 5 markdown files
• Schema Fields Added: 2 (height, width)
• Validation Rules Added: 2 (heightOutOfRange, widthOutOfRange)
• Per-Board Data Types: 5 entity types × multiple fields
• Per-User Data Types: 3 preference types
• Backward Compatibility: ✅ Yes (both fields optional)
• Data Loss Risk: ✅ None (old data preserved until migration)

🚀 How to Use This Documentation

For Developers Joining Now

1. Read CURRENT_STATUS.md - 5 min overview
2. Skim DATA_PERSISTENCE_ARCHITECTURE.md - understand the system
3. Reference IMPLEMENTATION_GUIDE.md - when doing Phase 2

For Reviewing Changes

1. Read SCHEMA_CHANGES_VERIFICATION.md - verify what was done
2. Check actual files: swimlanes.js, lists.js
3. Approve or request changes

For Implementing Remaining Work

1. Phase 2 (User Refactoring): See IMPLEMENTATION_GUIDE.md Section 2
2. Phase 3 (Migration): Use template in IMPLEMENTATION_GUIDE.md Section 4
3. Phase 4 (UI): See IMPLEMENTATION_GUIDE.md Section 3

For Troubleshooting

• Quick answers: QUICK_REFERENCE.md
• Detailed reference: DATA_PERSISTENCE_ARCHITECTURE.md

📞 Questions Answered

"What data is per-board?"

See DATA_PERSISTENCE_ARCHITECTURE.md Section: Data Classification Matrix

"What data is per-user?"

See DATA_PERSISTENCE_ARCHITECTURE.md Section: Data Classification Matrix

"Where is swimlane height stored?"

• New: In swimlane document (per-board)
• Old: In user.profile (per-user) - being replaced
• See SCHEMA_CHANGES_VERIFICATION.md for verification

"Where is list width stored?"

• New: In list document (per-board)
• Old: In user.profile (per-user) - being replaced
• See SCHEMA_CHANGES_VERIFICATION.md for verification

"How do I migrate old data?"

See IMPLEMENTATION_GUIDE.md Section 4 for migration script template

"What should I do next?"

See CURRENT_STATUS.md Section: Integration Path → Phase 2

"Is there a migration risk?"

No - see IMPLEMENTATION_GUIDE.md Section 7: Rollback Plan

"Are there validation rules?"

Yes - see DATA_PERSISTENCE_ARCHITECTURE.md Section: Validation Rules

🔄 Document Update Schedule

✨ Key Achievements

✅ Clear Architecture: Swimlane height and list width are now definitively per-board
✅ Schema Validation: Both fields have custom validation functions
✅ Documentation: 5 comprehensive documents covering all aspects
✅ Backward Compatible: Old data preserved, transition safe
✅ Implementation Ready: Code examples and migration scripts provided
✅ Future-Proof: Clear path for remaining phases

📝 Notes

• All data classification decisions made with input from security audit
• Per-board height/width means better collaboration (shared layout)
• Per-user collapse/visibility means better individual workflow
• Migration can happen at any time with no user downtime
• Testing templates provided for all phases

📍 File Location Reference

All files are in: /home/wekan/repos/wekan/docs/Security/PerUserDataAudit2025-12-23/

PerUserDataAudit2025-12-23/
├── CURRENT_STATUS.md                          ← Start here
├── DATA_PERSISTENCE_ARCHITECTURE.md           ← Complete spec
├── IMPLEMENTATION_GUIDE.md                    ← How to implement
├── SCHEMA_CHANGES_VERIFICATION.md             ← Verification
├── QUICK_REFERENCE.md                         ← Quick lookup
├── README.md                                  ← This file
├── QUICK_REFERENCE.md                         ← Previous doc
├── ARCHITECTURE_IMPROVEMENTS.md               ← From Phase 1
├── PERSISTENCE_AUDIT.md                       ← Initial audit
├── IMPLEMENTATION_SUMMARY.md                  ← Phase 1 summary
├── FIXES_CHECKLIST.md                         ← Bug fixes
└── Plan.txt                                   ← Original plan

Status: ✅ COMPLETE AND CURRENT
Last Review: 2025-12-23
Next Phase: User Model Refactoring (Phase 2)