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
