Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-6637

Work Effort Month Calendar View Is Broken

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Release Branch 12.04, Release Branch 13.07, Release Branch 14.12, Trunk
    • Fix Version/s: 14.12.01, 12.04.06, 13.07.03, 16.11.01
    • Component/s: workeffort
    • Labels:
      None

      Description

      The Work Effort Month calendar view does not work. The screen does not display:

      https://localhost:8443/workeffort/control/calendar?period=month

      and CPU utilization remains high. It appears to be in an endless loop.

      1. OFBIZ-6637.patch
        0.6 kB
        Gil Portenseigne

        Issue Links

          Activity

          Hide
          gil portenseigne Gil Portenseigne added a comment - - edited

          Hi Adrian, seems to work with me and derby configured. Only meeting in log

          org.ofbiz.base.conversion.ConversionException: java.text.ParseException: Unparseable date: "1446418800000 00:00:00.000"

          when i go to next or previous month (swithing month actually works).

          You may meet a db related issue ?

          Show
          gil portenseigne Gil Portenseigne added a comment - - edited Hi Adrian, seems to work with me and derby configured. Only meeting in log org.ofbiz.base.conversion.ConversionException: java.text.ParseException: Unparseable date: "1446418800000 00:00:00.000" when i go to next or previous month (swithing month actually works). You may meet a db related issue ?
          Hide
          gil portenseigne Gil Portenseigne added a comment -

          Works with postgres on my local environment either...

          Show
          gil portenseigne Gil Portenseigne added a comment - Works with postgres on my local environment either...
          Hide
          adrianc@hlmksw.com Adrian Crum added a comment -

          The problem exists on my local unmodified copy, and it also exists on the demo site.

          Show
          adrianc@hlmksw.com Adrian Crum added a comment - The problem exists on my local unmodified copy, and it also exists on the demo site.
          Hide
          adrianc@hlmksw.com Adrian Crum added a comment -

          It might be caused by having a recurring work effort that uses a temporal expression.

          Show
          adrianc@hlmksw.com Adrian Crum added a comment - It might be caused by having a recurring work effort that uses a temporal expression.
          Hide
          gil portenseigne Gil Portenseigne added a comment -

          Good catch ! The daily Grind test are the origin of the problem !

          Show
          gil portenseigne Gil Portenseigne added a comment - Good catch ! The daily Grind test are the origin of the problem !
          Hide
          gil portenseigne Gil Portenseigne added a comment -

          I did some more analysis around this issue, i may have found an irregularity about temporal expression.

          The issue come when evaluating DAiLY_GRIND temporal expression, which is and intersection of daily 8am rule, and monday to friday without US federal holidays rule.

          First is evaluated the smallest unit of time i.e. 8am rule. The next() method will find its way easily, but... it's might be a day after, and in the ExpressionContext, dayBumped value is set to "true".

          The inifinite loop come from the second rule next() method, which is a difference working on a day on week basis.

          public Calendar next(Calendar cal, ExpressionContext context) {
          Calendar next = (Calendar) cal.clone();
          if (includesDate(next)) {
          if (context.dayBumped)

          { return next; }

          next method return itself if dayBumped is set to true. Fine for the first time, bad for the next leading to an infinite loop.

          The patch I provide is simple and seems the good way to fix it.

          Then inifinite loop will not appear with a daily_grind recurrent workeffort.

          I find out that the calendar have a strange behaviour displaying my recurrent workeffort, i will continue studying it to see if the origin is this fix (i don't think so)...

          Show
          gil portenseigne Gil Portenseigne added a comment - I did some more analysis around this issue, i may have found an irregularity about temporal expression. The issue come when evaluating DAiLY_GRIND temporal expression, which is and intersection of daily 8am rule, and monday to friday without US federal holidays rule. First is evaluated the smallest unit of time i.e. 8am rule. The next() method will find its way easily, but... it's might be a day after, and in the ExpressionContext, dayBumped value is set to "true". The inifinite loop come from the second rule next() method, which is a difference working on a day on week basis. public Calendar next(Calendar cal, ExpressionContext context) { Calendar next = (Calendar) cal.clone(); if (includesDate(next)) { if (context.dayBumped) { return next; } next method return itself if dayBumped is set to true. Fine for the first time, bad for the next leading to an infinite loop. The patch I provide is simple and seems the good way to fix it. Then inifinite loop will not appear with a daily_grind recurrent workeffort. I find out that the calendar have a strange behaviour displaying my recurrent workeffort, i will continue studying it to see if the origin is this fix (i don't think so)...
          Hide
          adrianc@hlmksw.com Adrian Crum added a comment -

          Thank you for working on this!

          Show
          adrianc@hlmksw.com Adrian Crum added a comment - Thank you for working on this!
          Hide
          gil portenseigne Gil Portenseigne added a comment -

          My pleasure !

          Show
          gil portenseigne Gil Portenseigne added a comment - My pleasure !
          Hide
          gil portenseigne Gil Portenseigne added a comment -

          I confirm the fix is good for the endless loop and is quite logic. If a previous rule trigger the dayBump flag, bypassing day increment should revert the flag to false.
          The strange behaviour seems to be a separated bug i will describe in another Jira (getWorkEffortEventsByPeriod service)

          Show
          gil portenseigne Gil Portenseigne added a comment - I confirm the fix is good for the endless loop and is quite logic. If a previous rule trigger the dayBump flag, bypassing day increment should revert the flag to false. The strange behaviour seems to be a separated bug i will describe in another Jira (getWorkEffortEventsByPeriod service)
          Hide
          gil portenseigne Gil Portenseigne added a comment -

          Thanks Adrian for reporting the Bug

          With emotion my first commits fixed it in :

          trunk r1707782
          release14.12 r1707784
          release13.07 r1707785
          release12.04 r1707786

          Show
          gil portenseigne Gil Portenseigne added a comment - Thanks Adrian for reporting the Bug With emotion my first commits fixed it in : trunk r1707782 release14.12 r1707784 release13.07 r1707785 release12.04 r1707786

            People

            • Assignee:
              gil portenseigne Gil Portenseigne
              Reporter:
              adrianc@hlmksw.com Adrian Crum
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development