Enables Work History and hides pending tab

[shubham1g5]

Product Description

https://dimagi.atlassian.net/browse/CCCT-1722

Refer to #3221 for feature context.

Safety Assurance

Safety story

• Locally Tested
• QA before or as part of release

Labels and Review

• Do we need to enhance the manual QA test coverage ? If yes, the "QA Note" label is set correctly
• Does the PR introduce any major changes worth communicating ? If yes, the "Release Note" label is set and a "Release Note" is specified in PR description.
• Risk label is set correctly
• The set of people pinged as reviewers is appropriate for the level of risk of the change

Release Note: A new work history menu in side navigation drawer to see records of past jobs user did as part of Connect Programs

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request enables the WORK_HISTORY feature flag and temporarily reduces the work history view pager to display a single page instead of two. The changes include: updating the feature flag checker to return true for WORK_HISTORY, reducing TOTAL_PAGES in the ViewPager adapter from 2 to 1, adding conditional logic in the activity to hide the tab layout when only one page exists, and hiding a "Learn More" text view in the layout by default.

Sequence Diagram

sequenceDiagram
    participant Activity as PersonalIdWorkHistoryActivity
    participant Adapter as WorkHistoryViewPagerAdapter
    participant TabLayout as TabLayoutMediator

    Activity->>Adapter: Check TOTAL_PAGES
    alt TOTAL_PAGES == 1
        Activity->>Activity: Hide TabLayout
        Note over Activity: Single page mode<br/>(tabs not displayed)
    else TOTAL_PAGES > 1
        Activity->>TabLayout: Create and attach mediator
        TabLayout->>TabLayout: Bind tabs with titles/icons
        Note over TabLayout: Multi-page mode<br/>(tabs displayed)
    end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify the intentionality of temporarily setting TOTAL_PAGES to 1 and the pending rollout timeline
• Confirm the feature flag change to enable WORK_HISTORY aligns with product/team decisions
• Ensure the conditional tab-hiding logic doesn't cause layout issues or unexpected UI states

Possibly related PRs

• Backmerge Commcare 2.60.0 #3372: Modifies feature-flag handling in PersonalIdFeatureFlagChecker.kt for WORK_HISTORY and NOTIFICATIONS flags
• Hide Notifications behind a feature flag #3358: Updates PersonalIdFeatureFlagChecker's feature-flag branches for WORK_HISTORY and NOTIFICATIONS
• Rename Credential to work history #3344: Adjusts work-history UI presentation in PersonalIdWorkHistoryActivity and WorkHistoryViewPagerAdapter

Suggested reviewers

• OrangeAndGreen
• jaypanchal-13
• Jignesh-dimagi

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
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.
Description Check	⚠️ Warning	The pull request description is significantly incomplete when compared against the repository's template requirements. While a Product Description section is provided with a JIRA reference and a Release Note is included, several critical sections are entirely absent or severely underdeveloped: the Technical Summary (missing rationale and design decisions), Feature Flag section (not explicitly identifying the WORK_HISTORY flag), Automated Test Coverage (no tests mentioned), and QA Plan (no QA ticket or detailed plan provided). The Safety Story section is present but lacks substantive detail about confidence level, specific safety measures, and blast radius considerations. This incomplete documentation makes it difficult to properly assess the technical merit and risk of the changes affecting multiple Kotlin files and layout resources.	The author should update the pull request description to include: a Technical Summary section with links to relevant tickets and explanation of the design rationale for enabling the Work History feature flag and hiding the pending credentials page; an explicit Feature Flag section identifying WORK_HISTORY; a detailed Safety Story explaining confidence level and mitigation strategies; an Automated Test Coverage section identifying which tests validate these changes; and a QA Plan section with specific testing scenarios and a link to the associated QA ticket. These additions will provide reviewers with necessary context to evaluate the safety and correctness of the implementation.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The PR title "Enables Work History and hides pending tab" accurately reflects the main changes in the changeset. The first part, "Enables Work History," corresponds to the feature flag change in PersonalIdFeatureFlagChecker.kt where WORK_HISTORY now returns true. The second part, "hides pending tab," relates to the series of coordinated changes: reducing TOTAL_PAGES from 2 to 1 in WorkHistoryViewPagerAdapter.kt, conditionally hiding the TabLayout in PersonalIdWorkHistoryActivity.kt, and adding android:visibility="gone" to a TextViewin the layout file. The title is concise, specific, and conveys the primary intent of the PR clearly enough that a teammate reviewing the commit history would understand the main changes without additional context.

✨ 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 hidePendingCredentials

---

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: 0

🧹 Nitpick comments (1)

app/src/org/commcare/activities/connect/PersonalIdWorkHistoryActivity.kt (1)

50-59: Conditional tab handling implemented correctly.

The logic appropriately hides the TabLayout when displaying a single page and configures it with tabs when multiple pages are available. The implementation handles the temporary single-page state while preserving the infrastructure for the multi-page flow.

For slightly more defensive coding, consider checking TOTAL_PAGES < 2 instead of == 1 to handle any edge cases:

-        if (WorkHistoryViewPagerAdapter.TOTAL_PAGES == 1) {
+        if (WorkHistoryViewPagerAdapter.TOTAL_PAGES < 2) {
             binding.tabWorkHistory.visibility = android.view.View.GONE
         } else {

However, this is optional since TOTAL_PAGES is a compile-time constant.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d6dd813 and 90f48b8.

📒 Files selected for processing (4)

• app/res/layout/activity_personal_id_work_history.xml (1 hunks)
• app/src/org/commcare/activities/connect/PersonalIdWorkHistoryActivity.kt (1 hunks)
• app/src/org/commcare/adapters/WorkHistoryViewPagerAdapter.kt (1 hunks)
• app/src/org/commcare/personalId/PersonalIdFeatureFlagChecker.kt (1 hunks)

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

• GitHub Check: Lint Code Base

🔇 Additional comments (3)

app/res/layout/activity_personal_id_work_history.xml (1)

51-51: LGTM - View hidden for single-page flow.

Hiding the "Learn More" view is appropriate when displaying only one page in the work history.

app/src/org/commcare/adapters/WorkHistoryViewPagerAdapter.kt (1)

13-13: Temporary change documented appropriately.

The reduction to a single page makes the PENDING_TAB_INDEX case in createFragment (line 22) unreachable, but this is acceptable for a temporary change. The comment clearly documents the intent, and all infrastructure remains in place for easy rollback.

app/src/org/commcare/personalId/PersonalIdFeatureFlagChecker.kt (1)

24-24: LGTM - Feature flag enabled.

Straightforward enablement of the WORK_HISTORY feature flag, consistent with the PR objectives.

[conroy-ricketts]

With the push to general availability and getting rid of feature flags, are we going to be deleting this class in the near future?

[shubham1g5]

@conroy-ricketts Great question, but not really, these are meant to just be short term flags just to help us with release planning or deployment of the feature. Currently it provides us an easy switch to turn the feature off if it's not ready to deploy in the upcoming release but we soon plan to hook this class to a server endpoint so that we can potentially release a feature out for a sub-set of users before releasing to all users.

[OrangeAndGreen]

Noting the broken build but I think it's a failing test that has intermittent issues

[Jignesh-dimagi]

@shubham1g5 As discussed we will get rid of this hard coding and will use FeatureFlag.WORK_HISTORY_PENDING kind of variable to decide the number of total pages. Hope you are on same page?

[shubham1g5]

dc4790a