OFBiz › OFBiz - Dev

Discussion: Recurring Events

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

Adrian Crum

Discussion: Recurring Events

I would like to start working on connecting the temporal expressions
code to recurring events. Before I begin, I want to make sure I
understand the requirements and where things should land.

The WorkEffort entity already has a RecurrenceInfoId field, so adding a
temporal expression ID field to that is obvious.

What about a personal calendar? Where are those recurring events kept?
They aren't related to a work effort or a work schedule.

What about an employee work schedule? I want to assign an employee to
work in the roof department from 8am to 5pm, Monday through Friday, with
a lunch break from 12:00 to 12:30pm. Where would those recurring events go?

-Adrian

David E Jones

Re: Discussion: Recurring Events

On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:

> I would like to start working on connecting the temporal expressions
> code to recurring events. Before I begin, I want to make sure I
> understand the requirements and where things should land.
>
> The WorkEffort entity already has a RecurrenceInfoId field, so
> adding a temporal expression ID field to that is obvious.

Yep, sounds good.

> What about a personal calendar? Where are those recurring events
> kept? They aren't related to a work effort or a work schedule.

Why would a personal calendar be any different from any other calendar
event? Calendar events go in the WorkEffort entity.

> What about an employee work schedule? I want to assign an employee
> to work in the roof department from 8am to 5pm, Monday through
> Friday, with a lunch break from 12:00 to 12:30pm. Where would those
> recurring events go?

Here's what I wrote in Jira OFBIZ-1956: "To push this further, and to
answer Jacques' question: the WorkEffort entity is already designed to
handle work schedules using the WorkEffortType "Available" (ID:
AVAILABLE)."

In addition Jacopo added some demo data that I put together for
another project that shows how this would look (pretty much exactly,
actually) with the old recurrence records (also in that same issue):


<RecurrenceRule recurrenceRuleId="SCHED_STD_40HR_WK" frequency="DAILY"
intervalNumber="1" countNumber="-1"
byHourList="09,10,11,13,14,15,16,17" byDayList="MO,TU,WE,TH,FR"/>
<RecurrenceInfo recurrenceInfoId="SCHED_STD_40HR_WK"
startDateTime="2008-01-01 00:00:00.000"
recurrenceRuleId="SCHED_STD_40HR_WK" recurrenceCount="0"/>
<WorkEffort workEffortId="SCHED_STD_40HR_WK"
workEffortTypeId="AVAILABLE" scopeEnumId="WES_PRIVATE"
workEffortName="Work Schedule Full Time (40 hrs/wk)"
recurrenceInfoId="SCHED_STD_40HR_WK"/>

For the future let's do the same thing except instead of a
recurrenceInfoId on the WorkEffort have a temporalExpressionId.

Does that make sense, or were you looking for something else?

-David

Adrian Crum

Re: Discussion: Recurring Events

That's great input. I just wanted to make sure I didn't go in a
different direction than what was already planned.

Thanks!

-Adrian

David E Jones wrote:

>
> On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:
>
>> I would like to start working on connecting the temporal expressions
>> code to recurring events. Before I begin, I want to make sure I
>> understand the requirements and where things should land.
>>
>> The WorkEffort entity already has a RecurrenceInfoId field, so adding
>> a temporal expression ID field to that is obvious.
>
> Yep, sounds good.
>
>> What about a personal calendar? Where are those recurring events kept?
>> They aren't related to a work effort or a work schedule.
>
> Why would a personal calendar be any different from any other calendar
> event? Calendar events go in the WorkEffort entity.
>
>> What about an employee work schedule? I want to assign an employee to
>> work in the roof department from 8am to 5pm, Monday through Friday,
>> with a lunch break from 12:00 to 12:30pm. Where would those recurring
>> events go?
>
> Here's what I wrote in Jira OFBIZ-1956: "To push this further, and to
> answer Jacques' question: the WorkEffort entity is already designed to
> handle work schedules using the WorkEffortType "Available" (ID:
> AVAILABLE)."
>
> In addition Jacopo added some demo data that I put together for another
> project that shows how this would look (pretty much exactly, actually)
> with the old recurrence records (also in that same issue):
>
> 
> <RecurrenceRule recurrenceRuleId="SCHED_STD_40HR_WK" frequency="DAILY"
> intervalNumber="1" countNumber="-1" byHourList="09,10,11,13,14,15,16,17"
> byDayList="MO,TU,WE,TH,FR"/>
> <RecurrenceInfo recurrenceInfoId="SCHED_STD_40HR_WK"
> startDateTime="2008-01-01 00:00:00.000"
> recurrenceRuleId="SCHED_STD_40HR_WK" recurrenceCount="0"/>
> <WorkEffort workEffortId="SCHED_STD_40HR_WK"
> workEffortTypeId="AVAILABLE" scopeEnumId="WES_PRIVATE"
> workEffortName="Work Schedule Full Time (40 hrs/wk)"
> recurrenceInfoId="SCHED_STD_40HR_WK"/>
>
> For the future let's do the same thing except instead of a
> recurrenceInfoId on the WorkEffort have a temporalExpressionId.
>
> Does that make sense, or were you looking for something else?
>
> -David
>
>

