Archived contacts not coming in the contacts list

[jonneychris]

Issue Description:
Archived contacts are not displayed in the contact list for creating secret groups, forwarding media, social group invitations, and the new screen.

Test Steps
1.Archive any one contact.
2.Open Create Secret Group and check the contact list.
3.Open the Forward Media screen and check the contact list.
4.Open the Social Group Invitation Share list and check the contact list.
5.Open the New Screen and check the contact list.

Expected Result
Archived contacts should still appear in all contact lists (Create Secret Group, Forward Media, Social Group Invitation Share, and New Screen).

Actual Result
Archived contacts are not displayed in the contact lists in these sections.

[codeman-crypto]

@coderabbitai plan

[coderabbitai]

Warning

A plan generation is already in progress. Please wait for it to complete before requesting a new plan.

[coderabbitai]

Coding Plan

Summary

• Root cause is architectural: archival filtering is caller-controlled, forcing every picker to manually merge an active list with an archived list, which is brittle and lets archived contacts slip through.
• Introduce one archival-agnostic conversation query in ThreadDatabase that returns qualifying contacts regardless of the archived flag.
• Repoint all four affected pickers (New Screen, Create Secret Group, Forward Media, Social Group Invitation Share) to that single query, removing fragile dual-cursor merges.
• Keep existing recipient-level filters intact and aligned so behavior changes only with respect to archived inclusion, with no scope creep into unrelated contact consumers.

Design Choices

Design Choice 1: Should archived contacts be surfaced by fixing each screen's merge logic individually, or by introducing a single inclusive query at the database layer?

Options Considered:

1. Per-screen patching — Audit each of the four data sources and ensure each reads both the active and archived cursors and applies identical filters.
2. Centralized inclusive query — Add a single ThreadDatabase query that returns approved/active conversations regardless of archived state, then point all four data sources at it, removing the need to merge two cursors and the chance of inconsistency.

Chosen Option: 2

Rationale: A centralized inclusive query removes the fragile dual-cursor merge entirely, makes archival-agnostic behavior the default for contact pickers, and guarantees consistency across all four screens (and any future ones) from one place.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Provide an archival-agnostic contact query at the data layer

The objective of this phase is to make "include archived contacts" a first-class, reusable capability instead of something each screen reinvents. By owning archival behavior inside ThreadDatabase, every picker can fetch a complete contact set with a single cursor, eliminating the merge-and-hope pattern that lets archived contacts slip through.

Task 1: Add an inclusive approved-conversation query to ThreadDatabase

Introduce a query that returns the same conversations as the existing approved/active lists but does not restrict on the archived flag.

• Update app/src/main/java/io/beldex/bchat/database/ThreadDatabase.java to add a new method (e.g. getAllContactsConversationList() / getApprovedConversationListIncludingArchived()).
• Reuse the approval/visibility logic already present in getApprovedConversationList() (the has_sent, approved, closed-group, open-group conditions) but omit the archived = 0 predicate so both archived and non-archived qualifying threads are returned by one cursor.
• Keep the message_count != 0 semantics consistent with the existing approved/archived queries so empty threads are not newly introduced.
• Route the new method through the existing shared createQuery() helper to preserve the standard joins and ordering (pinned, date).

Task 2: (Optional) Expose a matching inclusive plain-list variant

If a screen relies on the looser conversationList semantics rather than the approved semantics, provide an equivalent inclusive variant so its behavior is preserved minus the archival restriction.

• In ThreadDatabase.java, if needed, add an inclusive counterpart to getConversationList() that drops only the archived = 0 condition, leaving all other behavior intact.
• Prefer reusing the Task 1.1 method everywhere possible; add this variant only if a screen's existing filter set genuinely depends on the non-approved list.

🤖 Prompt for AI agents

This phase adds a centralized archival-agnostic query to `ThreadDatabase.java`
so contact pickers can fetch a complete set of qualifying contacts with a single
cursor, without merging separate active and archived cursor results.

- In `app/src/main/java/io/beldex/bchat/database/ThreadDatabase.java`, add a new
public method (e.g. `getAllContactsConversationList()` or
`getApprovedConversationListIncludingArchived()`).
- Copy the approval/visibility logic from the existing
`getApprovedConversationList()` method — including `has_sent`, `approved`,
closed-group, and open-group conditions.
- **Remove the `archived = 0` predicate** from the WHERE clause so both archived
and non-archived threads satisfying the other conditions are returned.
  - Preserve the `message_count != 0` guard to avoid surfacing empty threads.
- Route the query through the existing `createQuery()` helper to maintain
standard joins and ordering (pinned-first, then by date).
- Optionally, if any picker screen relies on the looser `getConversationList()`
semantics rather than the approved semantics, add a second inclusive variant of
`getConversationList()` that likewise drops only the `archived = 0` condition
and leaves all other behavior intact. Only add this if genuinely needed after
reviewing picker usage.

