3

FullCalendar (FC) documentation states

Non-standard Fields In addition to the fields above, you may also include your own non-standard fields in each Event Object. FullCalendar will not modify or delete these fields. For example, developers often include a description field for use in callbacks such as eventRender. [Source: Event Object]

and for Google Calendar event sources

Advanced: Extended Properties Google Calendar’s API allows you to specify Extended Properties for your events. The extended properties will be available as the extendedProperties hash that is attached to each Event Object. [Source: events from Google Calendar]

However what isn't so clear is which GCal eventSource properties are classified as standard and which are non-standard.

‍‍‍‍‍‍ ‍‍

Assuming that the properties listed on the first Event Object Doc are also applicable as standard properties for GCal eventSources means anything else is likely to be a Non-standard Field, right?

If I want to query creator fields for given FC events e.g. creator.displayName or creator.email as per Google API ref doc for events#extendedProperties which appears at the bottom of the event popup i.e. "Created by: ... " (in Google calendar that is, not FC), but I am not sure how to accomplish this. ‍‍‍‍‍‍ ‍‍

I cannot find a complete list of Standard & Non-Standard Fields for FullCalendar (v3) GCal eventSources anywhere, never mind Docs/examples on how to access these properties.

‍‍‍‍‍‍ ‍‍

Anyhow attempted the following:

console.log(event.extendedProperties.creator.displayName);
console.log(event.extendedProperties.creator.email);

just produced

jquery-3.3.1.min.js:2 jQuery.Deferred exception: Cannot read property 'displayName' of undefined TypeError: Cannot read property 'displayName' of undefined

‍‍‍‍‍‍ ‍‍

And sure enough event.extendedProperties.creator did produce undefined. However next I tried:

console.log(event.extendedProperties);
console.dir(event.extendedProperties);

Which did not produce an error, but instead what appears to be an empty object

Screen shot of console.dir(event.extendedProperties)

So if it came back with nothing (i.e. empty object) it's fair to assume that there are no extendedProperties for the given events I'm querying and it also reasonable to assume that perhaps the creator fields: creator.displayName and creator.email aren't Non-standard Fields after all or at least not of the Extended Properties type.

Wait a minute, does this imply that there could be two types on Non-Standard Field lists we are dealing with or have I been staring at this screen for way too long?

‍‍‍‍‍‍ ‍‍

Finally I attempted to double check to make sure they are not part of the event object already.

console.log(event.creator.displayName);
console.log(event.creator.email);

but again this resulted in

Uncaught TypeError: Cannot read property 'displayName' of undefined

‍‍‍‍‍‍ ‍‍


I am at a complete loss. How am I supposed to obtain fields that aren't mentioned anywhere on the FullCalendar website nor appear to be an Extended Properties?

Have I overlooked anything or is there perhaps a list in existence of Standard/Non-standard Fields that I've somehow managed to miss?


Any ideas on how to obtain these creator fields would be much appreciated.

‍‍‍‍‍‍ ‍‍

‍‍‍‍‍‍ ‍‍

I don't see how any sort of code sample would be helpful here, but as I was told recently "Code is pretty much always required on Stack Overflow" so for compliance sake here's me code sample ...

<div id='calendar'></div>
<script>
$(function() {
  $('#calendar').fullCalendar({
    googleCalendarApiKey: '%googleCalendarApiKey%',
    events: {
      googleCalendarId: 'lph029pf163sce67stdgfcdpfg@group.calendar.google.com' //imdb UK
    },
    defaultView: 'month',
    eventRender: function(event, element) {
      element.popover({
        animation:true,
        delay: 300,
        title: event.title,
        content: event.description, // + req << creator.displayName/email >>  e.g."Created by: imdbreleases@gmail.com"
        placement: 'auto',
        trigger: 'hover'
      });
    }
  });
});
</script>

PS Didn't create CodePen as advised not to share GoogleAPIKey

ADyson
  • 57,178
  • 14
  • 51
  • 63