Adrian Crum

Re: Discussion: Recurring Events

In reply to this post by David E Jones

David E Jones wrote:

> On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:
>> What about an employee work schedule? I want to assign an employee to
>> work in the roof department from 8am to 5pm, Monday through Friday,
>> with a lunch break from 12:00 to 12:30pm. Where would those recurring
>> events go?
>
> Here's what I wrote in Jira OFBIZ-1956: "To push this further, and to
> answer Jacques' question: the WorkEffort entity is already designed to
> handle work schedules using the WorkEffortType "Available" (ID:
> AVAILABLE)."

Wouldn't that be confusing? When someone is working they are available?
It seems to me someone is available if they are *not* working.

-Adrian

David E Jones

Re: Discussion: Recurring Events

On Sep 17, 2008, at 4:02 PM, Adrian Crum wrote:

> David E Jones wrote:
>> On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:
>>> What about an employee work schedule? I want to assign an employee
>>> to work in the roof department from 8am to 5pm, Monday through
>>> Friday, with a lunch break from 12:00 to 12:30pm. Where would
>>> those recurring events go?
>> Here's what I wrote in Jira OFBIZ-1956: "To push this further, and
>> to answer Jacques' question: the WorkEffort entity is already
>> designed to handle work schedules using the WorkEffortType
>> "Available" (ID: AVAILABLE)."
>
> Wouldn't that be confusing? When someone is working they are
> available? It seems to me someone is available if they are *not*
> working.

That's correct, they're not working, they're available for work. In
other words those are times when events (or tasks with scheduling) can
be assigned, or when looking at all tasks assigned and their estimated
times how many days it will take to complete them (and when each will
start, etc).

-David

Adrian Crum

Re: Discussion: Recurring Events

David E Jones wrote:

> On Sep 17, 2008, at 4:02 PM, Adrian Crum wrote:
>> David E Jones wrote:
>>> On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:
>>>> What about an employee work schedule? I want to assign an employee
>>>> to work in the roof department from 8am to 5pm, Monday through
>>>> Friday, with a lunch break from 12:00 to 12:30pm. Where would those
>>>> recurring events go?
>>> Here's what I wrote in Jira OFBIZ-1956: "To push this further, and to
>>> answer Jacques' question: the WorkEffort entity is already designed
>>> to handle work schedules using the WorkEffortType "Available" (ID:
>>> AVAILABLE)."
>>
>> Wouldn't that be confusing? When someone is working they are
>> available? It seems to me someone is available if they are *not* working.
>
> That's correct, they're not working, they're available for work. In
> other words those are times when events (or tasks with scheduling) can
> be assigned, or when looking at all tasks assigned and their estimated
> times how many days it will take to complete them (and when each will
> start, etc).

Understood.

Okay, one more question (for future reference, not having to do with
recurring events):

In the example I gave above, I need to show that the employee is working
during those hours - that they are *not* available. Is there a
WorkEffortType for that?

I'm coming from the perspective of production employees punching a time
clock. They are supposed to be working 8am - 5pm, Monday through Friday.

-Adrian

David E Jones

Re: Discussion: Recurring Events

On Sep 17, 2008, at 4:49 PM, Adrian Crum wrote:

