Roles and Permissions for Non LOB applications

I have been going through the roles and permissions and think I understand how they will work with a LOB or in house application, ie an app is developed for a sales team and users can be created for that sales team with the roles being defined for each page, section etc. My question relates to commercial applications developed where one does not know who or what the groups or roles will be i.e. for a helpdesk application,there could be a run time group created for London Support, Johannesburg Support, but the roles in e.g. a section are defined at development time.

How is it possible to update the roles within pages, sections etc at runtime, or have I missed the point completely?

Hi Leon,

Do you foresee a difference on how one location uses the program versus another location?
In my opinion, typically the end user's functionality should be the same regardless of the location if they are performing the same job.

This may not be the best solution, however you can always save a page as a template as reuse it with different options.

I don't think you can dynamically set permissions, although I could be wrong.

Cory

Hi Leon,

use roles and permissions as the the macro-level filter; and then set the filter for the sections in question as a expression in the filter alltribute of the section.

So, e.g., if you have an employee table, employee, with a field for where they are located, cStaffLoc_FK, and that same Loc_FK is in the support records, then in the filter of the header section for support you might put:

cLoc_FK = employee.cStaffLoc_FK

hth,

Hank

Hi Cory/Hank

Thank you for your reply.

In our current helpdesk application all the 'visibility' of data is configured at runtime as the software is deployed across a variety of locations, departments and also inter company. For example company A may log calls against a SAP call category so they do not need to see other categories while company B only needs to see a Dynamics category. The list of examples is endless.

Hank, I suspect that your suggestion may be the answer. This will have to be done in code where we build our own security. Any suggestions welcome.

Many Thanks

Leon

Hi Leon,

I know there are a lot of developers who just love to write code but before you go writing code that may not be necessary let me try and explain how Lianja UI states work and why they are good for you to consider using.

The roles are all in the system!sysroles table (thats what the "Users" workspace works on). You can do what you want with this table at runtime. Passwords use the built-in md5() function to encrypt them.

The userName() function returns the name of the logged in user.

The userEmail() function returns the email address for the logged in user.

The userRoles("username") function returns a comma separated list of roles applicable for a given user.

The userDomain("username") function returns the "domain/tenancy" for that user.

UI states can be used to hide/show UI elements based on the "roles" that a certain user has. Changing the "state" of the UI can set filters on sections. You create states using the UI state editor and change states using either the Lianja system object Lianja.changeState("name_of_the_state") or an inline delegate $("changestate:name_of_the_state"). The UI states editor has the ability to set multiple attributes for a given state. Why is the UI state machine important? Answer, because you don't have to hard code filters or anything like that into the App and you can modify "states" in one place.

It's just a matter of understanding how users, roles, permissions and states can be combined to provide a different UI presentation depending on who the user is that has logged in.

Hi Barry

Thank you for your detailed reply. More coding is the last thing on my mind hence my interest in Lianja. I am trying to take that away from the techies.

We will need to do some experimenting to fully understand how this all hangs together, but it does look like the combinations will be sufficient for us to achieve what we are trying to do.

Many thanks for the support.

Leon