Hi, Readers.
Today I would like to talk a little more about permission sets. How to use Security Filters.
For record-level security in Business Central, you can use security filters to limit a user’s access to data in a table. A security filter describes a set of records in a table that a user has permission to access. You can specify, for example, that a user can only read the records that contain information about a particular customer. This means that the user cannot access the records that contain information about other customers.
There are two parts to implementing security filters.
- Creating the security filters on the table is typically done by an application administrator. (Today’s topic)
- Defining how the application behaves when the filters are applied is done in application code by a developer. (For example, How to make some filters mandatory on the list page (users can not change or remove))
Creating security filters
You create security filter by using the Business Central client. You set security filters on permission sets, which you assign to users.
1. Open the Permission Sets page.
2. On the Permission Sets page, select the permission set to which you want to add a security filter, and then choose Permissions.
3. On the Permissions page, in the row for the table data to which you want to add a security filter, select the Security Filter column to open the Table Filter page.
For example: 18 Customer
4. In the Table Filter page, in the Field Number column, select the field on which you want to limit a user’s access.
The Field Caption column in the Table Filter page is filled in automatically after you select the field number.
5. In the Field Filter column, enter the value of field that you want to use to limit access.
For example: Customer.”No.” = 10000|20000
Note:
Record level security filters do not support wildcard characters. This means that you cannot use * and ? in the filters. You can use other symbols, delimiters and, operators, such as, <, >, |, &, .., and =. If you do not enter an operator, then the default operator = is used.
Security filters support Unicode characters. The maximum length of a security filter is 200 characters, including all field names, delimiters, symbols, and operators that used in the filter.
When multiple permission sets that refer to the same table data are assigned to a user, they are combined so that the least restrictive filter is used. You should not repeat a table in multiple permission sets if you plan to combine those permissions sets for one user.
Completed.
Then assign the permission set to the user.
Test Video:
SecurityFiltering Property
When you create security filters, you limit a user’s access to data in a table. Therefore, code that requires access to all data in a table fails and the user receives an error message.
For example: The filter is the same as above. Customer.”No.” = 10000|20000
A security filter has been applied to table Customer. You cannot access records that are outside of this filter.
You can resolve potential conflicts with security filters and specify the desired behavior by setting the security filtering mode on Record variables to determine how the security filters are applied.
SecurityFiltering Property:
Specifies how security filters are applied to the record.
Applies To:
- Record variables
- Records on pages, reports, and XMLports
- Query variables
Property Value:
| Value | Description |
|---|---|
| Filtered | All security filters are applied to this instance of the record. |
| Ignored | All security filters are ignored for this instance of the record. |
| Disallowed | Security filters are not allowed on the record. If any security filters are set, then you receive an error when you run the object that uses this instance of the record. |
| Validated | All security filters are applied to this instance of the record and if any code tries to access a record that is outside the range of the security filters, then an error occurs. |
Syntax:
RecordVar.SecurityFiltering := SecurityFilter::<Disallowed|Filtered|Ignored|Validated> 
[SecurityFiltering(SecurityFilter::<Disallowed|Filtered|Ignored|Validated>)]
Default values:
| Explicit record variables | Explicit query variables | Implicit records on pages, reports, and XMLports | |
|---|---|---|---|
| New | Validated | Filtered | Filtered |
It is not supported to change the default Filtered value of the SecurityFiltering property on implicit records on pages.
Let’s see some examples:
1. SecurityFiltering::Filtered: If a record is set to Filtered, then any security filters that have been set are respected for this instance of the record. To the user, it is as if records outside the security filters that do not exist.
Test Video:
2. SecurityFiltering::Ignored: If a record is set to Ignored, then any security filters that have been set are ignored for this instance of the record.
Test Video:
3. SecurityFiltering::Disallowed: If a record is set to Disallowed, then setting any security filter on the record causes an error.
A security filter has been set for table Customer. This is not allowed for the current function.
4. SecurityFiltering::Validated: If a record is set to Validated, then any security filters that have been set are respected for this instance of the record, and an error occurs if the code attempts to access a record that is outside the range of the security filters.
Error:
A security filter has been applied to table Customer. You cannot access records that are outside of this filter.
No Error:
Test Video:
Find out more about Using Security Filters from Microsoft Docs.
END
Hope this will help.
Thanks for reading.
ZHU
コメント