BUG: N+1 query pattern in getTickets/getTasks/getTicketDetails causes performance issues

[g-k-s-03]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Issue Overview

Several data-fetching methods in SupabaseService perform multiple sequential database queries for related user data.

For example:

• getTickets
• getTasks
• getTicketDetails
• getTaskDetails

These methods:

1. Fetch a list of tickets/tasks/comments.
2. Then, for each item, make additional queries to fetch creator/assignee/user info.

This creates an N+1 query pattern.

Steps to Reproduce

1. Create a team with multiple members.
2. Add 20–50 tasks or tickets.
3. Call getTickets() or getTasks().
4. Observe in logs or network panel that dozens of extra queries are executed (one per item for user info).

Expected Behavior

Related user data (creator, assignee, comment user) should be fetched in a single query using joins or views, not separate queries per row.
The number of database calls should be:

• O(1) per screen load
  not
• O(n) per item.

Actual Behavior

For each ticket/task/comment:

• _getUserInfo() is called.
• This results in additional round-trips to the database.
• Performance degrades rapidly as data grows.

This will not scale for real teams.

Why this issue matters

This is not just micro-optimisation.
It directly affects:

• load time
• mobile data usage
• battery
• server cost
  On real data sizes, this becomes a serious bottleneck.

Record

• I agree to follow this project's Code of Conduct
• I want to work on this issue

[g-k-s-03]

Hi @SharkyBytes ,
I’ll start by identifying all places where N+1 queries occur (getTickets, getTasks, getTicketDetails, etc.) and measure the number of queries being triggered.

Then I’ll propose a fix using joins/views or an RPC-based approach so related user data can be fetched in a single query.

I’ll share the design first before opening a PR.