On the Windows desktop, user() returns the login from Windows, username() the name you use to login to the App Center or when you manually login to the App Builder.
When you install the Lianja App Builder, one user is already created - the 'admin' user, with the same password: 'admin'. You don't need to use these login details when you start the App Builder - you will be logged in automatically - but, you do need them to log into the Lianja App Center or when you log out of the App Builder Home Workspace and want to login again without exiting the App Builder.
When you Deploy, remember that you need to Deploy the system database along with your App, Data and Library scripts, so that your user and role data is available in the runtime environment.
If you want to handle this in code, you can control the visibility and updatability in the UI Presentation Rules.
Q:
control user access to certain command buttons on my Canvas page?
A:
You can use the UI presentation rules to "hide" or "disable" command buttons based on the UI presentation rules for "Visible when" and "Enabled when". These only take effect when you switch into runtime App view.
In order to maintain a consistent UI layout it may be better to disable specific buttons depending on who has logged in and what their roles are.
The userRoles() function can be used to get the roles of the logged in user then adjust the UI behavior accordingly in your custom section.
After careful consideration and considering the real need for database tenancies this has now been tied in properly with a users tenancy (domain) that is specified in the "Users" workspace.
This has been implemented as follows which fits in better with the overall architecture of the Lianja Platform.
Database tenancies are based on the authenticated user. The "Database" used by an App for a particular user in a specified tenancy is postfixed with an "_" followed by the tenancy (domain) for the user specified in the "Users" workspace.
For example, if the database for an App is southwind and the user has a tenacy (domain) specified of xyzco
then the database used for that user will be southwind_xyzco.
When the user authenticates in Desktop, Web or Mobile apps the specified database will be used rather than the default database for the App.
Remember to "Deploy" the system!sysroles table and the database for that tenancy from the "Deploy" workspace.
If a user who authenticates has no tenancy specified then they belong to the "public" tenancy.
You can think of a tenancy (domain) as a "company" or "organization".
This provides the ability to host a complete suite of Apps in the cloud or on a LAN with multi-company access but still maintaining security of the data across companies.
If you have hosted the Apps then you can of course consolidate information across multiple databases if you have that requirement.
We've had several developers asking how to run the same Apps against different databases depending on who the user is.
This is what "tenancies" are all about.
In order to simplify this I will be adding another field to the system!sysroles table called "database". When a user authenticates if this field in not empty then the specified database will be used rather than the default one that you have specified for the App.
This provides the ability to run the exact same Apps against different databases; e.g. one for each "company" that uses your App in the Cloud.
Q:
In our case, some clients has multiple companies in their group and the accessible companies within the group of companies depends on the user ID or user Role. BTW, am I correct that one user role can have multiple user IDs?
A:
Yes roles are whatever you want them to be then you can restrict access to apps, pages, sections and form items based on them.
Q:
we have been pondering the concept of "tenancies" for some time. Instead of having different databases can you place a Company Key against all Tables and have a single database?
The advantage would be gained (for us) when we need to sweep across the database for all clients to extract a common process file.
Currently, we use a key, but our legacy APP is in the LAN world and thus segregated anyway.
So the job would be to "sweep" through the multiple tenancies to accumulate the process file?
Or reverse engineer the procedure and have the tenancies spit the data out to a common process file?
A:
You would just need to open the databases and accumulate a process file.
use cust1!tablename
...
use cust2!tablename
...
etc
The database name can prefix the table name without having to explicit open the database.
Q:
How do you fit each tenant in that equation? i.e. tenancy1\cust1!tablename ... tenancy2\cust2!tablename
A:
A user currently belongs to a tenancy (domain in the users workspace).
I will be adding a "database" column to the system!sysroles table.
This will be used prior to the activation of full tenancies so that a user who authenticates works with tables in the specified database.
When full tenancies are enabled then all folders (including the data directory) are private to that tenancy.
So if you look at the current directory structure On windows under the lianja\cloudserver\public\ that is the default tenancy.
If a user has a tenancy of xyz.com then there will be a directory structure that is the domain of that tenancy:
which will include the "data" directory which in turn includes the databases for the xyz.com tenant.lianja\cloudserver\xyz.com\
This allows multiple tenants (or companies if you want to think of it like that) to be hosted on the same server or VM instance.
The "Runtime database" in the App Settings does that already. This is different, it for hosting different companies (tenants) running the same Apps against private databases.
When you setup users in Lianja you would normally assign "roles" to them that match the roles given in the UI Presentation rules for an App, Page, Section or field.
This fine granularity of permissions controls what CRUD (Create Read Update and Delete) operations can be performed by a given user on a UI element.
"Dynamic Roles and Permissions" can now be used to control this behavior without needing to have static roles specified (which still work as before). I have attached a screenshot to give you an idea about what this does.
Users are stored in the system!sysroles table and dynamic roles and permissions are stored in the system!sysperms table so you can write your own admin App to allow users with the correct permissions to setup their own users and roles. A dynamic role given to a user is prefixed with an @ character which causes the permissions to be looked up and applied to the UI at runtime.
Q:
How do I change the default user in App Builder? (Currently, it defaults to my Lianja username).
A:
The App Builder runs as your windows login and is treated as "admin". Why would you want to login as a different user? When developing you need all permissions.
Logins are primarily used in the App Center in conjunction with roles and permissions.
Q:
How do I create user login and password?
I inserted them into the User Tab
However, I still couldn't login through the app center.
A:
You need to deploy the "system" database.
You maintain it in dev mode and deploy it for runtime/web use.
Security is always an issue in web apps as i'm sure you understand, You can get the username in a server side procedure but not in the actual running client.
All topics in [Answers] alphabetically:http://www.lianja.com/community/show...ll=1#post12352
Reply With Quote
Bookmarks