OFBiz › OFBiz - Dev

Work Effort Event Reminders

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

Adrian Crum

Work Effort Event Reminders

I committed some basic work effort event reminder code in revision 708620.

I forgot to mention in the commit log that anyone wanting to deploy the
event reminders will need to set up a scheduled job to run the
processWorkEffortEventReminders service on a regular basis.

Right now the code only supports email reminders. I would like to expand
it to include workstation popup windows, but I'm not sure if I want to
write my own Java client or just add iCalendar capability to OFBiz so
that some other calendar software can handle popup notifications.

Let me know what you think.

-Adrian

Adrian Crum

Re: Work Effort Event Reminders

I would like to be able to set up the WorkEffort component to be an
iCalendar server. I will need a WebDAV servlet, and there is one in
Tomcat - http://wiki.apache.org/tomcat/Tomcat/WebDav.

I'm not a Tomcat or servlet guru, so I need a little help here. Can I
just put those elements in the WorkEffort web.xml file, or is there more
work involved?

-Adrian

Adrian Crum wrote:

> I committed some basic work effort event reminder code in revision 708620.
>
> I forgot to mention in the commit log that anyone wanting to deploy the
> event reminders will need to set up a scheduled job to run the
> processWorkEffortEventReminders service on a regular basis.
>
> Right now the code only supports email reminders. I would like to expand
> it to include workstation popup windows, but I'm not sure if I want to
> write my own Java client or just add iCalendar capability to OFBiz so
> that some other calendar software can handle popup notifications.
>
> Let me know what you think.
>
> -Adrian
>
>

Adrian Crum

Re: Work Effort Event Reminders

I have the Tomcat WebDAV servlet working. Now what I need is a CalDAV
servlet - basically a WebDAV servlet that supports a few extra commands.

I would like to extend the org.apache.catalina.servlets.WebdavServlet
class and add the CalDAV commands. Would that pose a problem if an
installation chose a different app server to run OFBiz on?

-Adrian

Adrian Crum wrote:

> I would like to be able to set up the WorkEffort component to be an
> iCalendar server. I will need a WebDAV servlet, and there is one in
> Tomcat - http://wiki.apache.org/tomcat/Tomcat/WebDav.
>
> I'm not a Tomcat or servlet guru, so I need a little help here. Can I
> just put those elements in the WorkEffort web.xml file, or is there more
> work involved?
>
> -Adrian
>
> Adrian Crum wrote:
>> I committed some basic work effort event reminder code in revision
>> 708620.
>>
>> I forgot to mention in the commit log that anyone wanting to deploy
>> the event reminders will need to set up a scheduled job to run the
>> processWorkEffortEventReminders service on a regular basis.
>>
>> Right now the code only supports email reminders. I would like to
>> expand it to include workstation popup windows, but I'm not sure if I
>> want to write my own Java client or just add iCalendar capability to
>> OFBiz so that some other calendar software can handle popup
>> notifications.
>>
>> Let me know what you think.
>>
>> -Adrian
>>
>>
>

David E Jones

Re: Work Effort Event Reminders

