- Progress Commit, this fills agreed upon functionality

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

_reference/reportFiltersAndSorters.md

@@ -3,6 +3,9 @@
 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.
 
+# 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
+
 ## High level Schema Overview
 
 ```javascript
@@ -36,6 +39,35 @@ const schema = {
 Filters effect the where clause of the graphQL query. They are used to filter the data returned from the server.
 A note on special notation used in the `name` field.
 
+## Reflection
+Filters can make use of reflection to pre-fill select boxes, the following is an example of that in the filters file.
+
+```
+    {
+      "name": "jobs.status",
+      "translation": "jobs.fields.status",
+      "label": "Status",
+      "type": "string",
+      "reflector": {
+        "type": "internal",
+        "name": "special.job_statuses"
+      }
+    },
+```
+
+in this example, a reflector with the type 'internal' (all types at the moment require this, and it is used for future functionality), with a name of `special.job_statuses`
+
+The following cases are available
+
+- `special.job_statuses` - This will reflect the statuses of the jobs table `bodyshop.md_ro_statuses.statuses'`
+- `special.cost_centers` - This will reflect the cost centers `bodyshop.md_responsibility_centers.costs`
+- `special.categories` - This will reflect the categories `bodyshop.md_categories`
+- `special.insurance_companies` - This will reflect the insurance companies `bodyshop.md_ins_cos`'
+- `special.employee_teams` - This will reflect the employee teams `bodyshop.employee_teams`
+- `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`
+- 
 ### Path without brackets, multi level
 
 `"name": "jobs.joblines.mod_lb_hrs",`
@@ -71,7 +103,6 @@ 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.
@@ -114,7 +145,6 @@ query gendoc_hours_sold_detail_open($starttz: timestamptz!, $endtz: timestamptz!
 - 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.