> David E Jones wrote:
>> On Sep 17, 2008, at 4:02 PM, Adrian Crum wrote:
>>> David E Jones wrote:
>>>> On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:
>>>>> What about an employee work schedule? I want to assign an
>>>>> employee to work in the roof department from 8am to 5pm, Monday
>>>>> through Friday, with a lunch break from 12:00 to 12:30pm. Where
>>>>> would those recurring events go?
>>>> Here's what I wrote in Jira OFBIZ-1956: "To push this further,
>>>> and to answer Jacques' question: the WorkEffort entity is already
>>>> designed to handle work schedules using the WorkEffortType
>>>> "Available" (ID: AVAILABLE)."
>>>
>>> Wouldn't that be confusing? When someone is working they are
>>> available? It seems to me someone is available if they are *not*
>>> working.
>> That's correct, they're not working, they're available for work. In
>> other words those are times when events (or tasks with scheduling)
>> can be assigned, or when looking at all tasks assigned and their
>> estimated times how many days it will take to complete them (and
>> when each will start, etc).
>
> Understood.
>
> Okay, one more question (for future reference, not having to do with
> recurring events):
>
> In the example I gave above, I need to show that the employee is
> working during those hours - that they are *not* available. Is there
> a WorkEffortType for that?
>
> I'm coming from the perspective of production employees punching a
> time clock. They are supposed to be working 8am - 5pm, Monday
> through Friday.

What is it that they're not available for? Do you mean when they are
working they are not available? In other words, they have a calendar
event that makes them unavailable 8-5 M-F?

-David

Adrian Crum

Re: Discussion: Recurring Events

David E Jones wrote:

> On Sep 17, 2008, at 4:49 PM, Adrian Crum wrote:
>> David E Jones wrote:
>>> On Sep 17, 2008, at 4:02 PM, Adrian Crum wrote:
>>>> David E Jones wrote:
>>>>> On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:
>>>>>> What about an employee work schedule? I want to assign an employee
>>>>>> to work in the roof department from 8am to 5pm, Monday through
>>>>>> Friday, with a lunch break from 12:00 to 12:30pm. Where would
>>>>>> those recurring events go?
>>>>> Here's what I wrote in Jira OFBIZ-1956: "To push this further, and
>>>>> to answer Jacques' question: the WorkEffort entity is already
>>>>> designed to handle work schedules using the WorkEffortType
>>>>> "Available" (ID: AVAILABLE)."
>>>>
>>>> Wouldn't that be confusing? When someone is working they are
>>>> available? It seems to me someone is available if they are *not*
>>>> working.
>>> That's correct, they're not working, they're available for work. In
>>> other words those are times when events (or tasks with scheduling)
>>> can be assigned, or when looking at all tasks assigned and their
>>> estimated times how many days it will take to complete them (and when
>>> each will start, etc).
>>
>> Understood.
>>
>> Okay, one more question (for future reference, not having to do with
>> recurring events):
>>
>> In the example I gave above, I need to show that the employee is
>> working during those hours - that they are *not* available. Is there a
>> WorkEffortType for that?
>>
>> I'm coming from the perspective of production employees punching a
>> time clock. They are supposed to be working 8am - 5pm, Monday through
>> Friday.
>
> What is it that they're not available for? Do you mean when they are
> working they are not available? In other words, they have a calendar
> event that makes them unavailable 8-5 M-F?

That's exactly what I mean. It could be I'm used to seeing things from a
different perspective than what you're describing.

I understand the approach you're describing - someone is available for
work so their work schedule is flagged as available. The perspective I'm
accustomed to is an employee is available for work when they are not
already working. They are available for work when they are "off."

So, I have to look at it differently. An employee is "off" when they are
not available.

No big deal. It will take some getting used to.

-Adrian

David E Jones

Re: Discussion: Recurring Events

On Sep 17, 2008, at 5:18 PM, Adrian Crum wrote:

