Servoy’s built-in security is fine for a few groups, a few basic form settings, and maybe an organization or two. And only if you don’t need a whole lot of flexibility to adjust things at runtime. Anything beyond that and you’re writing your own UI’s, code and possibly your own tables to manage things in a much more powerful and flexible way.
Servoy’s internal security tables and associated methods are there for the developer to build their own UI’s to manage things the “Servoy” way. This approach is solid and ties in with various design-time screens. Issues come into play when coordinating with your own data tables (hybrid approach) and when you need more flexibility than what Servoy gives you. For example:
Kahuna:
The simple Security built into Servoy would be much easier to manage, because we can define rights to groups at design time and let Servoy take care of access right down to specific buttons etc.
Servoy’s design-time element level security is not-so-simple anymore if your rules need to change based on what record the user is on. (IE, ‘my’ records I can edit but John Doe’s records I can only view.) And what about giving a power user run-time control?
After doing a few security schemes back in the day via Servoy’s (and hybrid) approach we finally decided to supercede Servoy’s system completely. So all our own tables: organizations, groups, users, logins, logging, etc. Then on login we push everyone through a couple of basic Servoy group and user records.
Our “strategic thinking” is groups define what people can see and do (typical). Logins are assigned to one or more groups. User tables (default supplied or from a CRM or Active Directory, etc) can be attached to our login records.
Security is in four tiers:
1- what views can be accessed (navigation).
2- what records can be accessed. filter by organization and further filter by group level rules.
3- what actions can be run. each workflow form can expose rules (via form variable object).
4- form element states. what shows up and editable or not.
1 and 2 can be managed entirely by UI (meta data). In addition to the UI component (actions registered by forms assigned to groups), 3 and 4 require code at the form level (usually onLoad and onRecordSelection events) to setup and manage state. We provide an API to make this easy. Example:
function REC_on_select() {
// editing control
if (globals.SUTRA.security.workflow.allowed('employee edit')) {
TOGGLE_elements(true)
}
else {
TOGGLE_elements(false)
}
// status field
var superStatus = ''
if (flag_status) {
superStatus += 'INACTIVE '
}
// status label
elements.lbl_super_status.text = 'User: ' + globals.SUTRA.security.getUser().staff.name
}
If needed, we will pull the above code out and create a UI for that particular client module to manage form level elements at runtime. We specifically do this on a case-by-case basis instead of in our core security module because of the plethora of customizations each situation can entail.
The key to making all this work is a layout manager that can be driven by security, the concept that forms publish their access rules, an API to make coding against simple, a four tier approach to keep complexity down, and the UI screens to manage everything at runtime. I think these same concepts apply for a hybrid system – but having to hook into Servoy’s security system just makes it harder to build in my opinion.
The end result is that any application can be run by this security system. Wonder why our Sutra CMS doesn’t have security built-in? Because it is a set of modules that is meant to be plugged into this setup. Same security UI for Sutra CMS and any other modules/solutions it is working along-side. Module portability requires that security be abstracted.
None of the things you bring up are a problem for us. And we run in web client now (even provide a login widget for websites). Want to save a buttload of work? ![:)]( "Smile")
http://demo.data-sutra.com
