We want to reset the Effective Date of some Dexterity Types, which are derived from NewsItems, as we often use the Effective Date as sort criterum.
We used to have python scipts for that, which worked fine in our PLONE 4 Instanzes but don't work in our PLONE 5 sites.
In one case it looks like this and should set the Eff.Date to the Creation Date:
dateorg=context.ZopeTime()
dateString = dateorg.strftime('%Y/%m/%d %T')
date = context.CreationDate()
oldeff = context.EffectiveDate()
context.setEffectiveDate(date)
neweff = context.EffectiveDate()
context.reindexObject()
return "Date now %s. Creat = %s . New Eff = %s . Old Eff = %s ." % (dateString,date,neweff,oldeff )
The output of the script shows the old and the new Eff.Date as expected, but when I edit the context object in PLONE it still shows the old Eff.Date. That means, even if context.EffectiveDate() gives the new Date after having it changed, it does not store that in the object itself.
Under PLONE 4 it works as expected.
PLONE 5 Docus tell me that setEffectiveDate(date) still should work as before.
Any hints, were that problem is? Did I miss something?
When I replace
context.setEffectiveDate(date)
by
context.effective_date = DateTime(date)
it is still the same problem. The script runs without throwing an exception and gives me the right return values as expected, but editing the context DT Object in PLONE shows still the old Effective Date.
Ah, interestering. I created an import script to import/sync content out of another system using xml and remember having issues with 'presetting' dates as well, but I had more issues with setting the creation date (to set the date in Plone to the the item was created in the external system).
@PeterB Do you also reindex the object after modifiying the effective date? Because you might see the old effective date coming from the catalog metadata. [edit: I now see the full reindexobject call in the initial code, but am not sure if you did this also after setting .effective directly, just checking]
Another caveat, specify a time zone, otherwise you can see weird 1 hour differences with Zope's older DateTime that is required.
# some BA's don't have initial date set
if new_ba['initial_date']:
# Add timezone hardcoded, otherwise we get a 1 hour offset if we
# create from date without time
creation_date = DateTime.DateTime(
str(new_ba['initial_date']) + " GMT+1"
)
new_obj.creation_date = creation_date
new_obj.modification_date = creation_date
new_obj.reindexObject(idxs=['modified', 'created'])
@PeterB How are you executing that script? Another guess have you tried doing a transaction?
import transaction
transaction.commit()
@fredvd related to the timezone I also encountered a problem with DST. I.e: for my timezone some dates are GMT+1 and some are GMT+2
So what I do it is create a DateTime from datetime instance:
Related to the name of the field. Correct me if I am wrong guys @erral@jensens, but I have understood that behaviors are adapters and that they factories can store the value anywhere (Anotations, attributes, ...). So the name of the field in the behavior definition may be diferent from the real one. I learnt this when in some script I wanted to call the plone api to create content passing as argument the effective_date. The same applies to behavior field subjects which is stored in subject.
So in this case field name appears is effective_date and the adapter factory it is defining a DCFieldProperty specifying the real field name