> David E Jones wrote:
>> On Sep 17, 2008, at 4:49 PM, Adrian Crum wrote:
>>> David E Jones wrote:
>>>> On Sep 17, 2008, at 4:02 PM, Adrian Crum wrote:
>>>>> David E Jones wrote:
>>>>>> On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:
>>>>>>> What about an employee work schedule? I want to assign an
>>>>>>> employee to work in the roof department from 8am to 5pm,
>>>>>>> Monday through Friday, with a lunch break from 12:00 to
>>>>>>> 12:30pm. Where would those recurring events go?
>>>>>> Here's what I wrote in Jira OFBIZ-1956: "To push this further,
>>>>>> and to answer Jacques' question: the WorkEffort entity is
>>>>>> already designed to handle work schedules using the
>>>>>> WorkEffortType "Available" (ID: AVAILABLE)."
>>>>>
>>>>> Wouldn't that be confusing? When someone is working they are
>>>>> available? It seems to me someone is available if they are *not*
>>>>> working.
>>>> That's correct, they're not working, they're available for work.
>>>> In other words those are times when events (or tasks with
>>>> scheduling) can be assigned, or when looking at all tasks
>>>> assigned and their estimated times how many days it will take to
>>>> complete them (and when each will start, etc).
>>>
>>> Understood.
>>>
>>> Okay, one more question (for future reference, not having to do
>>> with recurring events):
>>>
>>> In the example I gave above, I need to show that the employee is
>>> working during those hours - that they are *not* available. Is
>>> there a WorkEffortType for that?
>>>
>>> I'm coming from the perspective of production employees punching a
>>> time clock. They are supposed to be working 8am - 5pm, Monday
>>> through Friday.
>> What is it that they're not available for? Do you mean when they
>> are working they are not available? In other words, they have a
>> calendar event that makes them unavailable 8-5 M-F?
>
> That's exactly what I mean. It could be I'm used to seeing things
> from a different perspective than what you're describing.
>
> I understand the approach you're describing - someone is available
> for work so their work schedule is flagged as available. The
> perspective I'm accustomed to is an employee is available for work
> when they are not already working. They are available for work when
> they are "off."
>
> So, I have to look at it differently. An employee is "off" when they
> are not available.
>
> No big deal. It will take some getting used to.

If someone has nothing scheduled then all it means is we don't know
anything about their schedule, and it may be that they are available
for an appointment or something. If we look at their calendar and see
"Available" type of events then we know they are available for work
unless there is a specific calendar event scheduled on top of the
availability which would make them unavailable.

Does that help? We could change the description of this WorkEffortType
to be "Available for Work" or something...

-David

Jacopo Cappellato-4

Re: Discussion: Recurring Events

Hi Adrian,

>>
>> I understand the approach you're describing - someone is available
>> for work so their work schedule is flagged as available. The
>> perspective I'm accustomed to is an employee is available for work
>> when they are not already working. They are available for work when
>> they are "off."
>

