provide a property setter callback

Hi at the moment I've enabled it using the attached patch (created against 7.x-2.0-alpha3).
BTW I don't know if this could have some collateral effects, since the $property['setter callback'] was explicitly unset.

Quazardous, do you think you'll be writing a setter for datetime? If one is coming in the near future, I'll wait. If not, I'll change my field to a datestamp.

Thanks for the quick answer!

I've submitted a patch against Entity API (see #1156340: entity_property_verify_data_type validete only date in timestamp format) allows to use datetime and date ISO format.

This part of the code was provided by the maintainer of Entity API. I don't want to alter it without knowing why it was there in the first place. Plus I don't understand how unsetting a value solves the issue, you keep referring to providing a setter callback, this patch doesn't seem to do that.

Tagged #1189800: Unable to set non-datestamp field value using a rule as a duplicate of this issue.

Here's a proof of concept of how to do a custom setter callback for date. Note that this shouldn't be committed as is, and I'm focusing on the regular date field, not datestamp field.

I setup a rule with an event of viewing a node, with condition "Entity has field" with a date field on a content type, and changing the date field to a static date (I'm silly).

Going forward... We need to modify the property_info_alter and change the property type based on what type of date field, and set a custom setter callback depending on that type of date. As noted earlier in the issue, the standard "date" type for properties (from Entity API) is for timestamps and so the default setter callback can be used there. For others, property type should be changed to text or struct depending on the configuration of the field/instance.

Edit: i know the comment "e.g." is confusing with the actual code below, but again, proof of concept ;-)

#1213036: Cannot write to Date field using Rules marked as a duplicate of this issue.

subscribe

subscribe.

The rules module reaveled this problem to me.

I can also confirm that when the 'setter callback' is un-unset, the default 'setter callback' is 'entity_metadata_field_property_set' and it functions properly.

The rules module will create the appropriate input form to handle the date so that something like 'now' can be used.

When using the proof of concept, there is no proper handling of the input data (as noted) and I there cannot do anything with that patch as it stands (as noted).

I browsed the git repositories for date module and the entity module.
The following changes relating to the 'setter callback' function I mentioned above were made:
- http://drupalcode.org/project/entity.git?a=search&h=refs/heads/7.x-1.x&s...

It looks like there might have been some bug in the 'setter callback' on 2011-02-04, see: http://drupalcode.org/project/entity.git/commit/cd8dd5acb2532f9270a37003...

When I looked around that date for the date module, I noticed a 3-year gap of missing information for the date.module file:
- branch, master: http://drupalcode.org/project/date.git/history/283ad110c529b084603a3f17e...
- branch, 7.x-1.x: http://drupalcode.org/project/date.git/history/refs/heads/7.x-1.x:/date....
- branch, 7.x-2.x: http://drupalcode.org/project/date.git/history/refs/heads/7.x-2.x:/date....

So at this point I can only speculate as to what happened because of the missing history.

