migration: added getting_started_checklist, tips, explored_feature fields on the workspace member table

[sangeethailango]

Description

This PR will add the getting_started_checklist, tips, and trial fields to the workspace member.

Summary by CodeRabbit

• Chores
  • Extended system infrastructure with new data fields for storing onboarding progress, tips, and feature exploration data.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Three new JSONField attributes are added to the WorkspaceMember model: getting_started_checklist, tips, and explored_features, each defaulting to an empty dictionary. A corresponding Django migration is created to apply these schema changes to the database.

Changes

Cohort / File(s)	Summary
Model Definition apps/api/plane/db/models/workspace.py	Added three JSONField attributes to WorkspaceMember class: getting_started_checklist, tips, and explored_features, each with default empty dict values
Database Migration apps/api/plane/db/migrations/0114_workspacemember_explored_features_and_more.py	Created migration adding three JSONField columns to workspacemember table with default empty dict, dependent on prior migration 0113

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 Three fields hop into the member's home,
Checklists, tips, and features to roam,
JSON dicts so empty and light,
A migration prepared, everything's right!
The workspace now has room to grow.

🚥 Pre-merge checks | ❌ 3

❌ Failed checks (3 warnings)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title mentions 'trial' field but the changes only add 'getting_started_checklist', 'tips', and 'explored_features' fields; no 'trial' field is present in the code changes.	Update the title to accurately reflect the actual fields added: 'migration: add getting_started_checklist, tips, and explored_features fields to workspace member'
Description check	⚠️ Warning	The description is minimal and only partially fills the template. It covers the Description section but lacks Type of Change, Test Scenarios, and References sections required by the template.	Expand the description to include all template sections: specify the type of change (Feature), describe test scenarios, and add any related issue references.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f94b9a6 and 427a894.

📒 Files selected for processing (2)

• apps/api/plane/db/migrations/0114_workspacemember_explored_features_and_more.py
• apps/api/plane/db/models/workspace.py

🚧 Files skipped from review as they are similar to previous changes (1)

• apps/api/plane/db/models/workspace.py

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: dheeru0198
Repo: makeplane/plane PR: 8339
File: apps/api/plane/db/migrations/0113_webhook_version.py:7-14
Timestamp: 2025-12-29T08:58:46.563Z
Learning: In the Plane codebase, when adding product tour or onboarding fields via migrations, it's intentional to set existing records to `True` (completed) while having the model default to `False` for new records. This ensures existing users don't see tours they don't need.

📚 Learning: 2025-12-23T14:18:32.899Z

Learnt from: dheeru0198
Repo: makeplane/plane PR: 8339
File: apps/api/plane/db/models/api.py:35-35
Timestamp: 2025-12-23T14:18:32.899Z
Learning: Django REST Framework rate limit strings are flexible: only the first character of the time unit matters. Acceptable formats include: "60/s", "60/sec", "60/second" (all equivalent), "60/m", "60/min", "60/minute" (all equivalent), "60/h", "60/hr", "60/hour" (all equivalent), and "60/d", "60/day" (all equivalent). Abbreviations like "min" are valid and do not need to be changed to "minute". Apply this guidance to any Python files in the project that configure DRF throttling rules.

Applied to files:

• apps/api/plane/db/migrations/0114_workspacemember_explored_features_and_more.py

🧬 Code graph analysis (1)

apps/api/plane/db/migrations/0114_workspacemember_explored_features_and_more.py (1)

apps/api/plane/utils/exporters/schemas/base.py (1)

• JSONField (127-140)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: Build packages
• GitHub Check: Analyze (javascript)

🔇 Additional comments (1)

apps/api/plane/db/migrations/0114_workspacemember_explored_features_and_more.py (1)

6-28: LGTM! Migration structure is correct.

The migration is well-formed with appropriate field types and defaults. The use of default=dict for JSONField is correct in Django migrations.