I’m interested in hearing idea for how people are implementing field-level security in their solutions.
I’ve got an existing solution where the client is interested in implementing much stricter control for certain groups in their organization, and I’m having a bit of trouble implementing something that I’m comfortable will offer the right balance of security and maintainability.
For my needs currently, I think that what I’d really like is to be able to configure field access rights at the table level. Servoy, however, only supports table-level configuration.
Configuring security on elements on the form level just doesn’t feel comfortable to me. I’ve got situations where a group should only be able to edit field X and Y on a particular form. If I configure security to limit them to those to fields, I’ve got to remember to update it everytime I add a new field that they should not be able to edit to the form. That’s a setup for failure – for me at least.
Plus, you’ve got the issue of the same fields appearing on multiple forms. Ugh.
I’m willing to roll my own solution, but before I get too deep in planning that, I’m interested to here if others have already come up with something useful in this area – or, of course, if I’m just missing something obvious.
Can you give me a more precise scenario? Are you interested in implementing subscription security on fields, or to be able to set security access levels to fields for certain groups?
Well, I’ve got a couple of scenarios, but mainly, in this case, I’m really just wanting to be able to specify group security on the column level.
So if I’ve got an “orders” table, I want the “Sales” group to be able to update records, but not edit a certain set of fields – like “discount” and “terms.”
I want the “Accounting” group to be able to edit “discount” and “terms”, but not “sales_notes”, etc.
This can be accomplished with form element security, but boy you really have to be careful. With a solution that changes a lot, it’s very difficult to keep up with newly added fields and fields that appear on multiple forms.
I’ve experimented with a few solutions, like testing what element is being accessed in onRecordEditStart and only allowing edit mode if you are in a permitted field – but, you also have to make sure the user can’t tab to another field once in edit mode.
I could also break out tables for certain data on 1:1 relations, but, again, it’s a dynamic solution and the client changes their mind a lot so it’s hard to tell what fields would go where – and it’s not a good performance/reporting solution to add the layers of joins.
I could also maintain multiple sets of forms per group, but that’s also a bit of a nightmare for maintenance.
I am really interested on a reply for this. I know it’s been quite a while it was posted, but I’m looking for solutions to implement security in my project and the issues are the same as the ones mentioned above. How to implement field security? Are people creating tables to map the fields with security settings (visibility, etc.)?
This post was before the solution model came out. With the solution model you can build any form you want on the fly based on whatever rules you set up.
Ideally you would write abstract code to generate a version of your source form based on rules that are defined as data.
Defining the rules as data needs an interface. That interface would allow you to choose a source form, generate all the data points that defines the source form, then assign which groups that can view/edit each data point.
This data interface allows even a non-programmer to manage many variations of base forms. The only way to go if you have a solution that has many forms and many users with different access levels.
I agree with David, I had to implement a similar security in a big solution years ago (servoy 2.2), it was and it still is a real PITA every time you add a new field. You need to define (using servoy security GUI) if the field is visible/editable for EVERY group.
If you start from scratch I really advise you to go the way that David hinted and use the solution model.
It was the only game in town at the time and the customer was very happy to be able to hide the price column or to disable an entire tab based on the group the users belonged to.
So, to recap: it’s a real PITA but it’s doable, but if I should start from scratch I would be very very happy to spend some time to evaluate what hurts less between the element level security and the solution model, also using the solution model throughout the whole solution could turn to be not so funny.
ngervasi:
So, to recap: it’s a real PITA but it’s doable, but if I should start from scratch I would be very very happy to spend some time to evaluate what hurts less between the element level security and the solution model, also using the solution model throughout the whole solution could turn to be not so funny.
Totally agree. If you’re at this point and don’t have a well thought out solution structure in place the solution model approach could easily turn out to be just as unmanageable.
We recently wrote this into our frameworks for a client. It plugged quite nicely into our navigation engine and access & control abstractions:
the form combobox also lists all tab panels. This allows you to drill down to elements however many form levels deep.
the “all elements” list is the default element security settings. The import routine uses what you created originally which you can then adjust here.
you can further secure elements by group in the right column.
FYI: there is a bit of a trick to “reattach” form and element event methods. For now, this is part of the secret sauce of our frameworks…
