description: The Data Controller roadmap is aligned with the needs of our customers - we continue to build and prioritise on Features requested by, and funded by, new and existing customers.
On this page you can find details of the Features that have currently been requested, that we agree would add value to the product, and are therefore in our development roadmap.
Where customers are paying for the new Features (eg with our discounted Developer Days offer), then those Features will always take priority. Where funding is not available, new Features will be addressed during the Bench Time of our developers, and will always be performed after Bug Fixes.
Where features are requested, whether there is budget or not, we will describe the work below and provide estimates. Each task is given a Story Point (SP) value, and each SP is roughly 0.5 days (SCRUM masters - please don't lose your T-Shirt over this sizing approach!)
There are currently four features requested and sized, with estimates as follows:
The existing filter box provides a list of values when selecting operators such as "IN", "=" etc. The problem is that this dropdown does not consider existing filter selections. So if a user filters on, say, "region", and then filters on "store", they will see stores for ALL regions (not just the region/regions already selected in the filter).
#### Proposed Solution
We add a checkbox to the top right of the filter dialog (default ON) for "Dynamic Filtering". Whilst enabled, whenever a list of values is requested, it is filtered using every filter clause EXCEPT the one currently being modified.
Currently when calling the 'public/getcolvals' service we provide a single table (iwant) with two values (libds & col). This service needs to be extended to include an additional input (filtertable) with one column (filterline). The filter query will be split across multiple rows in this table.
The challenge here is similar to that of [Dynamic Filtering](/roadmap/#dynamic-filtering) - when editing a value in a grid, the values presented to the user should be filtered according to additional rules, based on the values of other cells in the same row.
Given the near infinite possibilities by which this list could be generated, the solution proposed is that provide a new config item in the MPE_VALIDATIONS table - one that links an editable column to a HOOK script via a web service.
If RULE_VALUE is left empty, we can default to filtering according to the value of the (remaining) primary key value(s).
The HOOK_SCRIPT can be either a SAS program on a filesystem (identified by a ".sas" extension) or the path to a registered SAS Service (STP or JES). The latter is identified by the absence of an extension.
- [ ] Prepare hooks for all target cols as defined in the `editors/getdata` response
- [ ] When in EDIT mode and the user selects the dropdown, call the `editors/get_dynamic_col_vals` service with the currentrow as input
- [ ] Whilst calling the service, a spinner should be presented and the page frozen
- [ ] On response, the dropdown is populated, and the service is not triggered again unless another cell in that same row ismodified (so if the user navigates away, and comes back, the service is not necessarily triggered again)
- [ ] If a user PASTES input (or provides input via Excel upload), then the hook is NOT triggered, even if it is a HARD select(in this case we would rely on backend validation, which is NOT yet implemented)
- [ ] Prepare tests covering all use cases in the Cypress test suite
Row level security is provided by various products in both SAS 9 and Viya, based on the logged in user identity.
This is problematic for the EDIT page, which - by necessity - operates under system account credentials.
It is also the case that some customers need row level security but the data access engine does not support that.
Therefore, there is a need to configure such a feature within the Data Controller product.
#### Proposed Solution
A new table (MPE_ROW_LEVEL_SECURITY) will be added to the data controller library with the following attributes:
|Variable|Description|
|---|---|
|RLS_SCOPE| Does the rule apply to the VIEW page, the EDIT page, or ALL pages|
|RLS_GROUP| The SAS Group to which the rule applies. If a user is in none of these groups, no rules apply. If the user is in multiple groups, then the rules for each are applied with an OR condition.|
|RLS_LIBREF|The library of the target table|
|RLS_TABLE|The table to which to apply the rule|
|RLS_COLUMN|The column to which to apply the rule|
|RLS_OPERATOR|The operator to apply, such as `=`, `<`, `>`,`!=`, `IN` and `CONTAINS`|
|RLS_VALUE|The value to which be used in the comparator|
|RLS_ACTIVE|Set to 1 to include the record in the filter, else 0|
Data Controller uses an OEM licence with the excellent [sheetJS](https://sheetjs.com/) library. This enables us to read pretty much any version of Excel at breakneck speeds.
By default, Data Controller will use the data model of the target table when extracting data, eg to determine whether a column should be character, numeric, date, datetime or time.
Formats are ignored and the cell _values_ are extracted when formulas are being used.
We now have a use case that the customer would like to extract and retain the actual formula itself, so it can e re-used when downloading the data again later.
#### Proposed Solution
A new table (MPE_EXCEL_CONFIG) will be added to the data controller library with the following attributes:
|Variable|Description|
|---|---|
|XL_LIBREF|The library of the target table|
|XL_TABLE|The table to which to apply the rule|
|XL_COLUMN|The column to which to apply the rule|
|XL_RULE|The rule to apply, such as FORMULA|
|XL_ACTIVE|Set to 1 to make the rule active, else 0|
|||
#### Technical Implementation
The additional configuration table must be provided to the frontend so that any imported Excel files may have the corresponding rules applied. Formulae will be imported as simple text strings - the target column must therefore be of character type and be fairly wide (at least $64 but preferably wider to avoid formula truncation)
- [ ] Creation of new table using SCD2 for history retention
- [ ] Inclusion of new table in the build process
- [ ] Update the migration scripts for customer upgrades
- [ ] Update the `edit/getdata` Service to include a new output table for excel config
- [ ] Create a post edit hook service to ensure that any new FORMULA fields added do in fact exist, and have character type, with a minimum width of $64
- [ ] SASjs tests to validate the new service output, and validation logic
- [ ] Macro Documentaton
- [ ] Service Documentation
- [ ] User Documentation, including screenshots
Frontend:
- [ ] Where configured, columns are extracted by formula rather than value
- [ ] Cypress tests (with corresponding excel files) are created to cover cases such as: one formula column, 3 formula columns, formula columns where values are not formulas, complex formulas, formatted formulas.
When importing spreadsheets with ambiguous dates (eg 01/02 or 02/01) the ANYDTDTM. informat was using the locale of the browser (en_us) instead of that of the client's actual country, resulting in incorrect dates being loaded. This is due to the [default behaviour](https://rawsas.com/look-out-locale-gotcha/) of the SAS Stored Process server.
#### Solution
We added a [new config item](/dcc-options/#dc_locale) so that the locale can be explicitly set for all Data Controller users.
Data Controller relies on metadata permissions (in SAS 9) or authorization rules (in Viya) to determine who can see which table.
We had a customer who was using Data Controller to provide data access to a company wide audience, most of whom did not have access to SAS client tools (such as Enterprise Guide) and so had not been set up in metadata before.
It was necessary to find a way to restrict the tables which certain groups could see, without having to tweak permissions in SAS Management Console.
#### Solution
We added a [new access level](/dcc-security/#view) in the MPE_SECURITY table so that access could be restricted at both TABLE and LIBRARY level.