Phase 2: Point all four contact pickers at the inclusive query

The objective here is to ensure each of the four reported screens sources its contacts from the new archival-agnostic query and applies a consistent recipient-level filter, so archived contacts that are otherwise valid (approved, not blocked, not self, correct type) always appear. Where screens currently merge two cursors, that merge is replaced by the single inclusive call to remove the source of inconsistency.

Task 1: New Screen (New Chat) contact list

Ensure the New Screen shows archived contacts.

• Update app/src/main/java/io/beldex/bchat/conversation_v2/NewChatScreenViewModel.kt to load recipients from the inclusive query (Task 1.1/1.2) instead of separately iterating conversationList and archivedConversationList.
• Preserve the existing recipient-level filter (1-to-1 contacts that satisfy approval/self checks, plus active closed groups) and deduplication so only the archival behavior changes.

Task 2: Create Secret Group contact list

Ensure the secret-group member picker shows archived contacts.

• Update app/src/main/java/io/beldex/bchat/conversation_v2/CreateSecretGroupViewModel.kt to source recipients from the inclusive query rather than merging approvedConversationList + archivedConversationList.
• Keep the current filter intent (non-group, hasApprovedMe(), not self, not blocked); confirm it does not implicitly depend on archived state.

Task 3: Forward Media contact list (ShareActivity)

Ensure the forward picker shows archived contacts.

• Update app/src/main/java/io/beldex/bchat/contacts/ContactSelectionListLoader.kt to read from the inclusive query instead of merging the approved and archived cursors.
• Maintain the existing type/approval/blocked filtering used to bucket contacts, closed groups, and open groups so visible results are unchanged apart from archived inclusion.

Task 4: Social Group Invitation Share contact list (SelectContactsActivity)

Ensure the open-group invite picker shows archived contacts.

• Update app/src/main/java/io/beldex/bchat/contacts/SelectContactsLoader.kt to use the inclusive query in place of the conversationList + archivedConversationList merge.
• Preserve the caller-supplied usersToExclude set and the non-group/hasApprovedMe()/isApproved/!isBlocked filter so only archival behavior changes.

Task 5: Consistency verification across pickers

Confirm uniform behavior and avoid regressions.

• Verify the post-load recipient filters across the four data sources are aligned (notably the isApproved vs hasApprovedMe() discrepancy noted between CreateSecretGroupViewModel and the others) so an archived-but-valid contact is treated identically in every picker.
• Confirm deduplication still behaves correctly now that a single cursor supplies all rows.
• Sanity-check that screens not in scope (e.g. callers of ContactUtilities.getAllContacts() such as Blocked Contacts and config sync) are intentionally left unchanged, since they are not part of this ticket.

🤖 Prompt for AI agents

This phase updates all four contact picker data sources to use the new inclusive
query introduced in Phase 1, replacing fragile dual-cursor merges. The goal is
that archived-but-valid contacts appear in every picker without changing any
other filtering behavior.

**`NewChatScreenViewModel.kt`**
(`app/src/main/java/io/beldex/bchat/conversation_v2/NewChatScreenViewModel.kt`)
- Replace the separate loads of `conversationList` and
`archivedConversationList` with a single call to the new inclusive query from
Phase 1.
- Retain the existing recipient-level filter: 1-to-1 contacts satisfying
approval/self checks, plus active closed groups. Preserve existing deduplication
logic.

**`CreateSecretGroupViewModel.kt`**
(`app/src/main/java/io/beldex/bchat/conversation_v2/CreateSecretGroupViewModel.kt`)
- Replace the merge of `approvedConversationList` + `archivedConversationList`
with a single call to the new inclusive query.
- Keep the current filter intent: non-group, `hasApprovedMe()`, not self, not
blocked. Confirm this filter does not implicitly depend on archived state.

**`ContactSelectionListLoader.kt`**
(`app/src/main/java/io/beldex/bchat/contacts/ContactSelectionListLoader.kt`)
- Replace the merged approved + archived cursor reads with a single call to the
new inclusive query.
- Maintain the existing type/approval/blocked filtering that buckets results
into contacts, closed groups, and open groups.

**`SelectContactsLoader.kt`**
(`app/src/main/java/io/beldex/bchat/contacts/SelectContactsLoader.kt`)
- Replace the `conversationList` + `archivedConversationList` merge with a
single call to the new inclusive query.
- Preserve the caller-supplied `usersToExclude` set and the
non-group/`hasApprovedMe()`/`isApproved`/`!isBlocked` filter.

**Consistency verification (no new code, review step)**
- Cross-check the post-load recipient filters in all four files — particularly
the `isApproved` vs `hasApprovedMe()` discrepancy between
`CreateSecretGroupViewModel` and the others — and align them so an
archived-but-valid contact is treated identically across every picker.
- Verify deduplication is correct now that a single cursor supplies all rows.
- Confirm that unrelated callers of `ContactUtilities.getAllContacts()` (e.g.
Blocked Contacts, config sync) are left unchanged.