If an employee has a contract to work 8 hours a day from 9am to 6pm
(with 1 hour of break from 12 to 1pm) then you cannot (well... at
least you shouldn't) assign a task to him outside this time frame; he/
she is *not* available for work 24 hours per day; that is why we need
to set the boundaries of availability and then schedule tasks/
assignment inside this frame.

Jacopo

smime.p7s (6K) Download Attachment

Adrian Crum-2

Re: Discussion: Recurring Events

In reply to this post by David E Jones

--- On Wed, 9/17/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: Discussion: Recurring Events
> To: [hidden email]
> Date: Wednesday, September 17, 2008, 5:14 PM
> On Sep 17, 2008, at 5:18 PM, Adrian Crum wrote:
>
> > David E Jones wrote:
> >> On Sep 17, 2008, at 4:49 PM, Adrian Crum wrote:
> >>> David E Jones wrote:
> >>>> On Sep 17, 2008, at 4:02 PM, Adrian Crum
> wrote:
> >>>>> David E Jones wrote:
> >>>>>> On Sep 17, 2008, at 2:15 PM,
> Adrian Crum wrote:
> >>>>>>> What about an employee work
> schedule? I want to assign an
> >>>>>>> employee to work in the roof
> department from 8am to 5pm,
> >>>>>>> Monday through Friday, with a
> lunch break from 12:00 to
> >>>>>>> 12:30pm. Where would those
> recurring events go?
> >>>>>> Here's what I wrote in Jira
> OFBIZ-1956: "To push this further,
> >>>>>> and to answer Jacques'
> question: the WorkEffort entity is
> >>>>>> already designed to handle work
> schedules using the
> >>>>>> WorkEffortType
> "Available" (ID: AVAILABLE)."
> >>>>>
> >>>>> Wouldn't that be confusing? When
> someone is working they are
> >>>>> available? It seems to me someone is
> available if they are *not*
> >>>>> working.
> >>>> That's correct, they're not
> working, they're available for work.
> >>>> In other words those are times when events
> (or tasks with
> >>>> scheduling) can be assigned, or when
> looking at all tasks
> >>>> assigned and their estimated times how
> many days it will take to
> >>>> complete them (and when each will start,
> etc).
> >>>
> >>> Understood.
> >>>
> >>> Okay, one more question (for future reference,
> not having to do
> >>> with recurring events):
> >>>
> >>> In the example I gave above, I need to show
> that the employee is
> >>> working during those hours - that they are
> *not* available. Is
> >>> there a WorkEffortType for that?
> >>>
> >>> I'm coming from the perspective of
> production employees punching a
> >>> time clock. They are supposed to be working
> 8am - 5pm, Monday
> >>> through Friday.
> >> What is it that they're not available for? Do
> you mean when they
> >> are working they are not available? In other
> words, they have a
> >> calendar event that makes them unavailable 8-5
> M-F?
> >
> > That's exactly what I mean. It could be I'm
> used to seeing things
> > from a different perspective than what you're
> describing.
> >
> > I understand the approach you're describing -
> someone is available
> > for work so their work schedule is flagged as
> available. The
> > perspective I'm accustomed to is an employee is
> available for work
> > when they are not already working. They are available
> for work when
> > they are "off."
> >
> > So, I have to look at it differently. An employee is
> "off" when they
> > are not available.
> >
> > No big deal. It will take some getting used to.
>
> If someone has nothing scheduled then all it means is we
> don't know
> anything about their schedule, and it may be that they are
> available
> for an appointment or something. If we look at their
> calendar and see
> "Available" type of events then we know they are
> available for work
> unless there is a specific calendar event scheduled on top
> of the
> availability which would make them unavailable.
>
> Does that help? We could change the description of this
> WorkEffortType
> to be "Available for Work" or something...

No, we don't need to change anything. Like I said, I understand why it's set up that way. It's just different from how I'm used to picturing it.

-Adrian

Adrian Crum-2

Re: Discussion: Recurring Events

In reply to this post by Jacopo Cappellato-4

Thanks Jacopo. I understood that, and it makes perfect sense.

Some background info about me might help explain my confusion...

I worked for 10 years as a scheduler for contract security officers. Each officer was assigned a work schedule. When they were not working their work schedule, they were considered to be "available." I even produced a report for the supervisors that showed when officers were available and how many hours they had worked already. That was a valuable tool that could be used should someone report in sick, or quit their job. An available (not working their work schedule) officer could be called in to fill the vacant shift.

Like I said to David, it's just a matter of me changing my perspective of the meaning of available.

-Adrian

--- On Thu, 9/18/08, Jacopo Cappellato <[hidden email]> wrote:

> From: Jacopo Cappellato <[hidden email]>
> Subject: Re: Discussion: Recurring Events
> To: [hidden email]
> Date: Thursday, September 18, 2008, 2:08 AM
> Hi Adrian,
>
> >>
> >> I understand the approach you're describing -
> someone is available
> >> for work so their work schedule is flagged as
> available. The
> >> perspective I'm accustomed to is an employee
> is available for work
> >> when they are not already working. They are
> available for work when
> >> they are "off."
> >
>
> If an employee has a contract to work 8 hours a day from
> 9am to 6pm
> (with 1 hour of break from 12 to 1pm) then you cannot
> (well... at
> least you shouldn't) assign a task to him outside this
> time frame; he/
> she is *not* available for work 24 hours per day; that is
> why we need
> to set the boundaries of availability and then schedule
> tasks/
> assignment inside this frame.
>
> Jacopo

Jacopo Cappellato-4

Re: Discussion: Recurring Events

On Sep 18, 2008, at 12:28 PM, Adrian Crum wrote:

> I worked for 10 years as a scheduler for contract security officers.

Oh that makes perfect sense... now I understand why you are fixing all
the calendar/time calc framework in OFBiz :-)

Thanks for all your valuable work, Adrian,

Jacopo

smime.p7s (6K) Download Attachment

Adrian Crum-2

Re: Discussion: Recurring Events

I don't do that work anymore. Currently, I'm an IT Manager/Programmer for a company that builds houses.

I'm working on the calendar stuff because I wrote a calendar application for our employees to use, and I'd like to get it into the project.

-Adrian

--- On Thu, 9/18/08, Jacopo Cappellato <[hidden email]> wrote:

> From: Jacopo Cappellato <[hidden email]>
> Subject: Re: Discussion: Recurring Events
> To: [hidden email]
> Date: Thursday, September 18, 2008, 3:40 AM
> On Sep 18, 2008, at 12:28 PM, Adrian Crum wrote:
>
> > I worked for 10 years as a scheduler for contract
> security officers.
>
>
> Oh that makes perfect sense... now I understand why you are
> fixing all
> the calendar/time calc framework in OFBiz :-)
>
> Thanks for all your valuable work, Adrian,
>
> Jacopo

