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
