We received this email below today from a company who is considering Alpha Anywhere as their environment for building online database software to manage their clients:
We are considering using Alpha Anywhere to build an online database system that would show our charity clients the donations that we have processed for them. I can see that users can be restricted to files and folders but can they be restricted to records? We want our clients to only view the records and reports that apply to their donors and not to donors for other charities?Alpha Software's Jerry Brightbill quickly replied:
Filtering based on the user login is common in any system. Alpha Anywhere makes it easy. Here are a few articles from our older blog that can get you started.
If the limitation is to restrict a user to view only their own invoices, each invoice record would need some user identifier stored in a field for each invoice such as a customer id. If the records are limited to a single group of users, the group would need some identifier, and every record would need the identifier stored in one of the fields.
In your scenario, each client would probably be linked to one or more charities. Then individual contributions would be linked to the charity with the charity identifier. If you know the current clients charity, you can limit any list to contributions made to that charity by filtering on the charity identifier field. You can also limit access to donors, if each contribution has a donor identifier.
The older articles mention a special security value named "ulink". We no longer recommend the use of the special "ulink" field in the security system. Instead, we suggest saving the users security "userid" or "username" in a table outside of the security system that contains more detailed information about the user.
Here is how it can work:
You have some users who can see data for charities. There is data about these users in a "RegisteredUsers" table, which can contain information such as their contact information. This special table would also contain the login "Userid" and some identifier to specify the charity which may be some code or other special value. For example purposes, assume the charities have a character code and the charity "My special charity" is number "C10". You may some users as below.
|User Information||User Login UserId||Charity Code|
When John Doe logs in, we have a special function that can find their security "userid", which id "johnd". This value can then be used to find their record in the RegisteredUsers table and obtain their charity , which in "C10". Normally, most developers then store this value is what is called a session variable, which is available as long as the session exists. So you may have a session variable such as this.
session.CurrentCharity = "C10"
This value can now be used in every component as part of the filter to show only data for charity "C10". Often, a designer will save multiple values for the user, such as their user identifier, perhaps their name, address and other information that could be useful on some page or form.
There are many ways to add filters, but all rely on linking the current user to some special value that is also stored in other tables and can be used as a filter.
Additional examples can be found the the sample Application Server Demo in Alpha Anywhere. The main index page is based on a tabbedUI component named "grids" which has login capability. The server side event "onLogin" has code that sets a series of session variables for the current logged in user.
These values are used in a couple components in filters. The UX component CustomerInvoices" sets a local variable from a session variable that is then used to filter the displayed data. The grid "CurrentUserInvoices" also uses the session variable to set an argument value that is used to filter invoices.