The commit on 2011-01-15 is unsetting the 'setter callback' function.
(see: http://drupalcode.org/project/date.git/commit/8dbf321a2f4a6cdc17bd4ccd09...)

The commit immediately before it on 2007-08-31 is doing no such unset.
(see: http://drupalcode.org/project/date.git/commit/9c03d322249c1b7d3768f60de4...)

Neither of these commits performed the change so it must have been done in between that time.

What I do know is that the unsetting of the 'setter callback' variable existed before the bugfix for the 'setter callback' in the entity module.
This makes me want to believe that the 'setter callback' function variable was being unset because the entity 'setter callback' function may have been broken in the entity module around that time. If that is in fact the case, then it should be safe to un-unset the 'setter callback' variable.

Based on the comments above, the 'datestamp' format may not be working and may needs its own 'setter callback'.
Perhaps the 'setter callback' variable should only be unset for the 'datestamp' type?

The missing history is because I had to re-organize the file structure so that the D7 automatic update would work (it didn't like my folder structure). Other than that I have not touched this code. It was contributed by fago and I never did anything but commit what he provided. I don't use this so cannot tell what needs to be changed.

subscribe

This feature would be very good to get solved so for example Rules could set a date value to a entity.

I am using a datestamp field and the patch in #6 works for me.

The patch in #6 (enabling the default property setter) will not work with date fields that have an end date ("value2") set. Not even with datestamp as field type.

The result is a transaction exception. Looking deeper it reveals a "field count does not match value count" sql exception. Caused by "value2" is listed in the field list, but not the value list.

So the true solution would be implementing proper setter methods, as started by mradcliffe in #15.

I ran into this by trying to clone a field_collection that contains date (range) fields: #1233256: Integrate node_clone with field_collection module

subscribe

subscribing

subscribe

I'm coming here now from #1103032: Document how to use date tokens. Entity token support won't work if the property does not end up as 'date', so generally it looks like all types of dates need to get transformed into timestamps and set with the 'date' property. Some of the people on this issue are trying to get things working in Rules. I have no idea how Rules would be affected if we transform all dates into timestamps.

But getting tokens working is a release blocker, so any solution here has to ensure that entity tokens will work for all types of dates.

This whole part of the code is a complete mystery to me. If this has to wait for me to have time to totally understand how this works, a Date release is a long ways off. I'm hoping there are people who *do* understand it who can push this along.

So I'm marking this as a critical task and a release blocker.

And for those who are just adding 'subscribe', you can now use the 'Follow' link at the top of the issue to avoid sending emails to everyone following this issue.

Also per my comment above, the tokens that don't work seem also to be dates that have end dates, so the handling of end dates is obviously a key issue.

For documentation, since the history was lost when I re-organized the files, this part of the code was created by fago, in two patches: #869606: integrate with the entity metadata module and #966590: fix and improve the metadata integration . You can see that he is the one that submitted the code that deliberately unset the setter callback. I have no idea why.

Digging into this more, I'm not sure the token problem will be fixed by this. Tokens are completely broken for dates that have end dates, but that may or may not affect what is happening when you try to use rules, and adding a 'setter' doesn't sound like it will fix tokens.

yes, this won't help token support.

I think the setter callback is not removed if you have a date field with UTC storage - as in this case no conversion is needed. Otherwise, we need to add setter callbacks that fix-up the time-zones, i.e. convert the incoming UTC value in whatever the date-field needs.

However, Date (ISO format) with UTC also doesn't support writing.

right, everything that needs conversion doesn't support it yet. So right now it only works with Datestamps I think.

Right now the only thing that works are datestamps with no end dates, everything else is broken. Nothing with a 'struct' type works.

I committed some code that I hope will work properly. It worked for me but no idea how it will work for others. And we should add tests too, but I don't have time to do that. Any takers?

To clarify, the patches in this issue are not what was committed, you need to get the latest code from git (as of a couple minutes ago).

Also should note I am using the Entity patch at http://drupal.org/node/1058856#comment-5281650. I don't think it affects the setter, but just in case... That patch, or some variation of it, should make it into the dev release of Entity soon.

I'm going to mark this fixed. If someone sees a problem they can reopen.

Many thanks, Karen.
Please commit Your patches, #34 into dev at least, as no everybody use git.

All changes go into git, that's the way the system works. The packaging system picks them up twice a day and updates the dev tarball.

I just gave it a short test and noticed that the timezone is converted twice if an end-date is used.

This is, as both the field-leveler setter as well as the struct-level setter did the conversion. So I had a short look at it and fixed it by making use of the existing verbatim setter for this case. Also, 0 is valid unix timestamp so we may not use empty() to check or NULL values - attached patch fixes that too.

Attached patch needs a cache-clear to work. I've tested setting a date field without end-date (no struct) as well as one with end-date (has struct). This certainly could need some test cases though.

I went ahead and committed this. You certainly understand this code better than I do so I'm happy to assume it's right. Thanks!

The patch makes sense to me too. Thank you.

"Set a data value" on a date field using Rules still doesn't work. No error messages any more, but the field isn't updated. I'm using the latest dev of Date, Rules and Entity API. Setting back to 'needs work' for now... if this bug report belongs in the Rules queue I apologise!

Ad #42:
Please create a separate issue with more details on your set up and make sure you've cleared caches. Feel free to post it to the Rules queue first.

There seems to be a problem with datetime fields witz th_handling = 'date' which have 3 columns: value, timezone, offset. I'm wondering if the property type should be a struct in that case?

While value and timezone gets saved, offset does not. Also I'm not sure how the process decides which timezone to use as the setter actually gets only a timestamp as argument.

See #1853322: entity_metadata_wrapper doesn't set offset column