Okay.. there are two issues to consider here.
1. Security - making sure that users cannot use the tables/records/fields that you don't want them to.
2. Usability - making the applications flow work properly for the user at hand.
On the security side of things, it is easy to "jail" a user. Simply define the getPermissions() methods on the three tables in such a way that the appropriate permissions are returned for each user. In your example above you would define the getPermissions() method for the A table as:
- Code: Select all
function getPermissions(&$record){
$auth =& Dataface_AuthenticationTool::getInstance();
$user =& $auth->getLoggedInUser();
// $user is a Dataface_Record encapsulating the currently logged in user.
// first let's deal with the case that the user is not logged in.
if ( !$user ) return Dataface_PermissionsTool::NO_ACCESS();
if ( $user->val('userid') == 3 ) return Dataface_PermissionsTool::ALL();
// If i understand the specs correctly, then user 3 is the only one that can access table 'A' at all
// so we revoke access to everyone else.
return Dataface_PermissionsTool::NO_ACCESS();
}
You would do similar things for the other tables to make sure that only authorized users can access them.
On the usability side, there are a number of things that you can do to tailor the application to your needs here.
The permissions will help a lot, but you may end up with a situation where users see "Permission denied" alot. This is where you have to tell your application to be "smart".
This is a fairly big topic that deserves a lot of space and discussion, but I'll begin by listing some of the more common hurdles:
1. The table tabs at the top of the app show up the same for each user - what if you want some tables to be hidden for some users.
2. If no table is specified in the URL, then the user is always directed to the first table in the tables menu. What if you want this to depend on which user is logged in?
3. The default action is 'list'. What if you want this to be different?
4. Some parts of the application may be confusing to some users, and are better hidden (e.g. how to hide the search box).
There may be more issues but their solutions will be similar.
Solutions:
1. The table tabs, for performance reasons, are just statically generated.. they don't take into account any permissions. Of course if a user clicks on a table that he has no access to he'll receive a permission-denied error. So how do we get around this.
a. You could remove these tabs altogether. You can do this by defining a getPreferences() method in the Application's delegate class. This will return an associative array of preferences. see
http://framework.weblite.ca/documentation/manual/delegate_classes for more on this.
b. You could override this slot with your own tabs using the 'table_tabs' slot in the Application's delegate class.
e.g:
- Code: Select all
function block__table_tabs(){
$auth =& Dataface_AuthenticationTool::getInstance();
$user =& $auth->getLoggedInUser();
// ... now display table tabs depending on who is logged in.
}
.. more later.. i'm out of time for now....
Please let me know if there are particular aspects that you are more interested in so that I can target the response..
best regards
Steve