search

4teamwork / ftw.builder

Builder pattern for creating Plone objects in tests
3 stars 0 forks source link

Fix DX effective date test for Plone 4.3.4. #33

Closed lukasgraf closed 9 years ago

lukasgraf commented 9 years ago

This fixes the current test failure for Plone 4.3.4.1.

obj.effective now seems to be not callable any more (again), and is a datetime.datetime instead of DateTime. Didn't look into it any further, but this fixes the test for the current Plone version.

@jone @phgross

jone commented 9 years ago

@lukasgraf any idea why that changed? I've also seen the same behavior for Plone 5 and thought this was a regular change, which is ok in a major release. Seeing it in a bugfix release confuses me :confused: any idea?

In my PR #32 I'm using EffectiveDate() instead, which should work for all Plone version and returns the date as a string (e.g. 2013-01-01T00:00:00+01:00), but I'm ok with doing it like this since it is in tests only and does not affect other packages.

jone commented 9 years ago

I have the suspicion that effective used to be a method but is now set to the effective field value since the default values now are set onto the object (IContextAwareDefaultFactory fix in plone.dexterity).

@lukasgraf I think that, in older Plone versions, when the effective date is changed, the effective changes from being a method to being a datetime object, because it is set as attribute on the object. Can you confirm or refute this?

jone commented 9 years ago

Btw did you mean Plone 4.3.4 instead of 4.3.4.1? I cant find any KGS or release..

lukasgraf commented 9 years ago

@jone I mistakenly was referring to the version of Products.CMFPlone instead of the KGS version.

What you describe sounds plausible, but I currently can't really confirm it. Since it obviously works and fixes the issues for all Plone versions, I would tend to use EffectiveDate() and therefore merge #32 (didn't realize you had already addressed that issue there).

lukasgraf commented 9 years ago

Fixed via #32.