Research

{"text": "All app code lives under app/src/main/java/io/beldex/bchat/. Conversation/contact data is served from a single SQLite-backed ThreadDatabase, where an archived column is the sole archival flag. The core fetch methods (getConversationList(), getApprovedConversationList(), etc.) hard-code archived = 0 in their WHERE clause, while getArchivedConversationList() returns only archived = 1 rows. Because archival filtering is entirely controlled by each query's WHERE string, every screen that wants a complete contact set must remember to call two cursors (the active list and the archived list) and merge them in memory before applying recipient-level filters (hasApprovedMe(), isApproved, !isBlocked, non-group, non-self).\n\nThe four affected pickers are backed by:\n- Create Secret Group → CreateSecretGroupViewModel\n- Forward Media → ShareActivity → ContactSelectionListFragment → ContactSelectionListLoader\n- Social Group Invitation Share → ConversationMenuHelper.inviteContacts() → SelectContactsActivity → SelectContactsLoader\n- New Screen → NewChatConversationActivity → NewChatScreen → NewChatScreenViewModel\n\nThe recurring "two cursors + merge + filter" pattern is fragile: any divergence in which cursors are read, deduplication order, or post-merge filter conditions can silently drop archived contacts. This fragility is the structural root cause the ticket exposes.", "creation_status": "new"}

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase adds a centralized archival-agnostic query to `ThreadDatabase.java`
so contact pickers can fetch a complete set of qualifying contacts with a single
cursor, without merging separate active and archived cursor results.

- In `app/src/main/java/io/beldex/bchat/database/ThreadDatabase.java`, add a new
public method (e.g. `getAllContactsConversationList()` or
`getApprovedConversationListIncludingArchived()`).
- Copy the approval/visibility logic from the existing
`getApprovedConversationList()` method — including `has_sent`, `approved`,
closed-group, and open-group conditions.
- **Remove the `archived = 0` predicate** from the WHERE clause so both archived
and non-archived threads satisfying the other conditions are returned.
  - Preserve the `message_count != 0` guard to avoid surfacing empty threads.
- Route the query through the existing `createQuery()` helper to maintain
standard joins and ordering (pinned-first, then by date).
- Optionally, if any picker screen relies on the looser `getConversationList()`
semantics rather than the approved semantics, add a second inclusive variant of
`getConversationList()` that likewise drops only the `archived = 0` condition
and leaves all other behavior intact. Only add this if genuinely needed after
reviewing picker usage.
===============================================================================

Task: 2

This phase updates all four contact picker data sources to use the new inclusive
query introduced in Phase 1, replacing fragile dual-cursor merges. The goal is
that archived-but-valid contacts appear in every picker without changing any
other filtering behavior.

**`NewChatScreenViewModel.kt`**
(`app/src/main/java/io/beldex/bchat/conversation_v2/NewChatScreenViewModel.kt`)
- Replace the separate loads of `conversationList` and
`archivedConversationList` with a single call to the new inclusive query from
Phase 1.
- Retain the existing recipient-level filter: 1-to-1 contacts satisfying
approval/self checks, plus active closed groups. Preserve existing deduplication
logic.

**`CreateSecretGroupViewModel.kt`**
(`app/src/main/java/io/beldex/bchat/conversation_v2/CreateSecretGroupViewModel.kt`)
- Replace the merge of `approvedConversationList` + `archivedConversationList`
with a single call to the new inclusive query.
- Keep the current filter intent: non-group, `hasApprovedMe()`, not self, not
blocked. Confirm this filter does not implicitly depend on archived state.

**`ContactSelectionListLoader.kt`**
(`app/src/main/java/io/beldex/bchat/contacts/ContactSelectionListLoader.kt`)
- Replace the merged approved + archived cursor reads with a single call to the
new inclusive query.
- Maintain the existing type/approval/blocked filtering that buckets results
into contacts, closed groups, and open groups.

**`SelectContactsLoader.kt`**
(`app/src/main/java/io/beldex/bchat/contacts/SelectContactsLoader.kt`)
- Replace the `conversationList` + `archivedConversationList` merge with a
single call to the new inclusive query.
- Preserve the caller-supplied `usersToExclude` set and the
non-group/`hasApprovedMe()`/`isApproved`/`!isBlocked` filter.

**Consistency verification (no new code, review step)**
- Cross-check the post-load recipient filters in all four files — particularly
the `isApproved` vs `hasApprovedMe()` discrepancy between
`CreateSecretGroupViewModel` and the others — and align them so an
archived-but-valid contact is treated identically across every picker.
- Verify deduplication is correct now that a single cursor supplies all rows.
- Confirm that unrelated callers of `ContactUtilities.getAllContacts()` (e.g.
Blocked Contacts, config sync) are left unchanged.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!