|
| 1 | +# RWB Inactive Users Custom Query Business Logic |
| 2 | +================================================ |
| 3 | + |
| 4 | +This document summarizes the business logic behind **"RWB Inactive Users"** PostgreSQL query that identifies specific users based on their group membership, catchment areas, and work order status. |
| 5 | + |
| 6 | +## Overview |
| 7 | + |
| 8 | +------------ |
| 9 | + |
| 10 | +The query involves several steps to filter users who meet certain criteria related to their group membership, catchment areas, and recent activity. |
| 11 | + |
| 12 | +## Steps Involved |
| 13 | + |
| 14 | +------------------ |
| 15 | + |
| 16 | +### 1. **Primary Users Identification** |
| 17 | + |
| 18 | +-------------------------------------- |
| 19 | + |
| 20 | +- **Purpose**: Identify users who belong to the 'Primary Users' group and are not disabled in Cognito. |
| 21 | +- **Conditions**: |
| 22 | + - Users must be part of the 'Primary Users' group. |
| 23 | + - Users must not be disabled in Cognito (`disabled_in_cognito = false`). |
| 24 | + - Users must either have no `last_activated_date_time` or it must be older than 3 days (`last_activated_date_time is null OR last_activated_date_time < now() - INTERVAL '3 DAYS'`). |
| 25 | + - Users must not be voided (`is_voided = false`). |
| 26 | + |
| 27 | + |
| 28 | +### 2. **Work Orders Identification** |
| 29 | + |
| 30 | +-------------------------------------- |
| 31 | + |
| 32 | +- **Purpose**: Identify work orders that are not voided and belong to a specific organization. |
| 33 | +- **Conditions**: |
| 34 | + - Work orders must not be voided (`is_voided = false`). |
| 35 | + - Work orders must be of type 'Work Order' for a specific organization (`subject_type_id` matches the 'Work Order' type for the organization identified by `:org_db_user`). |
| 36 | + |
| 37 | + |
| 38 | +### 3. **Closed Work Orders Identification** |
| 39 | + |
| 40 | +-------------------------------------------- |
| 41 | + |
| 42 | +- **Purpose**: Identify work orders that have been closed. |
| 43 | +- **Conditions**: |
| 44 | + - Work orders must have an encounter of type 'Work order endline' for the same organization. |
| 45 | + - The encounter must not be voided (`is_voided is null or is_voided = false`). |
| 46 | + - There must be exactly one such encounter per work order (`having count(e.id) = 1`). |
| 47 | + |
| 48 | + |
| 49 | +### 4. **Catchments Without Work Orders or At Least One Open Work Order** |
| 50 | + |
| 51 | +------------------------------------------------------------------- |
| 52 | + |
| 53 | +- **Purpose**: Identify catchment areas that either have no work orders or have more open work orders than closed ones. |
| 54 | +- **Conditions**: |
| 55 | + - Catchments must not be voided (`is_voided = false`). |
| 56 | + - Either there are no work orders (`count(wo.wo_id) = null`), or there are more work orders than closed work orders (`count(wo.wo_id) > count(cwo.wo_id)`). |
| 57 | + |
| 58 | + |
| 59 | +### 5. **Active User IDs** |
| 60 | + |
| 61 | +------------------------- |
| 62 | + |
| 63 | +- **Purpose**: Identify user IDs that have been active recently (created or modified entities after a certain cutoff date). |
| 64 | +- **Conditions**: |
| 65 | + - For individuals and encounters, if the creation or modification date is after the specified cutoff date, the created_by_id or last_modified_by_id is considered an active user ID. |
| 66 | + |
| 67 | + |
| 68 | +### 6. **Final Selection** |
| 69 | + |
| 70 | +------------------------- |
| 71 | + |
| 72 | +- **Purpose**: Select primary users who are in catchments without work orders or at least one open work order and have not been active recently. |
| 73 | +- **Conditions**: |
| 74 | + - Users must be primary users in catchments identified in step 4. |
| 75 | + - Users must not have been active recently (their IDs must not be in the list of active user IDs). |
| 76 | + |
| 77 | + |
| 78 | +## Summary |
| 79 | + |
| 80 | +---------- |
| 81 | + |
| 82 | +This query identifies primary users in catchments without work order or atleast one open wor-order, who have not been recently active in the system. It ensures that these users meet all the specified criteria related to their group membership, catchment areas, and recent activity. |
| 83 | + |
| 84 | +## IMPORTANT Additional Details |
| 85 | + |
| 86 | +- The CutOffDate for determining in-activity is 3 Days from current date. |
| 87 | +- Also, if the user has been nudged in the last 3 days, we do not nudge him again. |
0 commit comments