Adrian Crum-2

Re: Discussion: Recurring Events

In reply to this post by Adrian Crum

--- On Wed, 9/17/08, Adrian Crum <[hidden email]> wrote:
> I would like to start working on connecting the temporal
> expressions
> code to recurring events. Before I begin, I want to make
> sure I
> understand the requirements and where things should land.
>
> The WorkEffort entity already has a RecurrenceInfoId field,
> so adding a
> temporal expression ID field to that is obvious.

So, how do we want this to work? On my local copy, I changed the WorkEffortServices.getWorkEffortEventsByPeriod(...) method so that recurring event info is used to create "dummy" work efforts that are added to the results. If a user changes anything in the "dummy" work effort and saves it, then a work effort is created.

How does that sound? Does anyone have any other ideas?

-Adrian

David E Jones

Re: Discussion: Recurring Events

On Sep 18, 2008, at 5:02 AM, Adrian Crum wrote:

> --- On Wed, 9/17/08, Adrian Crum <[hidden email]> wrote:
>> I would like to start working on connecting the temporal
>> expressions
>> code to recurring events. Before I begin, I want to make
>> sure I
>> understand the requirements and where things should land.
>>
>> The WorkEffort entity already has a RecurrenceInfoId field,
>> so adding a
>> temporal expression ID field to that is obvious.
>
> So, how do we want this to work? On my local copy, I changed the
> WorkEffortServices.getWorkEffortEventsByPeriod(...) method so that
> recurring event info is used to create "dummy" work efforts that are
> added to the results. If a user changes anything in the "dummy" work
> effort and saves it, then a work effort is created.
>
> How does that sound? Does anyone have any other ideas?

At what point did you create the new WorkEffort records? What it when
they viewed the recurring event, or when they change something based
on a recurring event (probably along with a question of change just
this event or the entire series)?

-David

Adrian Crum-2

Re: Discussion: Recurring Events

David,

Sorry it took so long to reply to this - I've been giving it a lot of thought before answering.

I think it would be best to just have the one WorkEffort, and any changes made to recurring instances of it would be made to the original copy.

On a side note, the implementation here has some good designs and some bad designs. I'm trying to be careful to port over the good designs and not the bad ones. I came to the conclusion that using the "dummy" WorkEfforts was a bad design.

-Adrian

--- On Thu, 9/18/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: Discussion: Recurring Events
> To: [hidden email]
> Date: Thursday, September 18, 2008, 5:05 AM
> On Sep 18, 2008, at 5:02 AM, Adrian Crum wrote:
>
> > --- On Wed, 9/17/08, Adrian Crum
> <[hidden email]> wrote:
> >> I would like to start working on connecting the
> temporal
> >> expressions
> >> code to recurring events. Before I begin, I want
> to make
> >> sure I
> >> understand the requirements and where things
> should land.
> >>
> >> The WorkEffort entity already has a
> RecurrenceInfoId field,
> >> so adding a
> >> temporal expression ID field to that is obvious.
> >
> > So, how do we want this to work? On my local copy, I
> changed the
> > WorkEffortServices.getWorkEffortEventsByPeriod(...)
> method so that
> > recurring event info is used to create
> "dummy" work efforts that are
> > added to the results. If a user changes anything in
> the "dummy" work
> > effort and saves it, then a work effort is created.
> >
> > How does that sound? Does anyone have any other ideas?
>
> At what point did you create the new WorkEffort records?
> What it when
> they viewed the recurring event, or when they change
> something based
> on a recurring event (probably along with a question of
> change just
> this event or the entire series)?
>
> -David

Adrian Crum

Re: Discussion: Recurring Events

In reply to this post by David E Jones

David (and others),

There is a fundamental difference between the
RecurrenceRule/RecurrenceInfo entities and the TemporalExpression entity
that needs to be addressed.

In the example David gave below, the duration of the recurring event is
assumed to be 8 hrs (byHourList="09,10,11,13,14,15,16,17").