That servlet should be deploy-able on any app server (servlet
container) as long as it's on the classpath, and that shouldn't be a
problem at all (even if tomcat/catalina isn't used).

On a side note, there may be existing CalDav servlets/etc around that
would be easier, in fact it seems like I ran across one at some point,
but I can't remember.

-David

On Oct 29, 2008, at 10:41 AM, Adrian Crum wrote:

> I have the Tomcat WebDAV servlet working. Now what I need is a
> CalDAV servlet - basically a WebDAV servlet that supports a few
> extra commands.
>
> I would like to extend the
> org.apache.catalina.servlets.WebdavServlet class and add the CalDAV
> commands. Would that pose a problem if an installation chose a
> different app server to run OFBiz on?
>
> -Adrian
>
> Adrian Crum wrote:
>> I would like to be able to set up the WorkEffort component to be an
>> iCalendar server. I will need a WebDAV servlet, and there is one in
>> Tomcat - http://wiki.apache.org/tomcat/Tomcat/WebDav.
>> I'm not a Tomcat or servlet guru, so I need a little help here. Can
>> I just put those elements in the WorkEffort web.xml file, or is
>> there more work involved?
>> -Adrian
>> Adrian Crum wrote:
>>> I committed some basic work effort event reminder code in revision
>>> 708620.
>>>
>>> I forgot to mention in the commit log that anyone wanting to
>>> deploy the event reminders will need to set up a scheduled job to
>>> run the processWorkEffortEventReminders service on a regular basis.
>>>
>>> Right now the code only supports email reminders. I would like to
>>> expand it to include workstation popup windows, but I'm not sure
>>> if I want to write my own Java client or just add iCalendar
>>> capability to OFBiz so that some other calendar software can
>>> handle popup notifications.
>>>
>>> Let me know what you think.
>>>
>>> -Adrian
>>>
>>>

Adrian Crum

Re: Work Effort Event Reminders

Thanks David!

I'm still researching and coming up with strategy. Do I try to use an
existing CalDAV servlet and try to get it to use OFBiz as its datastore,
or do I cobble together some libraries (like iCal4j) with some glue logic?

I'll keep everyone updated. Additional comments are welcome!

-Adrian

David E Jones wrote:

>
> That servlet should be deploy-able on any app server (servlet container)
> as long as it's on the classpath, and that shouldn't be a problem at all
> (even if tomcat/catalina isn't used).
>
> On a side note, there may be existing CalDav servlets/etc around that
> would be easier, in fact it seems like I ran across one at some point,
> but I can't remember.
>
> -David
>
>
> On Oct 29, 2008, at 10:41 AM, Adrian Crum wrote:
>
>> I have the Tomcat WebDAV servlet working. Now what I need is a CalDAV
>> servlet - basically a WebDAV servlet that supports a few extra commands.
>>
>> I would like to extend the org.apache.catalina.servlets.WebdavServlet
>> class and add the CalDAV commands. Would that pose a problem if an
>> installation chose a different app server to run OFBiz on?
>>
>> -Adrian
>>
>> Adrian Crum wrote:
>>> I would like to be able to set up the WorkEffort component to be an
>>> iCalendar server. I will need a WebDAV servlet, and there is one in
>>> Tomcat - http://wiki.apache.org/tomcat/Tomcat/WebDav.
>>> I'm not a Tomcat or servlet guru, so I need a little help here. Can I
>>> just put those elements in the WorkEffort web.xml file, or is there
>>> more work involved?
>>> -Adrian
>>> Adrian Crum wrote:
>>>> I committed some basic work effort event reminder code in revision
>>>> 708620.
>>>>
>>>> I forgot to mention in the commit log that anyone wanting to deploy
>>>> the event reminders will need to set up a scheduled job to run the
>>>> processWorkEffortEventReminders service on a regular basis.
>>>>
>>>> Right now the code only supports email reminders. I would like to
>>>> expand it to include workstation popup windows, but I'm not sure if
>>>> I want to write my own Java client or just add iCalendar capability
>>>> to OFBiz so that some other calendar software can handle popup
>>>> notifications.
>>>>
>>>> Let me know what you think.
>>>>
>>>> -Adrian
>>>>
>>>>
>
>

David E Jones

Re: Work Effort Event Reminders

I wish I had done more research in this area. Actually, I think that
Andrew Zeneski mentioned some things along these lines not too long
ago. Any thoughts Andrew?

Whatever is easiest while still doing what is needed would be the way
to go (yeah, I know, that's a pretty duh/obvious statement). What I
mean is that if you can write some datastore adapter for an existing
library and that fits the bill, then great! If we need more
flexibility/control and actually want to generate the text files
needed from templates then that may be a bit more work (or may not be,
depending on how easy the data mappings are!), but may be more
generally useful down the road.

Either way, very cool effort.

-David

On Oct 29, 2008, at 11:59 AM, Adrian Crum wrote:

> Thanks David!
>
> I'm still researching and coming up with strategy. Do I try to use
> an existing CalDAV servlet and try to get it to use OFBiz as its
> datastore, or do I cobble together some libraries (like iCal4j) with
> some glue logic?
>
> I'll keep everyone updated. Additional comments are welcome!
>
> -Adrian
>
>
> David E Jones wrote:
>> That servlet should be deploy-able on any app server (servlet
>> container) as long as it's on the classpath, and that shouldn't be
>> a problem at all (even if tomcat/catalina isn't used).
>> On a side note, there may be existing CalDav servlets/etc around
>> that would be easier, in fact it seems like I ran across one at
>> some point, but I can't remember.
>> -David
>> On Oct 29, 2008, at 10:41 AM, Adrian Crum wrote:
>>> I have the Tomcat WebDAV servlet working. Now what I need is a
>>> CalDAV servlet - basically a WebDAV servlet that supports a few
>>> extra commands.
>>>
>>> I would like to extend the
>>> org.apache.catalina.servlets.WebdavServlet class and add the
>>> CalDAV commands. Would that pose a problem if an installation
>>> chose a different app server to run OFBiz on?
>>>
>>> -Adrian
>>>
>>> Adrian Crum wrote:
>>>> I would like to be able to set up the WorkEffort component to be
>>>> an iCalendar server. I will need a WebDAV servlet, and there is
>>>> one in Tomcat - http://wiki.apache.org/tomcat/Tomcat/WebDav.
>>>> I'm not a Tomcat or servlet guru, so I need a little help here.
>>>> Can I just put those elements in the WorkEffort web.xml file, or
>>>> is there more work involved?
>>>> -Adrian
>>>> Adrian Crum wrote:
>>>>> I committed some basic work effort event reminder code in
>>>>> revision 708620.
>>>>>
>>>>> I forgot to mention in the commit log that anyone wanting to
>>>>> deploy the event reminders will need to set up a scheduled job
>>>>> to run the processWorkEffortEventReminders service on a regular
>>>>> basis.
>>>>>
>>>>> Right now the code only supports email reminders. I would like
>>>>> to expand it to include workstation popup windows, but I'm not
>>>>> sure if I want to write my own Java client or just add iCalendar
>>>>> capability to OFBiz so that some other calendar software can
>>>>> handle popup notifications.
>>>>>
>>>>> Let me know what you think.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>

Adrian Crum

Re: Work Effort Event Reminders

It's kind of going in the same direction as the LDAP integration
discussion we had a few years ago - where a simple requirement to share
a password turned into a proposal to make OFBiz an LDAP server.

In this case, all I wanted was to set up a client app to query OFBiz for
work effort events so that reminders (or alarms) could pop up. Now it's
turning into a more involved task that would make OFBiz an iCal server.

I'm looking at Cosmo right now.

-Adrian

David E Jones wrote:

>
> I wish I had done more research in this area. Actually, I think that
> Andrew Zeneski mentioned some things along these lines not too long ago.
> Any thoughts Andrew?
>
> Whatever is easiest while still doing what is needed would be the way to
> go (yeah, I know, that's a pretty duh/obvious statement). What I mean is
> that if you can write some datastore adapter for an existing library and
> that fits the bill, then great! If we need more flexibility/control and
> actually want to generate the text files needed from templates then that
> may be a bit more work (or may not be, depending on how easy the data
> mappings are!), but may be more generally useful down the road.
>
> Either way, very cool effort.
>
> -David
>
>
> On Oct 29, 2008, at 11:59 AM, Adrian Crum wrote:
>
>> Thanks David!
>>
>> I'm still researching and coming up with strategy. Do I try to use an
>> existing CalDAV servlet and try to get it to use OFBiz as its
>> datastore, or do I cobble together some libraries (like iCal4j) with
>> some glue logic?
>>
>> I'll keep everyone updated. Additional comments are welcome!
>>
>> -Adrian
>>
>>
>> David E Jones wrote:
>>> That servlet should be deploy-able on any app server (servlet
>>> container) as long as it's on the classpath, and that shouldn't be a
>>> problem at all (even if tomcat/catalina isn't used).
>>> On a side note, there may be existing CalDav servlets/etc around that
>>> would be easier, in fact it seems like I ran across one at some
>>> point, but I can't remember.
>>> -David
>>> On Oct 29, 2008, at 10:41 AM, Adrian Crum wrote:
>>>> I have the Tomcat WebDAV servlet working. Now what I need is a
>>>> CalDAV servlet - basically a WebDAV servlet that supports a few
>>>> extra commands.
>>>>
>>>> I would like to extend the
>>>> org.apache.catalina.servlets.WebdavServlet class and add the CalDAV
>>>> commands. Would that pose a problem if an installation chose a
>>>> different app server to run OFBiz on?
>>>>
>>>> -Adrian
>>>>
>>>> Adrian Crum wrote:
>>>>> I would like to be able to set up the WorkEffort component to be an
>>>>> iCalendar server. I will need a WebDAV servlet, and there is one in
>>>>> Tomcat - http://wiki.apache.org/tomcat/Tomcat/WebDav.
>>>>> I'm not a Tomcat or servlet guru, so I need a little help here. Can
>>>>> I just put those elements in the WorkEffort web.xml file, or is
>>>>> there more work involved?
>>>>> -Adrian
>>>>> Adrian Crum wrote:
>>>>>> I committed some basic work effort event reminder code in revision
>>>>>> 708620.
>>>>>>
>>>>>> I forgot to mention in the commit log that anyone wanting to
>>>>>> deploy the event reminders will need to set up a scheduled job to
>>>>>> run the processWorkEffortEventReminders service on a regular basis.
>>>>>>
>>>>>> Right now the code only supports email reminders. I would like to
>>>>>> expand it to include workstation popup windows, but I'm not sure
>>>>>> if I want to write my own Java client or just add iCalendar
>>>>>> capability to OFBiz so that some other calendar software can
>>>>>> handle popup notifications.
>>>>>>
>>>>>> Let me know what you think.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>
>

Adrian Crum

CalDAV Servlet (was Work Effort Event Reminders)

I looked at using Cosmo as a CalDAV servlet. There is more to be done
than just connecting it to the OFBiz data store (it uses Hibernate). I
would also have to figure out a way to get it to use OFBiz's user
authentication. I'm sure I would run into other issues down the road.

I tried to extend the Tomcat Webdav servlet class, but too much of the
class was made private, so I can't access most of its properties and
methods.

I think I'll go ahead and develop our own CalDAV servlet. Using the
iCal4j library, the Tomcat Webdav servlet class, and Cosmo as resources
I think it will be fairly simple to get something going. It will have
limited ability at first, but we can build it out later if there is any
interest in it.

Just in case there is anyone who doesn't understand where I'm going with
this... my goal is to have OFBiz appear to be an iCalendar server -
which will serve work efforts as iCalendar data. This will enable
iCalendar-enabled clients (Apple's iCal, Mozilla Sunbird) to view work
effort calendars.

-Adrian

Adrian Crum wrote:

> It's kind of going in the same direction as the LDAP integration
> discussion we had a few years ago - where a simple requirement to share
> a password turned into a proposal to make OFBiz an LDAP server.
>
> In this case, all I wanted was to set up a client app to query OFBiz for
> work effort events so that reminders (or alarms) could pop up. Now it's
> turning into a more involved task that would make OFBiz an iCal server.
>
> I'm looking at Cosmo right now.
>
> -Adrian
>
> David E Jones wrote:
>>
>> I wish I had done more research in this area. Actually, I think that
>> Andrew Zeneski mentioned some things along these lines not too long
>> ago. Any thoughts Andrew?
>>
>> Whatever is easiest while still doing what is needed would be the way
>> to go (yeah, I know, that's a pretty duh/obvious statement). What I
>> mean is that if you can write some datastore adapter for an existing
>> library and that fits the bill, then great! If we need more
>> flexibility/control and actually want to generate the text files
>> needed from templates then that may be a bit more work (or may not be,
>> depending on how easy the data mappings are!), but may be more
>> generally useful down the road.
>>
>> Either way, very cool effort.
>>
>> -David
>>
>>
>> On Oct 29, 2008, at 11:59 AM, Adrian Crum wrote:
>>
>>> Thanks David!
>>>
>>> I'm still researching and coming up with strategy. Do I try to use an
>>> existing CalDAV servlet and try to get it to use OFBiz as its
>>> datastore, or do I cobble together some libraries (like iCal4j) with
>>> some glue logic?
>>>
>>> I'll keep everyone updated. Additional comments are welcome!
>>>
>>> -Adrian
>>>
>>>
>>> David E Jones wrote:
>>>> That servlet should be deploy-able on any app server (servlet
>>>> container) as long as it's on the classpath, and that shouldn't be a
>>>> problem at all (even if tomcat/catalina isn't used).
>>>> On a side note, there may be existing CalDav servlets/etc around
>>>> that would be easier, in fact it seems like I ran across one at some
>>>> point, but I can't remember.
>>>> -David
>>>> On Oct 29, 2008, at 10:41 AM, Adrian Crum wrote:
>>>>> I have the Tomcat WebDAV servlet working. Now what I need is a
>>>>> CalDAV servlet - basically a WebDAV servlet that supports a few
>>>>> extra commands.
>>>>>
>>>>> I would like to extend the
>>>>> org.apache.catalina.servlets.WebdavServlet class and add the CalDAV
>>>>> commands. Would that pose a problem if an installation chose a
>>>>> different app server to run OFBiz on?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> Adrian Crum wrote:
>>>>>> I would like to be able to set up the WorkEffort component to be
>>>>>> an iCalendar server. I will need a WebDAV servlet, and there is
>>>>>> one in Tomcat - http://wiki.apache.org/tomcat/Tomcat/WebDav.
>>>>>> I'm not a Tomcat or servlet guru, so I need a little help here.
>>>>>> Can I just put those elements in the WorkEffort web.xml file, or
>>>>>> is there more work involved?
>>>>>> -Adrian
>>>>>> Adrian Crum wrote:
>>>>>>> I committed some basic work effort event reminder code in
>>>>>>> revision 708620.
>>>>>>>
>>>>>>> I forgot to mention in the commit log that anyone wanting to
>>>>>>> deploy the event reminders will need to set up a scheduled job to
>>>>>>> run the processWorkEffortEventReminders service on a regular basis.
>>>>>>>
>>>>>>> Right now the code only supports email reminders. I would like to
>>>>>>> expand it to include workstation popup windows, but I'm not sure
>>>>>>> if I want to write my own Java client or just add iCalendar
>>>>>>> capability to OFBiz so that some other calendar software can
>>>>>>> handle popup notifications.
>>>>>>>
>>>>>>> Let me know what you think.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>
>>
>

Adrian Crum

Re: CalDAV Servlet (was Work Effort Event Reminders)

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

BJ Freeman

Re: CalDAV Servlet (was Work Effort Event Reminders)

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
>
>
>
>
>

Adrian Crum

Re: CalDAV Servlet (was Work Effort Event Reminders)

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
>>
>>
>>
>>
>>
>

David E Jones

Re: CalDAV Servlet (was Work Effort Event Reminders)

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
>>>
>>>
>>>
>>>
>>>

Adrian Crum-2

Re: CalDAV Servlet (was Work Effort Event Reminders)

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
> >>>
> >>>
> >>>
> >>>
> >>>

David E Jones

Re: CalDAV Servlet (was Work Effort Event Reminders)

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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>
>
>

Adrian Crum

Re: CalDAV Servlet (was Work Effort Event Reminders)

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 <[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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>
>>
>
>

Adrian Crum

Re: CalDAV Servlet (was Work Effort Event Reminders)

Never mind. Your idea would work in that scenario too.

Back to work...

-Adrian

Adrian Crum wrote:

> 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 <[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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>>
>>
>>
>

Adrian Crum

Re: iCalendar Servlet (was CalDAV Servlet (was Work Effort Event Reminders))

In reply to this post by David E Jones

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:

David E Jones

Re: iCalendar Servlet (was CalDAV Servlet (was Work Effort Event Reminders))

This sounds fine, probably the most flexible long-term approach.

A couple of thoughts:

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

2. the idea of following the fixed assets and finding more work effort
records to include is interesting, but I'm not sure about it

3. I have more significant doubts about following the party and
finding other work efforts; what I'm thinking is that people will have
calendar events associated directly with them (ie with a
WorkEffortPartyAssign) and they will select events from all of their
events and add them to one of their calendars; in other words, when
looking at a single calendar they will just want to see events in that
calendar and not every event associated with that party; in other
words, my vote is that we do not lookup all parties associated with
the calendar work effort and then look for events associated with the
parties

-David

On Nov 3, 2008, at 5:37 PM, 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>>

Adrian Crum

Re: iCalendar Servlet (was CalDAV Servlet (was Work Effort Event Reminders))

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.

> 2. the idea of following the fixed assets and finding more work effort
> records to include is interesting, but I'm not sure about it

Maybe because we see different applications. Example: I'm a maintenance
person in charge of a piece of equipment and I want to add it to my
calendar so I can see when it is being used for production runs and when
maintenances are due.

> 3. I have more significant doubts about following the party and finding
> other work efforts; what I'm thinking is that people will have calendar
> events associated directly with them (ie with a WorkEffortPartyAssign)
> and they will select events from all of their events and add them to one
> of their calendars; in other words, when looking at a single calendar
> they will just want to see events in that calendar and not every event
> associated with that party; in other words, my vote is that we do not
> lookup all parties associated with the calendar work effort and then
> look for events associated with the parties

That could be done too. I was looking at it more from the perspective of
someone wanting to "throw a switch" to allow others to see their
calendar. I can create a setting that will make it work either way.

Good thoughts on your part - I appreciate your comments!

-Adrian

David E Jones

Re: iCalendar Servlet (was CalDAV Servlet (was Work Effort Event Reminders))

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