- Reports V3 Targeted at Master

Signed-off-by: Dave Richer <dave@imexsystems.ca>

_reference/reportFiltersAndSorters.md

@@ -3,6 +3,12 @@
 This documentation details the schema required for `.filters` files on the report server. It is used to dynamically
 modify the graphQL query and provide the user more power over their reports.
 
+For filters and sorters, valid types include (`type` key in the schema):
+- string (default)
+- number
+- bool or boolean
+- date
+
 # Special Notes
 - When passing the data to the template server, the property filters and sorters is added to the data object and will reflect the filters and sorters the user has selected
 
@@ -67,7 +73,9 @@ The following cases are available
 - `special.employees` - This will reflect the employees `bodyshop.employees`
 - `special.first_names` - This will reflect the first names `bodyshop.employees`
 - `special.last_names` - This will reflect the last names `bodyshop.employees`
-- 
+- `special.referral_sources` - This will reflect the referral sources `bodyshop.md_referral_sources
+- `special.class`- This will reflect the class `bodyshop.md_classes`
+-
 ### Path without brackets, multi level
 
 `"name": "jobs.joblines.mod_lb_hrs",`
@@ -104,6 +112,7 @@ query gendoc_hours_sold_detail_open($starttz: timestamptz!, $endtz: timestamptz!
 ```
 
 ### Path with brackets,top level
+
 `"name": "[jobs].joblines.mod_lb_hrs",`
 This will produce a where clause at the `jobs` level of the graphQL query.
 
@@ -138,16 +147,22 @@ query gendoc_hours_sold_detail_open($starttz: timestamptz!, $endtz: timestamptz!
 ```
 
 ## Known Caveats
-- Will only support two level of nesting in the graphQL query `jobs.joblines.mod_lb_hrs` vs `[jobs].joblines.mod_lb_hrs` is fine, but `jobs.[joblines.].some_table.mod_lb_hrs` is not.
-- The `dates` object is not yet implemented and will be added in a future release.
-- The type object must be 'string' or 'number' and is case-sensitive.
+
+- Will only support two level of nesting in the graphQL query `jobs.joblines.mod_lb_hrs` vs `[jobs].joblines.mod_lb_hrs`
+  is fine, but `jobs.[joblines.].some_table.mod_lb_hrs` is not.
+- The type object must be 'string' or 'number'  or 'bool' or 'boolean' or 'date' and is case-sensitive.
 - The `translation` key is used to look up the label in the GUI, if it is not found, the `label` key is used.
-- Do not add the ability to filter things that are already filtered as part of the original query, this would be redundant and could cause issues.
+- Do not add the ability to filter things that are already filtered as part of the original query, this would be
+  redundant and could cause issues.
 - Do not add the ability to filter on things like FK constraints, must like the above example.
 
 ## Sorters
-- Sorters follow the same schema as filters, however, they do not do square bracket wrapping to indicate level hoisting, a filter added on `job.md_status` would be added at the top level, and a filter added on `jobs.joblines.mod_lb_hrs` would be added at the `joblines` level.
-- Most of the reports currently do sorting on a template level, this will need to change to actually see the results using the sorters.
+
+- Sorters follow the same schema as filters, however, they do not do square bracket wrapping to indicate level hoisting,
+  a filter added on `job.md_status` would be added at the top level, and a filter added on `jobs.joblines.mod_lb_hrs`
+  would be added at the `joblines` level.
+- Most of the reports currently do sorting on a template level, this will need to change to actually see the results
+  using the sorters.
 
 ### Default Sorters
 - A sorter can be given a default object containing a `order` and `direction` key value. This will be used to sort the report if the user does not select any of the sorters themselves.
@@ -164,4 +179,4 @@ query gendoc_hours_sold_detail_open($starttz: timestamptz!, $endtz: timestamptz!
         "direction": "asc"
     }
 }
-```
+```