Skip to main content

Data security and privacy remain important aspects of everyday life and in the Thinkwise Platform. Therefore, as of release 2021.1, we created a new access type: 'unauthorized', which can be used for columns, tasks and reports. And on top of that: you don't need to set up the columns yourself, but the Software Factory does it for you! 

Hidden or unauthorized? 

Now before explaining how that's possible, let's first set out the difference between a hidden and an unauthorized column. A hidden column was already available in the Software Factory. It means that the column is hidden visually from the user interface. That's quite safe already, but in some cases the data might still be approached through Indicium. Unauthorized columns on the other hand can't be approached in any way. The user interface or any API won't even know the column exists, so that's an even safer way to protect your sensitive data.

Until now, the best way to get the same effect was excluding columns from a basic table in a view. This was quite a lot of work, though.

Rules for unauthorized columns

To save you a lot of work, the Software Factory combines two settings to decide whether a column is unauthorized. The first is the Column type in the data model and the second is the Access type (menu Access control - Roles). If either the Column type or the Access type is hidden, the column will automatically get 'Unauthorized' as Effective access type.

The same system applies to task and report parameters. The first setting the Software Factory uses is the Column type used in the Task parameter or Report parameter (menu Processes - Tasks/Reports - Task parameters/Report parameters). The second setting is the parameter's Access type (menu Access control - Roles - Tasks/Reports - Task parameters/Report parameters). If either the Column type in a task or report parameter or the Access type applied to the task or report parameter is hidden, the column will automatically get 'Unauthorized' as Effective access type.

For a better understanding of why the effective access type is as it is, select a row and click on the question mark task: Image. 

Exceptions to the rules

There are a few exceptions to these rules however. In the instances mentioned below a column will never be unauthorized but only hidden, because unauthorized data would break the user interface: 

  • A role is an administrator role with all rights assigned to it.
  • A column is used as a primary key.
  • A column is used as the primary look-up display column.
  • A column is used as a conditional layout target.
  • A column is used as a conditional layout condition.
  • A column is used by any extender in any way, shape or form.
  • A column is used in a tree for grouping (parent or child), display or icon (base or variant).
  • A column is used in default sorting of a variant default sorting.
  • A column is used by another column in the same role as look-up display field.
  • A column is used by a granted cube field in the same role. (Yes, cube fields that can be granted individually is another cool feature that'll be available in the 2021.1 release!)

More information?

See the Software Factory manual in the Thinkwise Docs, chapter: Hidden, read-only, full rights or unauthorized.

Clearly explained, thank you for this well-arranged blog.

Thanks Jeroen!

Looking forward to this!

Question: Hoe is the execution of the default / layout and context procedure being handled when a column is unauthorized?

The logic execution is handled by Indicium. Indicium still has access to the full model.

When the architecture does not include Indicium, column authorization cannot take effect. The client will have (and need) direct database access in a 2-tier scenario.

Reply


Terms & ConditionsCookie settings