7a2918a856491d120df45518745b9800e8ca5fff
Field-Level-Security-Integration.md
| ... | ... | @@ -0,0 +1,24 @@ |
| 1 | +#Field Level Security Integration |
|
| 2 | + |
|
| 3 | +##Field Level Access |
|
| 4 | + |
|
| 5 | +The field level property ``FieldFilterRegex`` is a regular expression property that filters based upon the string it's given. The user would not see any fields containing the words 'pass', 'admin' or 'pw'. |
|
| 6 | + |
|
| 7 | +[[Please see this example|Controlling access to fields]] |
|
| 8 | + |
|
| 9 | +**Record Level Security Integration** |
|
| 10 | + |
|
| 11 | +- Row and Cell Level Access |
|
| 12 | + |
|
| 13 | +Izenda Reports supports the unique feature of being able to hide report data on-the-fly on a per user basis. Consider this scenario: Bill, Mary, and John are all sales people. You want to generate the same report for each of them, but with different sales territory data. With Izenda Reports, simply generate one report, give each user a link to that report, and change the filter for each user to show the specific sales data. |
|
| 14 | + |
|
| 15 | +In this example, the ``PreExecuteReportSet`` method adds hidden filters to limit data on-the-fly. |
|
| 16 | + |
|
| 17 | +```csharp |
|
| 18 | +public override void PreExecuteReportSet(Izenda.AdHoc.ReportSet reportSet) |
|
| 19 | +{ |
|
| 20 | + Izenda.AdHoc.Filter f = new Izenda.AdHoc.Filter("TerritoryID"); |
|
| 21 | + f.Value = GetCurrentUserTerritory(); |
|
| 22 | + reportSet.Filters.AddHidden(f); |
|
| 23 | +} |
|
| 24 | +``` |
|
| ... | ... | \ No newline at end of file |