Hi Robert,

Regarding the separate businesses, to achieve your goal, you should really model those businesses as part of your data model, queries and business logic and specify in your application which users belong to which businesses.

Regarding “acess levels”, for the first two stories in your example, the different roles people play really map directly to the standard Agile Platform Roles (see help here) which should be very easy to use. If you want to support the third story, then you’ll need to have multitenancy on the data, which means applying row level security (ensure that a user only sees data he is allowed to for a given condition). As such, I would

1. Model the Business -> BusinessRole -> User relation in the application and manage it in a custom backoffice
2. Eventually create a hidden Group for each combination of User – BusinessRole
3. Create a helper function CheckGroup(RoleId, UserId, GroupId) that allows you to check on every screen if the user has access to that data.
4. On the queries, you’ll need to enforce that the returned data is relative to that customer

Hope this helps.

All the best,
     Pedro Oliveira 

I found that in a SaaS scenario, you need to model it yourself like I did in my SaaS Framework, to get the flexibility you need. Last I checked, the multi-tenency has issues with multiple applications per machine. :(

If you're looking to do a SaaS-type situation, feel free to Skype me and I'll gladly give you some pointers on what I did.

J.Ja

Hi,

Thanks for your contribution guys. In fact you're both right.

When I talked about "multi-tenancy" above I was really talking about the concept and not the "multi-tenant feature". At this point the feature does have a set of limitations, which we will address at some point, which probably make it not be the best option for this specific scenario.

All the best,
   Pedro

Here's what I did to solve this issue...

(cheap plug: I sell the full package for handling this, a kind of "starter kit" for SaaS applications... contact me if you would like more details)

First, I use the Users entity, but I ignore all of the "USER_MASTER" kind of stuff. I just use the built-in functionality for handling users, sessions, logins, etc. But I add a "USER_DETAILS" entity which is extendable and refers to the "User" entity. I also have an "ACCOUNT" entity which represents one of our clients. USER_DETAILS links to ACCOUNT, and ACCOUNT links to a User as the "Account Administrator" (that user also get the "Account Administrator" privilege assigned to it). In certain parts of the application, it looks for the combination of checking to see who the Account Administrator is, and validating the current user having that privilege, to allow upscale access. I use a "CUSTOMERS" entity to represent the customers of the application's clients.

In the Spanner Planner application (www.spannerplanner.com) which allows auto repair shops to manage their work, the chain is like so:

ACCOUNTS (Mike's Repair Shop, Jimmy's Muffler Shack, etc.)
Users (Mike's Repair Shop: Mike [Account Administrator], Susan, John; Jimmy's Muffler Shack: Jimmy [Account Administrator], Louis, Barbara)
CUSTOMERS (Mike's Repair Shop: Car Dealer 1, Car Dealer 2, etc.; Jimmy's Muffler Shack: Car Owner 1, Car Owner 2, etc.)

All entities need to have a link to ACCOUNT, so that you can check which ACCOUNT the current user belongs to, and check it against the ACCOUNT of the entity, to validate that they should have access. Otherwise, someone could take an ID in the URL, change it, and potentially access data belonging to another ACCOUNT. For the same reason, you never want to just count on the "Account Administrator" permission, you want to combine it with looking at the Account Administrator attribute of ACCOUNT to ensure that the current user is the admin for the account in question.

I've got a ton of other things built in too, like password resets (both self-service and by the account administrator), allowing account administrators to add users to the account, monthly billing, closing accounts when billing fails, a global admin system, and so on.

J.Ja

Thanks for the response guys.


This might work.....

All data belong to the CompanyUserId, where multi user can login as the the company user id and manage items that belong to companyuserid.
-Once logged in, set session.EffectiveUserId to the logged in UserId.
-After this look up "UserAccess" by EffectiveUserId to see which company the current logged in user can manage.
-Once the user selects a Company, log into using CompanyUserId
 -Now in every webscreen and action verify the session.effectiveUserId has permission to perform the required task.

 

UserAccess

• Id
• CompanyUserId (the company master userId that the log in user wants to manage)
• UserId (UserId logged In)

Permission

• Id
• UserAccessId
• PermissionTypeId

 

PermissionType

• Id
• Name

Robert -

That is definitely an interesting approach that I had never considered! If it meets your needs, then I say go for it. I think the key here, is to realize that you'll need to make sure that on every screen, you carefully check data ownership, regardless of how you approach it at an entity level.

J.Ja