Thanks BJ. If no one else comes up with a better idea, I was thinking of
using relationship entities:
Calendar Entity
---------------
calDavUrl, id-vlong-ne
Description, description
partyId, id
fixedAssetId, id
calendarId, id (Optional - to support multiple calendars)
WorkEffortCalendarAssign Entity (To support multiple calendars)
-------------------------------
workEffortId, id-ne
calendarId, id-ne
The CalDAV servlet would look up the request URL in the Calendar entity,
then use either the partyId or fixedAssetId to look up the work efforts.
-Adrian
BJ Freeman wrote:
just off the top of my head how about a contactmech that is for calendars
then you can use the contactmech ID for the calendar.
Adrian Crum sent the following on 10/30/2008 11:13 AM:
I need your thoughts/comments/suggestions on some CalDAV implementation
issues I need to resolve...
In OFBiz, parties and fixed assets can be assigned to work efforts. In
CalDAV, calendars are viewed as a folder structure with *.ics files in
them. The simplest way to map the CalDAV spec to OFBiz (that I can
imagine) would be to have two main collections (folders) - parties and
fixedassets. Within each collection would be one calendar per
party/fixed asset. Within each collection the iCal "files" (the request
for a file will do a WorkEffort lookup and return an iCal text stream -
there is no physical file) will be named according to user login ID or
fixed asset ID.
So, assuming a base URL of https://localhost:8443/ical - the calendar
for the admin user login would be
https://localhost:8443/ical/parties/admin.ics, and the calendar for the
DEMO_MACHINE fixed asset would be
https://localhost:8443/ical/fixedassets/DEMO_MACHINE.ics.
This is a crude and simple implementation that would serve my immediate
needs, but it needs more work to make it more appealing to others (and
to make it RFC compliant). Here is where I need your help - I need ideas
on these potential issues:
1. Some users might balk at the idea of using their login ID as a
calendar name - since the URL could become public if the user wants to
share their calendar. We would need a way to map an iCal URL to a user's
work efforts. Example: https://localhost:8443/ical/TheAdministrator.ics
maps to user login ID admin.
2. The CalDAV specification allows for an arbitrary arrangement of
collections - just like the folder structure on a hard disk. So, I could
have something like -
https://localhost:8443/ical/adrian.ics
or
https://localhost:8443/ical/adrian/public.ics
https://localhost:8443/ical/adrian/private.ics
So there would have to be a way to map multiple calendars to each user.
The example brings up another issue - how to map work efforts to
different calendars.
Let me know what you think.
-Adrian
