[Zope-Coders] Re: [Zope-Checkins] CVS: Zope/lib/python/ZPublisher - Converters.py:1.14.8.2

[Casey Duncan]

BTW, I have reverted the change to PropertyManager.py on the HEAD, 2.6 an=
d 2.5=20
branch because it breaks any property sheet with an integer property.

As a note for the future, running unit tests is not enough,. Please do=20
"functional" testing as well. IOW after making a change like this, see if=
 you=20
can break it through the ZMI. Some quick playing around in the ZMI would=20
easily identify this bug and save us time and hassle.

And if you really feel motivated, and can break code without the tests=20
noticing it, fix the tests.

Thanks,

-Casey

On Friday 13 September 2002 10:46 am, Chris Withers wrote:
> Shane Hathaway wrote:
> >=20
> > 1) Are you sure this was broken?  _updateProperty(), which=20
> > manage_editProperties() calls, converts the type already.
>=20
> You're right, this bit of the fix is unnecessary, I'll back it out. I m=
ight=20
even=20
> optimise _updateProperty while I'm at it, unless anyone can tell me why=
 we=20
need=20
> "type(value)=3D=3Dtype('')" rather than "isinstance(value,StringType)".
>=20
> I'll await a go-ahead and make these changes.
>=20
> The bug (which I fixed) was that ZPublisher.Converters didn't map 'mult=
iple=20
> selection' to the field-to-list convertor. That meant that if you hit t=
he=20
edit=20
> button in CMF Type Information Objects' Properties tab, you got weird a=
n=20
> wodnerful errors if implicitly addable was unchecked.
>=20
> > 2) I don't feel good about this going into the 2_5 branch.  We discus=
sed=20
> > recently that the Zope release cycle needs to change in order to sque=
eze=20
> > out the notion of "hotfixes".  Specifically, only security-related=20
> > bugfixes should go into the 2_5 branch, except when specifically=20
> > approved by Brian.  That enables us to release a micro revision of Zo=
pe=20
> > at any time instead of a sysadmin-frightening hotfix, without *any*=20
> > worries of breaking sites. =20
>=20
> Fair enough, I wasn't aware of this change in policy. Can you elaborate=
 on=20
this=20
> new policy; where should I have checked this in and what should I have =
done=20
> before merging it to the 2.5 and 2.6 branches. (This is critical fix fo=
r a=20
CMF=20
> site I'm currently working on)
>=20
> My 2p though: I need this fix, does that mean I have to take the much b=
igger=20
> gamble of going to 2.6.0 from stable 2.5.1, just to get this tiny fix?
> (The other option is to remember to keep patching Zope until I have a=20
compelling=20
> reason to move to 2.6.x :-S)
>=20
> > This change seems like it could break sites.
>=20
> Only if they relied on this obscure and broken behaviour, which I would=
 be=20
> really suprised to hear of :-S
>=20
> cheers,
>=20
> Chris
>=20
>=20
> _______________________________________________
> Zope-Coders mailing list
> Zope-Coders@zope.org
> http://lists.zope.org/mailman/listinfo/zope-coders
>=20