Hi,

I upgraded to 1.2.3 and now have a strange problem with the CB User Manager. If I (1) search for a user by name, then (2) edit the user and (3) cancel out of the user page, then the resulting CB User Manager page has three extra controls:

1. An extra label "OK for Webmaster to send email:"
2. An extra pull-down list with the appropriate selections for the field in (1)
3. An extra search button.

These fields are functional. If you select a value in the pull-down list and click the search button, the search works.

This looks like a partial display/implementation of the advanced search.

This does not happen if you use "Save" to exit the user page, rather than "Cancel".

I have posted a screenshot at

spillthebeans.org/cbusermgmt123.jpg

The "OK for Webmaster to send mail" is a user-defined check box. The problem does not occur if I unpublish this field. There is a screenshot of the field definition here:

www.spillthebeans.org/cb_mailoptin.jpg

I am using:

PHP 5.2.11
CB 1.2.3
Joomla 1.5.20
No ACL modification
No SEF
No chages to configuration.php
Upgrade from CB 1.2.2
Migrated from Joomla 1.5.13
Internet Explorer 8
Firefox 3.6.8

Thanks for any help you can offer.

Post edited by: hrweb, at: 2010/08/14 23:41

Post edited by: hrweb, at: 2010/08/14 23:51

Post edited by: hrweb, at: 2010/08/15 00:16

Post edited by: krileon, at: 2010/08/16 19:27

Hi,

One more piece of information. I saved the page source for the user manager page when it was working properly and when it was failing. The relevant difference is the addition of |selected="selected"| for the option value="1" tag of the cb_mailoptin control.

cb_mailoptin is the only checkbox control on the profile form, which may explain why it is the only field that causes a problem.

I then added another checkbox to the profile. That one behaved the same way as cb_mailoptin (note that the user you look up must have a selection for the checkbox. If it has not been selected, nothing goes wrong.) This seems to confirm that there is a bug with the search facility for the checkbox control.

Here is the full html for the tag in the two cases:

Bad

---

<select name="cb_mailoptin" id="cb_mailoptin" size="1" class="inputbox" title="OK for Webmaster to send email: <p>If this box is checked, the Webmaster may, from time to time, send you emails concerning class events. If you prefer not to received this mail, un check the box.</p>">\par
\tab <option value="">No preference</option>\par
\tab <option value="1" selected="selected">Yes</option>\par
\par
\tab <option value="0">No</option>\par
</select>\par


Good

---

<select name="cb_mailoptin" id="cb_mailoptin" size="1" class="inputbox" title="OK for Webmaster to send email: <p>If this box is checked, the Webmaster may, from time to time, send you emails concerning class events. If you prefer not to received this mail, un check the box.</p>">\par
\tab <option value="">No preference</option>\par
\tab <option value="1">Yes</option>\par
\par
\tab <option value="0">No</option>\par
</select>\par

Post edited by: hrweb, at: 2010/08/16 17:34

Post edited by: hrweb, at: 2010/08/16 17:54

No, the only filter that I applied was to put a last name in the default filter box. I had not activated the advanced filtration. Thanks for adding it as a bug. I'm going to see if I can find it. If so, I'll post the code.

OK. The problem is that the code in cb.core.php near line 954, which reads:

$value = stripslashes( cbGetParam( $postdata, $col ) );

assumes that $postdata contains data from the User Manager page. When you cancel out of the Edit User page, $postdata contains the data for the user. This causes the erroneous setting of the checkbox field.

There is a comment that "no searchmode for checkboxes" and some code that has been commented out that suppressed the search on checkboxes.

It's not a long-term fix, but reactivating that code fixed the immediate problem for me.

A better solution is to check for a field that doesn't appear in the valid postdata and suppress the setting of the if the field appears:

if(isset($postdata)){
return $query;
}
I placed this immediately before:

foreach ( $field->getTableColumns() as $col ) {

This seems to cure the problem, even if it isn't real elegant.

Post edited by: hrweb, at: 2010/08/16 21:08

Post edited by: hrweb, at: 2010/08/16 21:47