Access Levels

wings

We are using aware to develop a product and we have a requirement where the customer can configure ther own access levels rather than it been hard coded by us the developers.

The issue is that each client will have there own requirements for access levels.

tford

wings,

Can you give an example of different scenarios required for customers?

Tom

wings

Hi Tom

Each of our clients will have their own job titles/Structure that will differ from site to site, and they want to relate users to these job titles, so the concept of a named set of access levels pre-configured in the Aware application doesn't relate to these job titles.

It gets more complex when you consider that issues raised by client customers need to be assigned to these job titles (and hence the users occupying these job titles.

Aware gives the developer the power to control this but we need the user to have this control.

wings

tford

wings,

Access levels are only accessible in the configuration tool, as you know.

Perhaps it would be possible to use a series of attribute flags that would work with rules to so some of the things that access levels would normally do??

Tom

aware_support

Can't you have an object that represents the "job title/structure" that is different for each client, so the client will pick the appropriate instance when the system is set up for a particular client? You will then have protection rules based on the values of the instance of this object?

Again, it seems that you have a design problem here if you want dynamic access control by the users.

The advice may sound very generic, but given that you provide very little details about your system, this is the best we can do.

wings

aware_aupport

We are building a coproate business solution for an Industry Sector. Each business has its own processes and business structures depending on their size.

eg a small business will have a user who is the Cashier, Customer Support, Clerk this type of role will need access to a larger number of functions

A larger business would have a separate user for each of the above positions thus wanting to restrict access to functions and fields on the form.

The way the security appears to be designed is suited more to an inhouse developement where security levels are known, rather than a large corporate solution where the business needs to establish the security levels based on the structure in place. We may potentionally have over 100 customers with an average of 75-100 users.

aware_support

A detailed example would really help here. Certainly not all end users will be defining security levels - it will probably be the job of the system administrator, who will be setting up security levels for the specific system.

The solution to this would be to have a business object to encapsulate all security settings. The administrator system would then create a single instance of this object at the system setup time. You will then need PROTECT rules to work with the attributes of this object, for example:

If SecuritySetup.SomeFlag = 5 Then
PROTECT ...
If SecuritySetup.SomeFlag = 6 Then
PROTECT ...

Are we missing something?

wings

Certainly not all end users will be defining security levels - it will probably be the job of the system administrator, who will be setting up security levels for the specific system.

Thats correct each customer will have a system administrator looking after the access for their users

The solution to this would be to have a business object to encapsulate all security settings.

But isn't this duplicating what aware already has inbuilt? We would prefer not to build a security system around all our forms and attributes if one already exists in the tool.

I'm sure other aware users must have hit this problem before.

pbrad

Hi,

From a purist perspective it is not truly 'securing' an application but I work on the philosophy that if a user can't see an attribute or business object and has no way of accessing that attribute, business object, form, query, report or whatever then whether it is truly 'secured' from them using access levels is pretty irrelevant.

On that basis, there are a number of ways to 'secure' AwareIM on the fly from users based on checkboxes in their profile or whatever. I will often do such things as putting certain elements on a form section (tabbed or sequential) and then show/hide that section conditionally based on conditions related to that object or in your case conditions related to the LoggedInRegularUser. Similarly, I will control the visibility of certain operations whether placed in a form, query or presentation based on similar conditions.

I have found through experience that it is often far more manageable to limit the number of Visual Perspectives and Access Levels to the minimum number possible and whereever it is feasible, to limit 'access' or more accurately 'visibility' of access using rules which are entirely flexible.

We are working on one project right now where there is no menu at all. All of the information presented to the user and every choice that is offered to them throughout the application as to what they can do is controlled dynamically. The home screen is a presentation that only shows them what I want them to see and access what I want them to access.

Often one of the biggest challenges that new users face is accepting the different paradigm of AwareIM and realizing that there are often dozens of ways of 'skinning the cat'. If you search through this forum for responses from Support where their response was "Just not possible", you won't likely find very many.

Good luck with it,
Pete

Celtic

Hi Pete,

based on your post here i wonder if you or others could provide further info? this is prettu much what i'm trying to do.

I am looking to create a web form where some of the attribute fields or sections of the form are only displayed (conditional show/Hide) based on values that a user selects on other form attribute fields, basically some fields or form sections are hidden but will only be displayed based on the data entry choices a user makes.

For example if I have a drop down field on the form called “do you wish to add more info” and the drop down options are either Y or N then by selecting Y this will then display several more fields or maybe event better another form section, if a user selects NO then another a different set of attributes or a form section is displayed. In both cases these fields that are now displayed must be then able to be edited.

Basically the form is dynamically changing the displayed attribute fields that are available to the user based on some conditional information that they add in certain attribute fields. This prevents too many attributes being shown that are irrelevant and keeps forms nice n simple.

In these cases the information is not determined by the type of user or access level but simply the choices they make, is it all in the READ PROTECT info?

from this last post you seem to be doing this, could you share some of your pearls of wisdom! provide some example rules or a sample bsv would be great.

Simon.

wings

Aware Support

Can you consider extending the Protect functionality to include menu items. When that is done, our Roles will be the mechanism for security allowing the Customers System Admin person the abilty to manage the security on the system.

wings

Celtic

any thoughts? 😃

aware_support

Yes, we will consider it. We do not have immediate plans to include it in the system. If you want this urgently, we can do it as custom development.

Celtic

ahh sorry, i was referring to whether anyone had thoughts on my post on the 2nd May, rather than Wings' post !

any pearls of wisdom would be great

cheers

pbrad

Hi Support, I would dearly love this functionality. Could you please pm or email me with a cost for this mod.

Cheers,
Pete

aware_support

Answering Celtic's question. Please refer to the How To Guide - it describes what you need to do to conditionally show/hide attributes on a form

pbrad

FYI,

Wings and I are co-funding the addition of the functionality for conditionally hiding menu items and you should see it soon in a new release.

I encourage all to support AwareIM by helping to fund features like this that we all benefit from.

Cheers,
Pete

aware_support

This has been implemented in build 1199