Bug 1032715 - Provide functionality to reset the portlet view
Summary: Provide functionality to reset the portlet view
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: Portal
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ER01
: ---
Assignee: Nobody
QA Contact: Marek Baluch
URL:
Whiteboard: 6_3
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-20 16:13 UTC by Martin Weiler
Modified: 2025-02-10 03:34 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-02-10 03:34:26 UTC
Type: Enhancement
Embargoed:


Attachments (Terms of Use)

Description Martin Weiler 2013-11-20 16:13:59 UTC
Description of problem:
As per the spec, the portal maintains the state across requests, unless explicitly reset. For portlets composed of multiple views, this means that the portlet presents the last view, when a user returns to the portlet from a different page. Resetting the state and presenting a default view instead is a commonly requested feature.

Comment 2 Lucas Ponce 2014-02-18 14:30:24 UTC
Hi Martin,

Please, can you add more details to the request ? Do you mean ... ?

a) Portlets based in PortletBridge JSF, to reset the JSF state to return to default view.

b) Pages with multiples portlets, each one with one state (i.e. EDIT mode and maximized), and reset portal page state.

c) Both cases ?

Thanks,
Lucas

Comment 3 Lucas Ponce 2014-02-18 14:48:52 UTC
Ken has pointed that JBoss Portal 6.1.1 will include PortletBridge 3.1.1 with a feature to not retain state (in other words to set the view for JSF portlets):

https://docs.jboss.org/author/display/PBR/Save+Bridge+Request+Scope+after+Render+complete

Comment 4 László van den Hoek 2014-02-18 15:23:36 UTC
(In reply to Lucas Ponce from comment #3)
> PortletBridge 3.1.1

Surely you mean PortletBridge 3.3.1? The version included with JPP 6.1.0 is 3.2.1.

Comment 5 Lucas Ponce 2014-02-18 15:26:50 UTC
PortletBridge 3.3.1

Sorry, I had a typo in my previous comment.

Comment 6 Martin Weiler 2014-02-18 15:30:32 UTC
Lucas,
the request was for scenario a), which is covered with the new PBR bridge feature. Feel free to close this bz.

Comment 8 Petr Mensik 2014-05-12 08:48:30 UTC
Yes, I can verify that this feature of PBR is really working.

Comment 10 Petr Mensik 2014-09-10 13:54:27 UTC
Based on the report from Anurag, I have to confirm that it seems PBR retains the state of JSF portlets again no matter what configuration you have.

Steps to reproduce (you can use reproducer provided by Anurag)

1. Deploy portlet
2. Add it to some page and go to there
3. Fill something into the input and submit, now you are on the step 2
4. Go to some other page
5. Go back to the page with reproducer, portlet should have reset the view into its initial state but you can still see the step 2 hanging there

Comment 11 Petr Mensik 2014-09-18 12:55:02 UTC
So I managed to test it with older versions and result is still the same. I made a reproducer from one of the example portlets in PBR, so you can check it for yourself in earlier version of JPP

https://github.com/pmensik/portletbridge/tree/BZ-1032715_reproducer

I also have added integration test into the PBR testsuite and strange thing is that it passes (I mean you leave the portlet in step two, go to some url, go back and portlet shows you the homepage), you can check it in the other branch of my fork

https://github.com/pmensik/portletbridge/tree/BZ-1032715

Just do mvn verify -P browser-phantomjs,integration-tests,jbossas-managed-7 -Dtest=RequestScopeRetainingTest

Comment 14 Ken Finnigan 2014-09-29 11:57:49 UTC
The resolution in comment #3 refers to PBR-499, which is related to state being retained between requests when it shouldn't.

This BZ relates to resetting the view id of a portlet, and is unrelated to whether state is being retained between Render requests or not.

Comment 20 Red Hat Bugzilla 2025-02-10 03:34:26 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.


Note You need to log in before you can comment on or make changes to this bug.