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.
Access Levels
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
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
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
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.
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.
Aware IM Support Team
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.
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
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
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?
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?
Aware IM Support Team
Thats correct each customer will have a system administrator looking after the access for their usersCertainly 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.
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.The solution to this would be to have a business object to encapsulate all security settings.
I'm sure other aware users must have hit this problem before.
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
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
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.
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.
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact: