Creating Events from back end code

Hi Phil,

Can your code create an iCal file? We are full iCal based and can import iCal files from the front or backend and on a routine.

Many thanks
Tony

Hi Tony,

Thank you. It can't do anything at the minute...but it could easily do so. I have then two sub-questions:
Is there an .ics standard to which you conform?
How would the back end push an .ics file into jEvents

Many Thanks

See https://tools.ietf.org/html/rfc5545 - we only support the event part not the TODO and FREEBUSY etc.

Thats brilliant, just skimmed through and it apepars very clear on the .ics content building.

Do you have any feedback on the question of how to introduce this .ics file to jEvents via php in the back end?

Many Thanks

When you have an ics file you simply import is as a calendar (use a file import for a one off import or a url import for an updatable one).

You could also look at a CSV file as alternative - see https://www.jevents.net/frequently-aske ... csv-format

Thanks Geraint, but I don't believe that's my issue (or I am not following, so apologies in advance).

We create the event information in a different process (a review of a document) but the code which supports this review has the information necessary to create an event (dates, times, descriptions etc.). We want to automatically generate this event in the jevents calendar WITHOUT any further user interaction, ideally in the back end.

The calendar will then be accessed by users to see what events exist, download etc. as per normal, however, the CREATION process is systemic.

If I have been following the thread, I can create my event as an .ics file but I am still no wiser as to how the back end (by default php) can call the correct jevent routines to import this file.

Write this ics file to a location on your server then import it as a URL and finally setup a cronjob to update the calendar from the URL location

Thanks Geraint,

Understood and will do. If jevents ever plan to create an API for this please let me know.

We follow Joomla! conventions in our development roadmap so we'll probably take advantage of the yet-to-come webservices in Joomla! 3.6 and we'll adapt our extensions to them. There would be an API then, probably.