The good news is the expression recognized September 7 as a federal holiday.

I think that getWorkEffortEventsByPeriod service need the fix, got one but i'd like some feedback about using recurrencies and workeffort.

Indeed I wonder if it's not absurd to use actualXXXXDate for recurrent workeffort (I tested it and calendar display something not regular). Studying getWorkEffortEventsByPeriod service make me wondering about actualXXXDate recurrent workeffort...

i'll attach my first patch to exclude occurence out of the limits of workeffort start and completion dates. Opinions are welcome !

I might be missing something in the second loop of the service, but this patch will make the display of a estimatedXXX recurrent workeffort good

Yeah, Temporal Expression are fine in my tests

Using the actual date-time fields does not make sense. The temporal expression is used to indicate something that happens repeatedly, like a scheduled event. Using the DAILY_GRIND expression as an example, the expression tells you when your work day is supposed to start, but you might show up late. Your actual arrival time is stored in the actual date-time fields.

Many thanks for the feedback, it's what i imagined, and I guess actual date-time will be stored on a new workeffort for each day.

Better fix, ignoring temporal expression for actual dated workeffort

Commited in
trunk r1707791
R14.12 r1707792
R13.07 r1707793
R12.04 r1707794

Hi Gil,

you should also close this ticket

Happy coding,

Michael

oops Thanks for the reminder