[WEB-5667] chore: estimate value display in analytics

[NarayanBavisetti]

Description

replaced the key with the estimate value to display the correct data in analytics.

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Screenshots and Media (if applicable)

Test Scenarios

References

Summary by CodeRabbit

• Bug Fixes
  • Corrected the labeling and ordering of estimate points in chart visualizations to display data accurately.

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

[cursor]

You have run out of free Bugbot PR reviews for this billing cycle. This will reset on January 20.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[coderabbitai]

📝 Walkthrough

Walkthrough

The ESTIMATE_POINTS field mapping in the get_x_axis_field function was swapped, reversing which database field is used as the identifier versus display name. This alters how estimate points are labeled and ordered in chart data.

Changes

Cohort / File(s)	Summary
Chart utility field mapping apps/api/plane/utils/build_chart.py	Swapped ESTIMATE_POINTS tuple from ("estimate_point__value", "estimate_point__key", None) to ("estimate_point__key", "estimate_point__value", None), inverting which field serves as id_field and name_field. Affects grouping and labeling of estimate points in charted data.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

A rabbit hops through estimate fields so bright,
Swapping keys and values, left becomes right,
Charts now dance with proper labels true,
Point-by-point, the data shines anew! 🐰📊

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description is largely incomplete. While it briefly mentions the change ('replaced the key with the estimate value'), it lacks detail about what was changed, why it matters, and most required template sections are empty or unfilled.	Add detailed explanation of the field swap, include before/after context, provide test scenarios, add screenshots if applicable, and reference the issue ticket [WEB-5667].
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.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is tangentially related to the changeset but lacks specificity. It mentions 'estimate value display in analytics' which aligns with the code change of swapping ESTIMATE_POINTS fields, but doesn't clearly convey the actual fix (field mapping swap).

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore-estimate-point-value-analytics

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 777200d and cbd8292.

📒 Files selected for processing (1)

• apps/api/plane/utils/build_chart.py

🧰 Additional context used

🧠 Learnings (1)

📚 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/utils/build_chart.py

⏰ 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). (5)

• GitHub Check: check:lint
• GitHub Check: check:types
• GitHub Check: Lint API
• GitHub Check: Agent
• GitHub Check: Analyze (javascript)

🔇 Additional comments (1)

apps/api/plane/utils/build_chart.py (1)

54-54: Remove unsupported claims about breaking changes—this is a new file.

The ESTIMATE_POINTS mapping at line 54 introduces a new chart-building feature, not a modification of existing code. The file build_chart.py was newly created in this commit, so there is no prior implementation to break. The mapping correctly uses estimate_point__key (numeric 0–12) as the identifier and estimate_point__value (display string) as the display name, which aligns with the EstimatePoint model structure. The ordering by key field (line 136) is appropriate for numeric sequences.

No verification of frontend compatibility or saved configurations is necessary for a new feature.

---

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.}

[makeplane]

Linked to Plane Work Item(s)

• [WEB-5667] Dashboard Widget Displays Empty Chart When Epics/Work Items Have Estimate Time

This comment was auto-generated by Plane

[Copilot]

Pull request overview

This PR fixes a bug in the analytics feature where estimate point data was being displayed incorrectly. The issue was caused by the tuple elements being in the wrong order, resulting in the estimate key being used as the display value and vice versa.

• Fixed the ordering of estimate_point__key and estimate_point__value in the get_x_axis_field() function to ensure correct data display in analytics

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.