Best practice for read-only functionality

Question

Hi,
I'm part of the development team of a system with about 100 screens. The customer would like us to add some read-only functionality to the system, so that certain users are able to access the screens but not change any of the data on them. We already have policies in place on the database level that keeps read-only users from saving data, but it's not very user friendly to allow users to change data on a screen, only to tell them that they're not allowed to save those changes once they try to do so. It would clearly be better if all components are rendered as read-only components for read-only users, making them unable to make any data changes in the first place.
User privileges in the system are controlled by roles defined and set in the system (not ADF roles or Weblogic roles). At any given time and place, it's possible to check whether the current user has a certain role. We already use this in a number of places to make it possible to control which user has access to which screens. In a few places we even control which functionality should be enabled for the current user within a screen, but mostly the access control is currently on the screen level. With read-only users getting access to all screens, it seems we will need lot of extra in-screen access control to keep these users from changing anything.
But what's the best practice here? One way to go would be to add some logic to every single active component on every single screen, to determine whether it should be rendered as active or disabled/read-only. But that would require a lot of extra coding.
So my question is: Is there a smarter way to do this? Maybe something done through skinning? Or something else?
(I'm not sure how relevant this is for this sort of question, but we're currently using JDev 11.1.1.4.0, and expect to upgrade to 11.1.1.6.0 within the next 6 months)
Best regards,
Andreas

Answer 1

Hi Guna, Puthanampatti and Don,
Thanks a lot for your replies. I'm currently looking into implementing something along the lines of what Guna has suggested:
Our application consists of a number of individual work spaces that are deployed as adflibs which have all been added to a "master application work space", and the master application is deployed as an .ear file. Most of the individual work spaces are for all the different functional areas of the application, with their own task flows, page fragments etc. The rest are work spaces with common functionality, like datamodel (entity definitions), utility methods, page templates, and framework extensions. In the latter, we have defined custom classes for all the base classes (somewhat similar to what Don describes, I believe).
In our custom class for ViewRowImpl, I have added an isAttributeUpdateable method, and in our custom class for ApplicationModuleImpl I have added an isReadOnlyUser method. The isAttributeUpdateable method uses the isReadOnlyUser method to determine if the current user is a read-only user or not; if the user is a read-only user the isAttributeUpdateable method will return false, otherwise true. The isReadOnlyUser method in our base class is just a dummy method that always returns true. But in the ApplicationModuleImpl classes of our individual work spaces, i've written an override for isReadOnlyUser, giving the answer that is relevant for the work space in question (for instance, whether or not the current user has the role "User Administrator").
That pretty much takes care of all input fields in tables and forms, which is a big step in the right direction. This still leaves some work to be done for components that are not directly linked to view object attributes (like buttons), but I guess that can't be helped. Also, there are a few of the work spaces that contain a number of pages that are related to different user privileges (as in: page 1 requires user privilege A, and page 2 requires user privilege B); in these cases I will have to do something different than just writing an override in the "local" ApplicationModuleImpl class.
@Don: What you describe seems to be pretty close in functionality to what we already have, though your implementation is different from ours. You have used your custom base ApplicationModuleImpl class to keep read-only users from committing changes. We use Virtual Private Database and database policies to the same end: If a user without the required full-access role tries to commit data it will cause a database error, which we then handle in the application (so the user gets a message like "You don't have the required privileges to changes this data", rather than an ORA message). Unfortunately, our customers are not content with this. They want a solution where all input fields and most of the buttons etc. are disabled for read-only users, and that's why I'm looking into the best/smartest way to do this.
@Puthanampatti: We already use something similar to what you're suggesting. The challenge I'm currently facing is how best to disable/enable components based on the current user's roles, not how to determine and store those roles.
Best regards,
Andreas