Temporal expressions have no duration information. That is intentional -
a temporal expression indicates when an event occurs, not how long it
will last.

So, in the case of WorkEfforts, we need a way of storing the duration of
a recurring event. Should we use one of the existing *Millis fields, or
do something else?

-Adrian

David E Jones wrote:

David E Jones

Re: Discussion: Recurring Events

Have you decided on a solution to this yet Adrian?

To clarify, you are talking about the duration of each instance of the
recurring event? In other words the temporal expression would describe
when each recurrence of the events starts and then this additional
information would describe how long it lasts each time after it starts.

On the WorkEffort the estimated time millis field should be used. That
field should probably be replaced with something more similar to what
we do in other places, ie have a field for estimated duration and
another for the duration uomId (which could be shared with the field
for the actual duration and possibly other fields). For now though we
can just use the millis field, unless you want to take on the effort
to deprecate that field (not one of the funner things to do!).

-David

On Sep 30, 2008, at 9:40 AM, Adrian Crum wrote:

> David (and others),
>
> There is a fundamental difference between the RecurrenceRule/
> RecurrenceInfo entities and the TemporalExpression entity that needs
> to be addressed.
>
> In the example David gave below, the duration of the recurring event
> is assumed to be 8 hrs (byHourList="09,10,11,13,14,15,16,17").
>
> Temporal expressions have no duration information. That is
> intentional - a temporal expression indicates when an event occurs,
> not how long it will last.
>
> So, in the case of WorkEfforts, we need a way of storing the
> duration of a recurring event. Should we use one of the existing
> *Millis fields, or do something else?
>
> -Adrian
>
> David E Jones wrote:
>> On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:
>>> I would like to start working on connecting the temporal
>>> expressions code to recurring events. Before I begin, I want to
>>> make sure I understand the requirements and where things should
>>> land.
>>>
>>> The WorkEffort entity already has a RecurrenceInfoId field, so
>>> adding a temporal expression ID field to that is obvious.
>> Yep, sounds good.
>>> What about a personal calendar? Where are those recurring events
>>> kept? They aren't related to a work effort or a work schedule.
>> Why would a personal calendar be any different from any other
>> calendar event? Calendar events go in the WorkEffort entity.
>>> What about an employee work schedule? I want to assign an employee
>>> to work in the roof department from 8am to 5pm, Monday through
>>> Friday, with a lunch break from 12:00 to 12:30pm. Where would
>>> those recurring events go?
>> Here's what I wrote in Jira OFBIZ-1956: "To push this further, and
>> to answer Jacques' question: the WorkEffort entity is already
>> designed to handle work schedules using the WorkEffortType
>> "Available" (ID: AVAILABLE)."
>> In addition Jacopo added some demo data that I put together for
>> another project that shows how this would look (pretty much
>> exactly, actually) with the old recurrence records (also in that
>> same issue):
>> 
>> <RecurrenceRule recurrenceRuleId="SCHED_STD_40HR_WK"
>> frequency="DAILY" intervalNumber="1" countNumber="-1"
>> byHourList="09,10,11,13,14,15,16,17" byDayList="MO,TU,WE,TH,FR"/>
>> <RecurrenceInfo recurrenceInfoId="SCHED_STD_40HR_WK"
>> startDateTime="2008-01-01 00:00:00.000"
>> recurrenceRuleId="SCHED_STD_40HR_WK" recurrenceCount="0"/>
>> <WorkEffort workEffortId="SCHED_STD_40HR_WK"
>> workEffortTypeId="AVAILABLE" scopeEnumId="WES_PRIVATE"
>> workEffortName="Work Schedule Full Time (40 hrs/wk)"
>> recurrenceInfoId="SCHED_STD_40HR_WK"/>
>> For the future let's do the same thing except instead of a
>> recurrenceInfoId on the WorkEffort have a temporalExpressionId.
>> Does that make sense, or were you looking for something else?
>> -David

Adrian Crum

Re: Discussion: Recurring Events

David,

You are correct - the temporal expression indicates *when* something
occurs, but not how long it lasts.

I thought about using the WorkEffort estimatedMillis field. On the UI
side of things, we could have drop downs for days, hours, minutes,
seconds, etc - then the update service could translate those values to
milliseconds and store them in the work effort.

