Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Won't Fix
-
Affects Version/s: EE-1.8.2.GA_P03
-
Fix Version/s: EE-1.8.2.GA_P04
-
Component/s: None
-
Labels:None
-
Environment:-
-
Assignee Priority:P2
-
Workaround Exists:Yes
-
Workaround Description:The attached test case shows how to use component bindings in order to resolve the issue when using the 1.8.2 EE P03 jars.
Description
It's observed that if we have a programmatically-selected row in a data table then a subsequent click on any other row of the table doesn't deselect the programmatically selected row (this happens in both the modes - single-select and multi-select).
Note: This issue is specific to EE jars. For the community jars this problem is observed only in single-select mode and seems to be fixed for multi-select mode (also have a look at this related link - http://www.icefaces.org/JForum/posts/list/12123.page)
Attached with this case is a sample that exhibits the issue.
Scenario 1:
1. Select a row by clicking on it.
2. Click "Move Up" button to move the select row one level up.
3. Now click on another row
4. Observation - The clicked row gets selected but the row which was moved also remains selected.
Scenario 2:
1. Click "Add" button to move add a new row that's pre-selected / programmatically selected.
2. Now select another row
3. Observation - The clicked row gets selected but the row which was added also remains selected.
Note: This issue is specific to EE jars. For the community jars this problem is observed only in single-select mode and seems to be fixed for multi-select mode (also have a look at this related link - http://www.icefaces.org/JForum/posts/list/12123.page)
Attached with this case is a sample that exhibits the issue.
Scenario 1:
1. Select a row by clicking on it.
2. Click "Move Up" button to move the select row one level up.
3. Now click on another row
4. Observation - The clicked row gets selected but the row which was moved also remains selected.
Scenario 2:
1. Click "Add" button to move add a new row that's pre-selected / programmatically selected.
2. Now select another row
3. Observation - The clicked row gets selected but the row which was added also remains selected.
Activity
Tyler Johnson
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Tyler Johnson
made changes -
Status | Reopened [ 4 ] | Resolved [ 5 ] |
Resolution | Won't Fix [ 2 ] |
Tyler Johnson
made changes -
Resolution | Fixed [ 1 ] | |
Status | Resolved [ 5 ] | Reopened [ 4 ] |
Ken Fyten
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Adnan Durrani
made changes -
Assignee | Adnan Durrani [ adnan.durrani ] | Tyler Johnson [ tyler.johnson ] |
Adnan Durrani
made changes -
Attachment | TableBean1.java [ 13916 ] |
Ken Fyten
made changes -
Fix Version/s | EE-1.8.2.GA_P04 [ 10280 ] | |
Assignee Priority | P2 | |
Assignee | Adnan Durrani [ adnan.durrani ] |
Tyler Johnson
made changes -
Salesforce Case | [5007000000JNSrr] |
Tyler Johnson
made changes -
Field | Original Value | New Value |
---|---|---|
Attachment | sf-10715.war [ 13832 ] |
Tyler Johnson
created issue -
Ticket's Resolution (= Fixed) is bit misleading! It appears that (also as per Salesforce Ticket 10715 comment) the issue is not fixed in Product, but users/clients are advised to use workaround to get around this issue. In ICEfaces JIRA, I have seen such tickets typically marked as Won't Fix (with Workaround Exists: Yes). May be this can be extended here too. (Just a suggestion).