Are you saying to just add the calDavUrl field to WorkEffort? That would work too.
-Adrian --- On Thu, 10/30/08, David E Jones <[EMAIL PROTECTED]> wrote: > From: David E Jones <[EMAIL PROTECTED]> > Subject: Re: CalDAV Servlet (was Work Effort Event Reminders) > To: dev@ofbiz.apache.org > Date: Thursday, October 30, 2008, 10:21 PM > We could probably just use WorkEffort itself for a > "calendar" with the proper type ID and what what. > Conveniently WorkEffort already has associations with all of > these things, including other WorkEfforts through the > WorkEffortAssoc entity. > > -David > > > On Oct 30, 2008, at 1:00 PM, Adrian Crum wrote: > > > 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 > >>> > >>> > >>> > >>> > >>>
