Description of problem: When trying to edit targets in the ACI editor pane -> Targets tab and sorting the target attribute table by Name, cannot check the checkbox at first and whats more, the name field changes to an attribute name which is IMHO the attribute in that exact position on the unsorted list. So when I try to check the attribute in the sorted list, I select the wrong attribute, because the sorting seems to be just visually done. How reproducible: Always Steps to Reproduce: 1. Go to Directory Console 2. Select Directory Server Console 3. Select Directory Tab 4. Select an entry 5. Hit Ctrl + L 6. Select any ACI or create new 7. On the "Edit ACI for..." pane select Targets tab 8. Sort table by name 9. Try to check some attribute, and the discrepancy should show himself. Actual results: Selecting an unwanted attribute for ACI target inclusion. Expected results: Selecting the visually shown attribute for ACI target inclusion. Additional info: Running on Sun Java 1.5.0.16
I also encountered this problem with Fedora DS 1.0.2 . You can work around it by following these steps for each attribute you want to select or deselect. 1. Click the column name you want to sort on. 2. Find and click ONCE in the check box of the attribute you want to modify. 3. Repeat until you are finished. To check that no other attributes were changed, you can clcik the checkbox icon in the column names to sort by selection.
Created attachment 327150 [details] diffs
Created attachment 327179 [details] cvs commit log Reviewed by: nkinder (Thanks!) Fix Description: The main problem was that the Table Model code was not checking the type of the model change event, and was just unconditionally resetting/initializing the internal indexes array every time the checkbox was checked. This caused the table to revert back to the original order every time a checkbox was checked on or off. The only events which should cause the indexes to be reset/initialized are the INSERT and DELETE types, not the UPDATE type. There were also some problems with setting up the initial model, and I cleaned up some bogus code. Platforms tested: RHEL5 Flag Day: no Doc impact: no
Checking and unchecking target attributes after a sort by name, seems to behave properly however, I am not certain of what the "discrepancy" in the description was. I'de like to verify that exactly what was happening is no longer happening. Thanks
I have same question as Jenny does. My guess is that the unchecked column will become checked after sorting. And I can verify this mis-behave is not happening. I will verify with Nathan.
just check with Nathan, my guess is close but not exact. When we click the table title to request a "sort" action, not just the column of check boxes should be shift correspondingly, but the backend data (called model) need to change as well. my test result above is part ot verification, but i need one more test test is below: 1. setup 2 acis for a certain user. make sure use console and make the target column sorted back and force couple times such as: FTPDownloadBandwith ARecord 2. save the above change 3. make ldapsearch against this user. verify the aci includes correct selected aci test result: pass [root@mv32a-vm ~]# /usr/lib/mozldap/ldapsearch -D "CN=directory manager" -w redhat123 -s sub -b "ou=accounting,dc=example,dc=com" "uid=*Bt*" "aci" version: 1 dn: uid=BTahamont34, ou=Accounting, dc=example,dc=com aci: (targetattr != "FTPDownloadBandwidth || ARecord") (version 3.0;acl "newac i";allow (all)(userdn = "ldap:///anyone");) [root@mv32a-vm ~]# ====================================================== check attached screen as well
Created attachment 338413 [details] UI to prove aci editing is correct now
bug closed now
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html