wearejh / flexitime Goto Github PK

"Hours Remaining this Month" always currently returns September's remaining hours when you travel backward to August or July or June, and doesn't display the month you're currently viewing like other figures surrounding it in the sidebar.

April: +9.5
May: +1.25
June: +3.25
July: +6.5
August: +1.25
September: -22.25

Running balance appears as +11.25 and balance forward as +33.5 - where as it should be calculated as -21 in this example.

At the moment, a maximum carry over amount of hours isn't enforced or implemented, and needs to be.

The field type for the running_balance.balance is currently set to a VARCHAR(255) when it should be a DECIMAL(5,2) or higher. The result of having the running_balance as a string rather than a decimal is that 30.00 is less than 5.5 when you order by that column.

Because, why?

https://github.com/WeareJH/Flexitime/blob/master/src/JhFlexiTime/Service/PeriodService.php#L126

Should be in the InputFilter, I can use the Callback Validator for this: http://framework.zend.com/manual/2.3/en/modules/zend.validator.set.html#callback

The issue was found due to 00:00 as start time and 00:00 as end time being entered, whether I fix that is not decided. That is the same as not entering a record.

There's a bug with the crapped credit when the indexer runs if the user already has capped credit for that month. It causes a Integrity constraint violation on the primary key because an entry already exists and we're trying to add a new row.

Doctrine\DBAL\Exception\UniqueConstraintViolationException
 An exception occurred while executing 'INSERT INTO capped_credit (date, capped_credit, user_id) VALUES (?, ?, ?)' with params ["2017-01-31", 3.75, 14]:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '14-2017-01-31' for key 'PRIMARY'

There are 2 obvious approaches to this:

1. Easiest: Remove all entries for that date and let the indexer re-add them this will also remove any rows that are no longer valid based off user edits to the previous month.
2. Alternative: Use an insert... update on duplicate key approach to update the value. The issue here would be the cleanup of the any user's credit that is no longer valid.