Discussion: Recurring Events

[David E Jones]

Adrian,

Yes, that was the idea with the *millis fields, ie that the UI could  
present more user-friendly time units to the user and then translate  
into this field. With a single field in the database that has a fixed  
UOM it is also easier to write queries to do calculations and  
comparisons.

As for the estimated versus actual time, you are correct that most  
calendaring only has one field and that is usually implied to be  
estimated before, and may or may not be changed after to represent  
that actual time. Rather than doing that we wanted separate fields so  
that we know what the value actually represents, and so that we can  
keep track of both estimated and actual times.

For recurring events it's probably not going to be used much, and if  
it were it wouldn't be on the recurring WorkEffort itself but rather  
on a duplicated record that represents a variance in the history. This  
field is useful for various types of work efforts, including calendar  
events and tasks and manufacturing activities.

-David


On Oct 9, 2008, at 9:20 AM, Adrian Crum wrote:

> 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):
>>>> <!-- Standard Work Schedule Schedules: work availability of 8  
>>>> hours per day, from Monday to Friday -->
>>>> <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