Re: CalDAV Servlet (was Work Effort Event Reminders)

[Adrian Crum]

That would work for users who want to create additional calendars within 
OFBiz, but it doesn't accommodate a simple URL->WorkEffort collection 
mapping.

(On a side note, I'm not sure OFBiz needs to provide that capability - 
calendar clients will let users create additional calendars.)

OFBiz has processes that generate work efforts automatically or 
semi-automatically - like the project manager, manufacturing, and fixed 
asset maintenance. Parties are assigned to those work efforts. So a user 
will have a number of work efforts assigned to him/her that they didn't 
create specifically. They are "free floating" calendar events that are 
not tied to a "calendar."

Let's say I want to let others know my availability, so I publish an 
iCal URL that they can query. When Joe Public checks my calendar to see 
if I'm available (the iCal/CalDAV spec allows this kind of query even on 
calendar items marked "private") the CalDAV servlet needs to know how to 
map that URL to all of the "free floating" work efforts assigned to me.

That's why I suggested adding the URL as a field to the WorkEffort 
entity. So, it would work something like this:

CalDAV Request ->
  Look up URL in WorkEffort ->
  If WorkEffort.partyId is not null
    <- Query all work efforts assigned to that party
  If WorkEffort.fixedAssetId is not null
    <- Query all work efforts assigned to that fixed asset

The work effort containing the URL could have a type like "Calendar 
Properties" or something. The fields in that record can control access. 
For instance, if that work effort is marked as "private" then no queries 
can be performed on that party's/fixed asset's work efforts. Also, the 
work effort description could be used as the calendar name.

-Adrian


David E Jones wrote:

Or use the workEffortId as part of the URL, ie something like:

http://whatever.foo/calendar/11011/workEffortName.ics

This uniquely identifies the calendar and allows the user to specify (in 
the workEffortName field) what they want the ics file and calendar to be 
called.

-David


On Oct 31, 2008, at 6:52 AM, Adrian Crum wrote:

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