Michael B
  • 107
  • 1
  • 12
  • 1
    The only things which _fullCalendar_ considers as "standard" fields are the ones explicitly listed in the Event Object documentation. That's regardless of what the source of the events is – ADyson Mar 18 '19 at 21:08
  • What you perhaps haven't considered here is that almost none of the field names in the data that Google's API returns will match the ones that fullCalendar recognises (as per the Event Object documentation). So the little gcal.js plugin which makes this integration work has to process that Google data, translate the necessary field names and output a new event object for fullCalendar to use. Whether or not it also copies other fields from google at the same time, you can perhaps check by looking at the final event objects being held in fullCalendar – ADyson Mar 18 '19 at 21:14
  • 1
    E.g. you could use the "clientEvents" method in fullCalendar as a test to output all the events which were copied from the Google API data and see what, if any, custom fields were included. If it doesn't include data you need then you'd have to either alter the gcal.js script or write your own integration code instead in order to make it include that data from Google in the object it passes to fullCalendar. – ADyson Mar 18 '19 at 21:16
  • But as to it being documented about which exact fields are carried across, you're right, I don't think it's documented to that level, hence why you'll have to test it yourself and/or read the source code – ADyson Mar 18 '19 at 21:31
  • P.S. In your quotes above you said "The extended properties will be available as the extendedProperties hash that is attached to each Event Object"...that's actually a misquote. The page says "the extendedProps hash" ...not "extendedProperties". So in your code above, I'd guess (without being able to test) that `console.log(event.extendedProperties);` probably ought to be `console.log(event.extendedProps);` . It's gotta be worth a try. – ADyson Mar 18 '19 at 21:42
  • Thanks for the response ADyson and I've taken a look at each of your points. "_The only things which fullCalendar considers as "standard" fields are the ones explicitly listed in the Event Object documentation._" ... that I can believe, apart from the **event.description** which may well be listed as a standard fields since it's use is widespread. Odd how it didn't make the cut. – Michael B Mar 19 '19 at 00:50
  • I kinda figured that some kind of field mapping is taking place behind the scenes and that matching GCal fields would have a corresponding field in FC, but equally I figured that all Non-standard Fields would simply retain their original GCal name. Either way this **field mapping really needs to be documented** and taking a quick peak at the gcal.js script for v3.10.0 I can't see anything else being named. admittedly my JS is not exceedingly good enough to understand the inner workings of this by simply skimming it. Still nothing obvious enough for me to pick up on. – Michael B Mar 19 '19 at 00:51
  • As for the **Extended Properties** misquote. You're right in that it's called **extendedProps in v4**, however it's was originally called **extendedProperties in v3** to match the GCal name. The name changed for v4 after it was tweaked. – Michael B Mar 19 '19 at 00:51
  • FullCalendar **clientEvents** method is an interesting one as it does indeed seems to list all fields in use. I added it my **eventClick** function `var evtObj = $('#calendar').fullCalendar('clientEvents', event.id);` `console.log(evtObj);` This returned an object which I've been trawling through in search of my **creator.displayName** / **email** without any joy thus far, but as we already know I'm not entirely sure what to look for as we already discovered that the field mappings between GCal properties and FullCalendar are not documented anywhere. – Michael B Mar 19 '19 at 01:06
  • I was rather _hoping it would be there somewhere with the original GCal name_, even though the **extendedProperties** list seems to be empty as it only seems to list this rather odd `__proto__: Object` which keeps on appearing. Now that I think about it I may have seen it in the gcal.js script. Dare I even ask what this is all about? In any case I am still **none the wiser**, even though I now know I could have used **clientEvents** to list all properties and save myself lots of time with my previous stack overflow question concerning **event.source** object. Oh well. – Michael B Mar 19 '19 at 01:23
  • "_If it doesn't include data you need then you'd have to either alter the gcal.js script or write your own integration code instead in order to make it include that data from Google in the object it passes to fullCalendar._" ... I use CDN for gcal.js and have no intention of altering it. As for integrating my own code to ensure a standard GCal property comes across to FullCalendar, I shouldn't really have to. After all we're talking about a default GCal properties which appears on every calendar event! **creator.displayName** / **creator.email** are as standard GCal properties as they come. – Michael B Mar 19 '19 at 01:42
  • Ok re the misquote...I'm guessing you originally posted this when the link https://fullcalendar.io/docs/google-calendar pointed to the v3 docs. But it appears maybe v4 was released over the weekend and now the link points to the v4 docs by default. Hence the confusion. – ADyson Mar 19 '19 at 09:18
  • The part of gcal.js (in v3.10) which tells you which properties get transferred is `return { id: item.id, title: item.summary, start: item.start.dateTime || item.start.date, end: item.end.dateTime || item.end.date, url: url, location: item.location, description: item.description, extendedProperties: extendedProperties };` ...so description ought to be in there. https://cdnjs.cloudflare.com/ajax/libs/fullcalendar/3.10.0/gcal.js – ADyson Mar 19 '19 at 09:22
  • the __proto__(object) thing is just a general thing in JS, exposed by your browser's dev tools. Not really relevant here. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto – ADyson Mar 19 '19 at 09:23
  • P.S. I agree it would be better if the mappings were documented...but please don't shoot the messenger. I have no involvement with the fullCalendar project. I'm just a user who likes to help out by answering the odd question about it on this site. As for "I shouldn't really have to" ...this is a free, open-source project we're talking about here. So I'm not quite sure you can have that kind of expectation. If it doesn't quite do what you wanted it to, then you can always make a contribution of some sort to the project. – ADyson Mar 19 '19 at 09:27
  • Lastly, as far as I can tell, the "extendedProperties" which may come back from the google API will only contain fields you defined as custom ones on the google side. So if you're looking for creator, email etc then they're standard properties as far as Google is concerned, so it won't expose them via extendedProperties. I think you've got confused between what's standard in Gcal and what's standard in fullCalendar. If you want them to be visible in fullCalendar then you'll have to modify that snippet of the gcal.js code that I provided above, and host your own version. – ADyson Mar 19 '19 at 09:30
  • 1
    e.g. perhaps `return { id: item.id, title: item.summary, start: item.start.dateTime || item.start.date, end: item.end.dateTime || item.end.date, url: url, location: item.location, description: item.description, extendedProperties: extendedProperties, creator: item.creator };` would do the job. (Note that creator may not always have a displayName, e.g. if the event was created by a Service Account or something. Maybe you might want to include the `organizer` as well - I don't know, depends on your setup.) – ADyson Mar 19 '19 at 09:33
  • Again **thanks for taking the time to look into this ADyson**. Appreciate your input & time spent looking into this. Of course I realise this is an open-source project and **an absolutely fabulous one** at that. You are right perhaps my expectation is a tad high, but then again if something could do with a bit of tweaking/improving then I'm all for voicing this. I also saw the fields you listed in gcal.js and figured they may not be included as they certainly are not on the list nor as part of the empty extendedProperties object So yes **standard GCal** but **not in fullCalendar** – Michael B Mar 19 '19 at 17:04
  • I really don't want to go down the route of hosting my own copy of gcal.js so perhaps I'll go raise this as a potential change (tweak?) with fullCalendar as I really do feel that all key GCal properties, and I very much consider the creator fields key properties, should be part of the fullCalendar properties I will try to argue this with the team at fullCalendar, although I am not entirely sure how to go about doing so as it doesn't fall into a bug/issue as such which understandably they will be focusing on. Again thank a lot for all your help. I will close & accept this answer now as is – Michael B Mar 19 '19 at 17:11
  • No problem. I think you can make a simple "feature request" (I provided the link below). It would be a very small-fry change for them I should think. TBH you could probably code it yourself very quickly (you're just adding a a line or two of code after all) and submit as a ready-made contribution following the guidelines (again link provided below) - that might get accepted more quickly (since less dev/test time is required on the fullCalendar side) if you accompany it with a short paragraph of justification. It doesn't break anything else so I can't see why it would be controversial. – ADyson Mar 19 '19 at 17:14
  • The only thing is now v4 is live I don't know if they'll be making any more changes to v3, or not. So you might have to switch to v4 to use the new feature, if it gets accepted. And if you make a contribution it might be best to base it on the v4 code. But I'm only speculating - perhaps a conversation with the maintainers before you embark on it would help to clarify what path you should take. – ADyson Mar 19 '19 at 17:15

1 Answers1

1

When the fullCalendar docs say

Google Calendar’s API allows you to specify Extended Properties for your events. The extended properties will be available as the extendedProperties hash that is attached to each Event Object.

they are referring to extra custom fields you may have defined in your Google Calendar events - fields which are not otherwise supported or provided by the Calendar API as standard. These are the fields which fullCalendar will copy as "extra". It is not referring to "any fields which fullCalendar normally doesn't regard as standard".

Now, because almost none of the event data structure returned by the Calendar API would map directly onto the data structure which fullCalendar requires you to provide in order to construct a valid event object (see the list of fullCalendar's "standard" fields in the Event Object docs), we cannot simply provide the JSON output of the Calendar API direct to fullCalendar and expect it to work and automatically map the fields.

That's why fullCalendar has provided the gcal.js file as a convenience utility to connect to the API, retrieve the event data and transform it into the format that fullCalendar expects and will understand. Clearly the developers made a choice about which fields they were going to carry over from one to the other. Since a new object is being constructed to pass to fullCalendar, there's no automatic mapping of any kind - it all relies on what's written in the code. Normally if you provide JSON to fullCalendar direct it also copies across any other fields it finds in the object, in addition to the ones it actually recognises as "standard" (i.e. the standard ones are the ones it uses for specific purposes as explained in the documentation). But again since the code creates new objects for fullCalendar, this does not occur either.

Apart from the note on "extendedProperties", there's no explicit documentation of which fields the code copies from the API output into the fullCalendar-compatible event objects. A quick experiement using console.log($("#calendar").fullCalendar("clientEvents")); in your page will reveal what properties the final events have, but you can also look in the source code. At the time of writing, the latest version of fullCalendar v3 was 3.10, and the gcal.js source code for that version (viewable here).

The code contains the following snippet to transform the API data into a fullCalendar object:

    return {
        id: item.id,
        title: item.summary,
        start: item.start.dateTime || item.start.date,
        end: item.end.dateTime || item.end.date,
        url: url,
        location: item.location,
        description: item.description,
        extendedProperties: extendedProperties
    };

In your question and comments, you've mentioned that you'd be interested in the creatorand description fields which the Calendar API provides. These are standard fields in GCal (as per the resource representation docs) and therefore would not be in the "extendedProperties" collection. You can also see that description is already copied across by gcal.js, even though it's not a field that fullCalendar ordinarily makes use of - nevertheless it's there if you want to make some use of it in your calendar.

Therefore all you need to do to make the creator field (or any other field from the GCal properties) available in your fullCalendar events is include it in the data which gcal.js copies. e.g.:

    return {
        id: item.id,
        title: item.summary,
        start: item.start.dateTime || item.start.date,
        end: item.end.dateTime || item.end.date,
        url: url,
        location: item.location,
        description: item.description,
        extendedProperties: extendedProperties,
        creator: item.creator
    };

Of course if you are including gcal.js / gcal.min.js via a CDN you'll need to change your code to host your own modified version instead.


As an aside, if you feel the fullCalendar project would benefit as a whole from having more fields from GCal included by default, then since fullCalendar is an open-source, community project, you'd be free to make a feature request to get changes made to the gcal utility (which is really just a convenience add-on as a layer between fullCalendar's standard functionality and the Google Calendar API), or even make a code contribution containing the suggested change, for consideration by the maintainers for inclusion in the main release. Failing that, you can continue to maintain your modified version of gcal.js, or even replace it entirely with your own utility for interacting with the Calendar API.

ADyson
  • 57,178
  • 14
  • 51
  • 63
  • Ah! Just saw this. Thanks for providing this explanation which I will chew on and also from the **feature request** link which will come in handy. Not sure I have the confidence in my JS to be making code contributions yet. Perhaps something for the road ahead :) – Michael B Mar 19 '19 at 17:16
  • In this case you're literally adding one or two lines of code to the existing file along the lines I've shown above. That's all you have to change. And it's trivial to test it beforehand. So I don't think you need to worry too much about that aspect! The harder part I'd guess would be using the tools (e.g. github branches, use of typescript, or whatever they specify) to make the contribution in the desired format. But it's a good thing to have an open-source contribution, however small, against your name, and get used to the kind of process by which many projects accept such contributions. – ADyson Mar 19 '19 at 17:17
  • Thanks, food for thought ;) – Michael B Mar 19 '19 at 17:27