Thanks for this great module, I love it.
There is only one thing I can't get to work and that is mapping a custom X-Property like X-MICROSOFT-CDO-BUSYSTATUS
I can map any other custom property like STATUS or PRIORITY with the hook_date_ical_import_timezone_alter() function but when I map a custom X-property like X-MICROSOFT-CDO-BUSYSTATUS:BUSY not the value BUSY is pushed in the Drupal field but the string "X-MICROSOFT-CDO-BUSYSTATUS" (see screenshot)
Here is my custom module where I successfully map STATUS but where I can't map X-MICROSOFT-CDO-BUSYSTATUS
/**
* Implements hook_date_ical_import_timezone_alter().
*/
function date_ics_mapping_date_ical_mapping_sources_alter(&$sources) {
// Add the "STATUS" ics Outlook property to the mapping sources.
$sources['STATUS'] = array(
'name' => t('Status'),
'description' => t('The status of the appointment. It is CONFIRMED .'),
'date_ical_parse_handler' => 'parseTextProperty',
);
// Add the "X-MICROSOFT-CDO-BUSYSTATUS" ics Outlook property to the mapping sources.
$sources['X-MICROSOFT-CDO-BUSYSTATUS'] = array(
'name' => t('MicroSoft Busy Status'),
'description' => t('The X-MicroSoft Busy status of the appointment. It is BUSY or TENTATIVE. Tentative is the state before accepting the anointment by the delegated'),
'date_ical_parse_handler' => 'parseTextProperty',
);
// Add the "PRIORITY" ics property to the mapping sources.
$sources['PRIORITY'] = array(
'name' => t('Priority'),
'description' => t('The Priority status'),
'date_ical_parse_handler' => 'parseTextProperty',
);
}
The X-MICROSOFT-CDO-BUSYSTATUS comes from a Exchange ics file. Here is a part of that:
BEGIN:VEVENT
SUMMARY:My test appointment 50
DTSTART;TZID=W. Europe Standard Time:20160422T070000
DTEND;TZID=W. Europe Standard Time:20160422T110000
UID:040000008200E00074C5B7101A82E0080000000020FA569E4B9AD101000000000000000
0100000007EDD6BCC2144ED4D83B8F6CDC0CFDE97
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20160419T194020Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION:Rotterdam
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
BEGIN:VEVENT
SUMMARY:My test appointment 100
DTSTART;TZID=W. Europe Standard Time:20160422T130000
DTEND;TZID=W. Europe Standard Time:20160422T150000
UID:040000008200E00074C5B7101A82E00800000000201B3A671F9AD101000000000000000
010000000A9274B22BB5DEF48922A4EA931F7B921
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20160419T194020Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION: Amsterdam
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
I can use some help here:
- So what do I do wrong?
- How can I map X-MICROSOFT-CDO-BUSYSTATUS?
Thanks for your time!
Comments
Comment #2
coredumperror commentedHmm, interesting. It's possible that the iCalcreator library treats X properties differently, which is why Date iCal isn't working as intended. I'll try out your code and look for the reason why this isn't working for you.
Comment #4
coredumperror commentedOK, I figured out what was wrong, and pushed up a fix. If you grab the latest dev release of date_ical, this problem should be gone.
If this works for you, please let me know, so I can release it in a new green release. If it doesn't work, also please let me know, so we can work together to figure out why.
Comment #5
neorg commentedHi coredumperror thanks for the fast response!
I installed the 7.x-3.8+6-dev version of date_ical unfortunately the result is still the same. The key "X-MICROSOFT-CDO-BUSYSTATUS" is still pushed to Drupal field instead of the value "BUSY" or "TENTATIVE"
How can I help to fix this?
Comment #6
coredumperror commentedHmmm, very strange. The change I made worked fine for me on the ical VEVENTs you posted. Are you sure the import actually updated the relevant nodes? You might want to temporarily enable the "Skip hash check" option in the Processor settings of your feed importer. That will force it to always update imported nodes, even if the system thinks there aren't any changes.
If that doesn't work, my first recommendation is to apply the attached "restriction" patch file to the dev release you just installed. It will make the parser less restrictive about what it considers to be an X-PROP that needs special processing. If that fixes it, I'll have to rethink whether or not date_ical even needs that restriction.
If that patch doesn't help, apply the attached "logging" patch file. Then run your importer, and wait for it to finish. After that, check out the "Recent log messages" page (/admin/reports/dblog) for printouts of all the property keys and their corresponding values that the parser found (if you don't have it enabled, the "Database logging" module must be turned on to be able to see the messages on that page. Otherwise, I think they'll only be visible in your syslog). Look for X-MICROSOFT-CDO-BUSYSTATUS in there, click the link in the "Message" column to see the full log entry, and report back here what the full Message string is.
I expect you to find watchdog messages like this:
X-MICROSOFT-CDO-BUSYSTATUS: ["X-MICROSOFT-CDO-BUSYSTATUS","TENTATIVE"]
But if your X-MICROSOFT-CDO-BUSYSTATUS values don't look like an array of two strings, that will be why it's not working.
Comment #7
coredumperror commentedAaaaand I forgot to attach the patches. </facepalm>
Comment #8
neorg commentedBoth possible solutions, "Skip hash check" and the date_ical-restriction.patch didn't work. I even deleted all nodes to be sure that the ics-file was really read and imported.
After the date_ical-logging.patch I see lots of date_ical messages in the log but not one X-MICROSOFT-CDO-BUSYSTATUS message.

Comment #9
coredumperror commentedWait a sec... that seems impossible. If there's no log message for X-MICROSOFT-CDO-BUSYSTATUS, then that attribute isn't being imported at all. Which tells me that either your
hook_date_ical_mapping_sources_alterimplementation isn't triggering, or your importer's config isn't mapping that attribute onto a field. But if that's the case, how is the field being populated with any data at all?Do you have a Feeds Tamper rule set up that could be interfering with this? Maybe the field has a default value, so a lack of imported data is setting it anyway? I'm honestly not sure what could be going on here.
Comment #10
neorg commentedSorry, sorry, sorry it works perfect..
I made some changes in the hook_date_ical_mapping_sources_alter for testing and forgot to change that back to default.
I am now successfully running the 7.x-3.8+6-dev version with the date_ical-restriction.patch. Just tried it without the date_ical-restriction.patch and that also works perfect.
Thanks for the support, sorry for wasting your time.
Comment #11
coredumperror commentedNo worries, dude, I've done that exact thing so many times I've lost count. You did discover a legit bug in the way date_ical handles certain output from iCalcreator, so this was hardly a waste of time.