Allow End User to manage own user access

[CGibson]

Hello,

A while ago Barry posted the following information:
http://www.lianja.com/community/show...nd-Permissions

Has anyone attempted to make their own application so that end users can manage their own users and permissions?

In the dynamic section, there is a section for app. Is this the app name, if so how would the end user know this information?
How would we access the system user tables in our apps (main database is not stored locally)?

If we continue to manage the users using the App Builder, how would we separate specific users associated with one business versus another business?

Cory

[HankFay]

Hi Cory,

this article http://www.lianja.com/doc/index.php/Users_and_Roles should answer most of your questions. If you forget the link, search for "dynamic roles" on the wiki (without the quotes). Take a look at the section of the document titled "Customizing Deployed Users and Roles".

On the issue of users from multiple companies managed on the app builder: that's the subject of an ER already submitted (by me, which is the only way I'd know whether it had been submitted <s>). Assuming one has created an administration app, the real challenge is when you are testing a cloud app, and customers are hitting your test server to which you deploy a version for testing. Probably the best way to handle it (as contrasted with what I am doing now <s>) is to use the administration app you create to CRUD users and roles on the deployed version. It gets trickier with tenancies, but without tenancies you would only need the admin user to get into the app and handle users.

hth,

Hank

[CGibson]

Hi Hank,

Thanks for the response.
I don't think I had seen that page yet.
It does have a lot of useful information.

Cory

[barrymavin]

Hi Hank,

Users from multiple companies are handled already by specifying the "tenancy" as a "domain" in the user record in system!sysroles.

When that user logs in the database they use is specific to their tenancy,

Users are grouped into tenancies.

Your ER (if i understand it correctly) is to handle multiple system databases so that the system database is specific to a tenancy. This is a catch 22 as you don't know the tenancy until the user has logged in.

My assumption is that you want a system database specific to an app or group of apps. The ER has been submitted but I need to properly think it out and how this will work in Web/Mobile without being a security weakness.

[HankFay]

Hi Barry,

yes, it gets complicated. Even more so when using a web service, where the usual login isn't available, so that tenancy has to be held in a general system database, and then the database is switched on-the-fly. I save the tenancied-database in a session variable for subsequent calls. Save datasession would work, although not every table is used on every web service request, so there are fewer tables to reopen when doing it as needed (a prg that checks whether the db and alias are open, and open only if needed).

The answer is, I believe, to create the user and dynamic roles apps and have that done by an admin for each app. That way everything is easy to manage. Only the admin_<thetenancy> user needs to be in the dev system, the rest gets done on the instance of the application. I'll likely be creating one for a consulting client, and if so, will add it to LianjaX.

thanks,

Hank

[barrymavin]

Hi Hank,

As I mentioned earlier I will look into the best way to implement this when I make full tenancies available. Currently the system!sysroles table determines what database a certain user will use.

Tenacies are more for regular apps than custom web services as these can be programmatically handled.

[HankFay]

Hi Barry,

understood.

In this case, the regular app is the manager for the web service. And on a given server, there would be <n> instances of the app. It all works out, in any case. The key is having an id for the source that matches up to a tenancy table in the default database (public), so the switch can be made. That makes sense from our perspective of managing multiple partners all using the same interface to their various POS systems.

And I so think that the larger issue of managing users, even in a test environment, can be handled through a central system database. Separating users into one tenancy at a time can be handled by the UI. So, separate system db's probably aren't needed.

thanks,

Hank