In my local copy, I set up the following fields (which could be an
alternative to the estimated millis field): durationDays, durationHours,
durationMins, durationSecs. That allowed a direct mapping of UI drop
down values to field values. Either way (estimatedMillis field or
duration* fields) is fine with me. I'll wait for comments from the
community.

I'm not sure we need both estimated duration and actual duration. A
calendar event duration would be considered estimated.

Example: a meeting is scheduled for 1PM and the duration is one hour.
That information allows attendees to plan their day. Then the meeting
actually runs one hour and 15 minutes. What is done with the extra 15
minutes? Do we really need to record the extra 15 minutes somewhere?

-Adrian

David E Jones wrote:

>
> Have you decided on a solution to this yet Adrian?
>
> To clarify, you are talking about the duration of each instance of the
> recurring event? In other words the temporal expression would describe
> when each recurrence of the events starts and then this additional
> information would describe how long it lasts each time after it starts.
>
> On the WorkEffort the estimated time millis field should be used. That
> field should probably be replaced with something more similar to what we
> do in other places, ie have a field for estimated duration and another
> for the duration uomId (which could be shared with the field for the
> actual duration and possibly other fields). For now though we can just
> use the millis field, unless you want to take on the effort to deprecate
> that field (not one of the funner things to do!).
>
> -David
>
>
> On Sep 30, 2008, at 9:40 AM, Adrian Crum wrote:
>
>> David (and others),
>>
>> There is a fundamental difference between the
>> RecurrenceRule/RecurrenceInfo entities and the TemporalExpression
>> entity that needs to be addressed.
>>
>> In the example David gave below, the duration of the recurring event
>> is assumed to be 8 hrs (byHourList="09,10,11,13,14,15,16,17").
>>
>> Temporal expressions have no duration information. That is intentional
>> - a temporal expression indicates when an event occurs, not how long
>> it will last.
>>
>> So, in the case of WorkEfforts, we need a way of storing the duration
>> of a recurring event. Should we use one of the existing *Millis
>> fields, or do something else?
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> On Sep 17, 2008, at 2:15 PM, Adrian Crum wrote:
>>>> I would like to start working on connecting the temporal expressions
>>>> code to recurring events. Before I begin, I want to make sure I
>>>> understand the requirements and where things should land.
>>>>
>>>> The WorkEffort entity already has a RecurrenceInfoId field, so
>>>> adding a temporal expression ID field to that is obvious.
>>> Yep, sounds good.
>>>> What about a personal calendar? Where are those recurring events
>>>> kept? They aren't related to a work effort or a work schedule.
>>> Why would a personal calendar be any different from any other
>>> calendar event? Calendar events go in the WorkEffort entity.
>>>> What about an employee work schedule? I want to assign an employee
>>>> to work in the roof department from 8am to 5pm, Monday through
>>>> Friday, with a lunch break from 12:00 to 12:30pm. Where would those
>>>> recurring events go?
>>> Here's what I wrote in Jira OFBIZ-1956: "To push this further, and to
>>> answer Jacques' question: the WorkEffort entity is already designed
>>> to handle work schedules using the WorkEffortType "Available" (ID:
>>> AVAILABLE)."
>>> In addition Jacopo added some demo data that I put together for
>>> another project that shows how this would look (pretty much exactly,
>>> actually) with the old recurrence records (also in that same issue):
>>> 
>>> <RecurrenceRule recurrenceRuleId="SCHED_STD_40HR_WK"
>>> frequency="DAILY" intervalNumber="1" countNumber="-1"
>>> byHourList="09,10,11,13,14,15,16,17" byDayList="MO,TU,WE,TH,FR"/>
>>> <RecurrenceInfo recurrenceInfoId="SCHED_STD_40HR_WK"
>>> startDateTime="2008-01-01 00:00:00.000"
>>> recurrenceRuleId="SCHED_STD_40HR_WK" recurrenceCount="0"/>
>>> <WorkEffort workEffortId="SCHED_STD_40HR_WK"
>>> workEffortTypeId="AVAILABLE" scopeEnumId="WES_PRIVATE"
>>> workEffortName="Work Schedule Full Time (40 hrs/wk)"
>>> recurrenceInfoId="SCHED_STD_40HR_WK"/>
>>> For the future let's do the same thing except instead of a
>>> recurrenceInfoId on the WorkEffort have a temporalExpressionId.
>>> Does that make sense, or were you looking for something else?
>>> -David
>
>