Posts tagged Personalization
In a recent post I wrote how wonderful the ADF support for user level customizations or personalizations is, and then I went on to explain how the user can be enabled to remove her own personalizations (http://technology.amis.nl/2012/09/27/adf-undo-the-users-page-personalizations-query-and-manipulate-mds/). This article a sequel to that story. It will introduce the capability for one user to clone the personalizations from another user. This means at the background that the document that contains the customizations for a page for the ‘source user’ is read and a new document with the exact same contents is written for the ‘target user’ who will then have personalizations that are at that time exactly the same as those of the source user. There is no link between the two documents – they are both on their own. Any pre-existing personalizations for the target user are lost in this process.
Note: I do not talk about the privileges that you want to define in order to not have anyone copying from just anyone else. Also note that I discuss cloning the personalizations for a single page only. Copying all personalizations from one user to another however is a very simple extension of what More >
One of the quite powerful features of ADF is the built in support user customizations also known as personalizations. A user can apply changes to an ADF web page – rearranging some of the layout, configuring advanced components such as tables and generally fine tuning the look and feel to the user’s individual needs. If the application is so configured, these changes are retained during the session (for each next visit to the page) or even across sessions (for each next visit to the page, also after an intermediate log out, in an entirely new session).
The framework provides declarative support for registering and reapplying the personalizations made by the user. These are held in the MDS Repository, in an XML file that contains the deltas that the user is (indirectly) requesting to have applied on top of the base sources of the application.
The framework does not have built in out of the box support for resetting the page – returning it to its factory level, the state in which the developers created it. The customization document needs to be removed from the MDS repository when the user wants to undo the personalizations made. To accomplish this, we need to write a little code More >
One of the rather cool pieces of functionality that did not make it into the JDeveloper 11g Boxer release of early October 2008 is the Meta Data Service or MDS and especially its capability to store and reapply user created personalizations of the User Interface across sessions. Some simple examples of what this means: ADF 11g Rich Client Components allow users to manipulate the state of components – such as the position of the separator in the PanelSplitter, the ordering and width of Table Columns, the initially visible tab or accordion child etc.. Through MDS, these changes are captured and stored for th duration of the session (if so desired), which means that when the user returns to a page thus ‘personalized’, the component will not assume their default state as specified in the JSF page at design time by the developer, but rather the state that user specified. Eventually MDS will persist these component personalizations across sessions – but not right now. That means that at the present when a user starts a new session, all components are presented in their default state.
In this article I will describe two things: Change Persistency for all attributes – not just the More >
The Case At the customer we use Oracle Incentive Compensation (OIC). OIC is used to compensate external partners. These partners are maintained in CRM foundation. The partners are set up as salesperson. Salespersons can be used inside OIC.
The customer has two operating units. In CRM for each operating unit, the salesperson must be set up. So if you had setup the salesperson in operating unit A, then there’s not yet a salesperson in operating unit B.
The problem in CRM foundation is that it is possible to change information of operating unit B, while you’re using a responsibility that is assigned to operating unit A. If you change information of operating unit B, using the responsibility for operating unit A, the relation in the database will be made with operating unit A. So for example you changed a role that is used in operating unit B this will be related to the salesperson of operating unit A. This causes inexplicable errors. On screen everything seems ok, but somewhere hidden in the database there is a wrong relation.