Work Effort Event Reminders

[Adrian Crum]

I hadn't thought of that - thanks!

-Adrian

David E Jones wrote:

>
> On Nov 4, 2008, at 10:45 AM, Adrian Crum wrote:
>
>> Thanks for the reply David! Comments inline...
>>
>> David E Jones wrote:
>>> 1. if you're doing a custom servlet you could even just do a
>>> ControlServlet request event, and then all of the OFBiz context stuff
>>> (service/entity engines, etc) is already setup for you
>>
>> I considered that, but all I needed in the end was the delegator, so I
>> C&P the ControlServlet code to get that. The iCalendar servlet is
>> around 100 lines, and I guessed a new request handler might take more
>> than that. *shrug* Six of one, half a dozen of the other.
>
> You wouldn't need a new request handler, just an event written in java
> (ie <event type="java" ...>).
>
> -David
>
>

[Adrian Crum]

The iCalendar integration has been committed - revision 718684.

I followed a strategy similar to the one I discussed previously:

The integration has been set up as a servlet. Work efforts can be
accessed in iCalendar format by using a URL in the form of

https://whatever.foo:8443/iCalendar/[work effort ID]/CalendarName.ics

where [work effort ID] is the ID of the work effort used for calendar
publishing properties, and CalendarName.ics can be any name you want.

There is a demo set up, use:

https://localhost:8443/iCalendar/CALENDAR_PUB_DEMO/MyCalendar.ics

to try it out.

View the CALENDAR_PUB_DEMO work effort to see how the publish property
work effort is set up.

Child work efforts that are related to the publish property work effort
will be published. If parties or fixed assets are related to the publish
property work effort, then their public work efforts will be published.

The published calendar is read-only.

Complex temporal expressions might not translate to iCalendar
recurrences. This is due to the limitations in the iCalendar format.

I will continue to work on this as I have time.

-Adrian


Adrian Crum wrote:

> I decided to go with a plain iCalendar servlet instead of CalDAV. CalDAV
> was too complicated and I felt that I was in over my head. All an
> iCalendar servlet has to do is return an iCalendar file in response to
> an HTTP GET.
>
> Using David's example, the servlet looks up work effort ID 11011. That
> work effort is set up as a kind of "Calendar Properties" value. It is
> used to publish a group of work efforts as a calendar. The field
> contents tell the servlet what to do next.
>
> I figure the servlet would get the parties related to the "Calendar
> Properties" work effort, and return all of their public work efforts.
> Likewise, the servlet would get the fixed assets related to the
> "Calendar Properties" work effort, and return all of their public work
> efforts.
>
> To summarize:
>
> http://whatever.foo/calendar/11011/workEffortName.ics Request ->
>   Look up work effort #11011 ->
>   Get parties related to w/e #11011 ->
>   Get all public work efforts for all related parties ->
>   Get all fixed assets related to w/e #11011 ->
>   Get all public work efforts for all related fixed assets ->
>   <- Return work efforts as iCalendar file
>
> -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 <[hidden email]> wrote:
>>>
>>>> From: David E Jones <[hidden email]>
>>>> Subject: Re: CalDAV Servlet (was Work Effort Event Reminders)
>>>> To: [hidden email]
>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>>
>>
>>
>