How do we restrict a user from editing a display profile,
If a user is making modification to the desktop and logs off, when he logs back i dont want his old state, but i want the state which he could for the first time when he logged.
please provide pointers for doing the same
This is an interesting requirement that goes against the common portal functionality. I would like to know the reason that you require this functionality, because you may be persuing the solution in a roundabout manner.
The desktop modifications are written to the user's profile in real time. That is, each time a user modifies the content or layout of the desktop, the changes are written to the user's display profile. This profile information is loaded each time the user logs into the portal.
If the desktop of the user should revert to the desktop as defined at the role or organization level, then you can probably just delete the user's profile each time they log in. This would require a custom authentication module, but I think it's possible. Essentially, you would be erasing all of the user customizations that were made during the previous session.
- Jim
We need this because of a specific requirement.
whats happening is , we are launching a portlet in a maximised state from the homepage and if the user logs out form here and if he returns back, we see him in the same state he has returned, instea of he returning back to homepage. if you can help us configure this , it would be great.
I would suggest investigating using the Pre/Post processing classes that can be configured to invoke a custom class, post authentication, but prior to loading the desktop. It's a bit easier than developing a whole new authentication class.
You could also explicitly configure the display profile to not allow portlets/channels to be minimised, closed or moved.
In my opinion, for what you are trying to achieve, it will probably be best to do a bit of hand-coding of your display profile XML's. You can define restrictions for channels in the DP XML file. You will need to have a basic understanding of the Displayprofile XML structure where:
- Channels (Portlets) are grouped together in a container
- More than one container can exist in the display profile
- Restricitions such as isMovable, isMinimizable, hasBorder etc are grouped as a collection inside a container.
Have a look at the following snippet:
<--
<Container name="JSPEnglishTableContainer" provider="JSPTableContainerProvider">
<Properties>
<String name="title" value="English"/>
<String name="contentPage" value="tabtable.jsp"/>
<String name="description" value="English DeskTop"/>
<Collection name="channelsColumn">
<String name="Login" value="1"/>
<String name="AfNewsAnon" value="1"/>
</Collection>
<Collection name="channelIsEditable">
<Boolean name="Login" value="false"/>
<Boolean name="AfNewsAnon" value="false"/>
</Collection>
<Collection name="channelsIsMinimizable">
<Boolean name="Login" value="false"/>
<Boolean name="AfNewsAnon" value="false"/>
</Collection>
<Collection name="channelsIsDetached">
<Boolean name="AfPubAnon" value="true"/>
</Collection>
</Container>
You will have to refer to the DTD for all the available options, but this will allow you to restrict channel/portlet options on the desktop quite extensively. From here you can develop multiple display profile documents, i.e. a DP for guests/anonymous and a DP for registered users.
There are some merge semantics you will have to take into consideration but they are well documented in the developers guide.
Hope this helps.
-Chris
hi,
are you saying that you want the user to 1) be able to make changes, but those changes get reset when they logoff, or 2) you don't want them to be able to make changes at all?
if it's #2, take a look at the developer authless desktop for an example. it does just this. when you access the desktop as authless (aka anonymous), you are just logging in implicitly as a user named "authless". however, the authless user's DP is locked down such that they cannot edit anything on their desktop. the desktop does not give them the option.
for example, the authless user's DP overrides the isEditable properly is all of the channels to be false. the authless desktop type's JSPs remove the "content / layout" links. etc.
let me know if you need more details.
if you are looking at #1, that's not really supported. there are ways to make it happen, but they are quite convuluted and probably not something you'd want to pursue. it would also be sort of strange from a usability perspective ... confusing to the user.
Thanks every one,
But the requirement is little different,
Lets say we have a user(guest), logged in and he does edit his portlet, now is maximised that and logs of.
Now when i give the same guest user to others , i dont want the old state(one portlet maximised), i want the state which i showed for the first time logged user.
For this as said by Jim and Chris, either i have to delete the DP every time the user logs in or i will have to put some code in pre/post process to get the portlets to normal state at the time of logout.
Please share your thoughts on the same.
Can you use the "edit" mode of the portlet window instead of "maximized"? The advantage is that the portal dedicates a full screen that allows editing of the portlet, but it does not permanently store the portlet state as maximized.
I don't think that logout processing is a good approach because you can't rely on users clicking the logout link.
- Jim
Thanks Jim,
I was thinking of the option of clearing the DP when the user logs in by using the pre process,
Before i could go with this option can you tell me when will the DP get loaded and is it a good option to have a code in the pre-process of the loginAction and one more thing is i have the DP out in LDAP.
Please share your thoughts on this.
As a general rule, I cannot recommed modifying the user's DP in the pre-process action. First of all, I have not done this myself and I don't know for sure that it will work. Even if it does work, there is a real potential for scalability issues since every user login will result in a write operation to the LDAP. LDAP does not perform well for large numbers of write operations. During peak usage, this could become an issue under significant load.
Can you please describe why you would prefer this solution over using the "Edit" mode function of the portlet?
Thx,
Jim
Hi,
Is it possible to change the DesktopProfile priority for the guest user and lock the portlet window status on the global desktop?
If you change the priority to 0 and put a priority of 10 to the top level deskop and force the window state at the top level, at the logon the display profile will always be the same.
Jim,
To give you more inputs on the what i require, I have users who are new to this portal environment, they can be endusers or guests,
if they login to my system and do some operations(maximise the portlets) and then logout,
Issue comes when they logout at maximised state, DP has the state persisted and when i login back i have the same state, they want the old state back, when they login.
please advice the best way
You still have not explained why using the edit mode is not a viable option for you. The more I think about this problem, the more I think that the edit mode is an appropriate solution for this problem. If you have a reason for not considering this, I would like to know why.
Have you thought about concurrency issues on this as well? For instance:
a. Guest User #1 logs in and channel is in normal display mode
b. Guest User #2 logs in and channel is in normal display mode
c. Guest User #2 maximizes channel
d. Guest User #1 refreshes page and notices that channel has been maximized.
I am sure this is undesirable behavior. Even if you were to reset the guest user display profile during login, you would still have concurrency issues while multiple guests are logged in. Apply this same logic to other information that is stored with the user's display profile and see if there are other problems that may arise.
Another option might be to add another tab to the desktop that has only this one channel in a permanent maximized state. Then, change the maximize logic to simply switch tabs to the one with the maximized version of the channel. The current tab selection is not stored in the LDAP and therefore would not cause concurrency issues with other guest users. You could even use a nested tab model to implement this. Create a nested tab and modify the HTML so that the tabs are not displayed. Then, the user is never aware that the UI is really switching tabs from Nested Tab A (normal) to Nested Tab B (Maximized).
- Jim
Jim,
I am not considering OPtion 1, of having edit because, i will have to give the same option of no-customisation to registered users also,
Option 2 seems to be a good one, but can you put some more info about the approach we can have to achieve that.
thanks
Sampath
