My Wishlist


Author
Message
StrataFrame Team
S
StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
If you only knew, Kevin...



Like Trent said, we're developing the security right now based on the Users/Roles approach... each permission will be assigned a key, much like the localization key, and when you assign a permission key to a control/form/object, that permission is required for the user to view/interact with that control/form/object... as for a timeline, we're not sure, but it will definitely be in version 1.5. There will be a global User object that indicates the currently logged-in user (it will be a business object containing the record for that user).
Kevin Lingofelter
Kevin Lingofelter
StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)
Group: Forum Members
Posts: 77, Visits: 804
Sounds great! Let me know if you need testing. Can you indicate any timelines?
Trent Taylor
Trent Taylor
StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 7K
Kevin,

You'll be glad to know that this one is already in the works BigGrin!  We have already started the process and plan on even allowing it to be data-driven as well.  I will elaborate on it more later, but this feature will be added to the framework. 

Kevin Lingofelter
Kevin Lingofelter
StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)StrataFrame Novice (123 reputation)
Group: Forum Members
Posts: 77, Visits: 804
Greetings!

I am going to be posting some of my wishlist for Strata. Some of my ideas are pretty long winded, so I thought I should create a post for each one.

Better security support
I would like to see role based security implemented in the layers:

Framework
1. A global object which identifies the curernt user. This identity would include username, roles collection and whether or not the user has been authenticated. It would also include methods which allow the username, password and roles collection to be modified. Another handy utility would be a function which is passed a role as an argument and it returns true if the user is in that role.
2. A User/Role editor which can be used by the programmer in their applications. These are pretty standard and would fit nicely with some of the existing SF forms already in use. Of course, the programmer can use their own form to manage uers and roles.

UI
A RequiredRole collection for Strata UI components which is bound to a specified property which can be bound to a certain property, for example the read-only state, visibility, enabled, etc. Before a control is rendered, it checks to see if the user is in the declared role(s). If not the control's property is toggled accordingly. Forms can also respond to the RequiredRoles collection by either throwing an exception or displaying the login form, etc.

Imagine this scerio:

txtSellingPrice
  RequiredRoles = {"Manager", "Owner"}
  BoundProperty = ReadOnly

If the user logged in is only a member of SalesClerk, the selling price would be readonly. If Manager and Owner, then the textbox would be editable. In the change event, I could then allow the changes to be limited by role. For example, if Manager is logged in, allow price to be changed up to 3%, the Owner can change it to whatever he/she likes.

This would allow for a more declaritive security model. If the existing secuirty model is extended to utilize roles, the programmer can also have "low level" security hooks to do whatever they wanted.

Thoughts?

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search