feat(case-manager): make GetNextCase relative to the provided case #997
Conversation
repositories/case_repository.go
Outdated
| @@ -504,6 +504,8 @@ func (repo *MarbleDbRepository) GetNextCase(ctx context.Context, exec Executor, | |||
| "assigned_to": nil, | |||
| }, | |||
| squirrel.NotEq{"status": "closed"}, | |||
| squirrel.NotEq{"id": c.Id}, | |||
| squirrel.GtOrEq{"created_at": c.CreatedAt}, | |||
There was a problem hiding this comment.
As outlined verbally, this would fail if we are already on the most recent unassigned case, we basically reversed the initial issue.
There was a problem hiding this comment.
Indeed and it's even worst since we cannot find the actual oldest unassigned case if the case in the context is assigned and newer.
siiick
force-pushed
the
feat/relative-get-next-case
branch
from
173a11f to
af64f4e
Compare
There was a problem hiding this comment.
We rediscussed this this morning (?) with Arnaud and Antoine (sorry, was orally in the office)
The short version is (and I should write it up):
- the order/filters for this should be: boosted before non boosted, ignore assigned closed and snoozed, otherwise oldest first
- if the current case is not in this category (unassigned open and not snoozed), navigate to the highest (in order) such case
- if the case is already in this category, navigate to the next one in order (if there is none, move back to inbox homepage ?)
where "in order" above means (boosted, created_at ASC) as mentioned. It would probably be most easily done with two sql queries and some code logic to glue them, than just one query on the full order.
for current case that is unassigned, not closed and not snoozed. Select the next unassigned case instead of the older one.
|
I hardly see the need to build two distinct queries.
Additionally, we always want to prioritize cases that are:
If I understand your comment correctly, we can keep the same base query (after my changes: 48413031 and ff08c982). If the current case is unassigned, open, and not snoozed, we can just filter for cases created after it, and keep the same ordering logic. Does that sound good @Pascal-Delange ? |
| Limit(1) | ||
|
|
||
| if c.AssignedTo == nil && c.Status != "closed" && (c.SnoozedUntil == nil || c.SnoozedUntil.Before(time.Now())) { | ||
| query = query.Where( | ||
| squirrel.And{ |
There was a problem hiding this comment.
As discussed orally earlier: this "pagination" like condition does not exactly match the order that we defined above - also, the index that we created is on "boost is null" (which is similar enough to "boost is not null" but the DB cannot translate) => would be better to replace by "boost is null desc" perhaps. In any case, let me just a moment to review this
If the provided case is already assigned, keep the current behavior:
→ Return the oldest, non-closed, non-boosted, unassigned case from the same inbox.
Otherwise, return the immediate next unassigned case (i.e., the one created right after the provided case), instead of always returning the oldest.