Dashboard

OLMIS-6776: Added retry for Invalid Token issues during Authorization
OLMIS-6776: Added retry for Invalid Token issues during Authorization
OLMIS-6745: Fixed incorrect calculation of Stock on Hand for edge cases.
OLMIS-6745: Fixed incorrect calculation of Stock on Hand for edge cases.
"Fixed adding processing periods (...)"

"Fixed adding processing periods (...)"

I've tried but JS new Date will always adjust to the current timezone. I can set a specific hour etc. but 'Sat Feb 29 2020 16:00:00 GMT+0100' is not equal to 'Sat Feb 29 2020 16:00:00 GMT-0800' and...

I've tried but JS new Date will always adjust to the current timezone. I can set a specific hour etc. but 'Sat Feb 29 2020 16:00:00 GMT+0100' is not equal to 'Sat Feb 29 2020 16:00:00 GMT-0800' and getting rid of Date is not possible since it is used in real code.

Here is an failed attempt to create that test:

describe('create for timezone -8 h', function() {

it('should create new processing period', function() {
var offset = -8;
var startDateString = '2020-03-01';
var endDateString = '2020-03-31';
var start = this.moment.utc(startDateString).utcOffset(offset);
var end = this.moment.utc(endDateString).utcOffset(offset);
var clientStartDate = new Date(start.years(), start.months(), start.dates(), start.hours());
var clientEndDate = new Date(end.years(), end.months(), end.dates(), end.hours());
var period = this.PeriodDataBuilder()
.withName('March2020')
.withStartDate(clientStartDate)
.withEndDate(clientEndDate)
.build();
var periodCopy = angular.copy(period);
periodCopy.startDate = startDateString;
periodCopy.endDate = endDateString;

this.$httpBackend
.expectPOST(this.referencedataUrlFactory('/api/processingPeriods'), periodCopy)
.respond(200, this.period);

var result;
this.periodService
.create(period)
.then(function(response)

Unknown macro: { result = response; }

);
this.$httpBackend.flush();
this.$rootScope.$apply();

expect(angular.toJson(result)).toEqual(angular.toJson(period));
});
});

Yes, they work differently. We were using dateUtils for this but it was causing timezone bug when sending dates to the backend. Although dateUtils works fine for displaying dates on the frontend.

Yes, they work differently. We were using dateUtils for this but it was causing timezone bug when sending dates to the backend. Although dateUtils works fine for displaying dates on the frontend.

I'm asking why we are adding new function when we already have something like this in dateUtils. Can't we just use the existing one? Do they work differently?

I'm asking why we are adding new function when we already have something like this in dateUtils. Can't we just use the existing one? Do they work differently?

dateUtils are a part of ui-components and if there is a place where we expect client's timezone then it will lead to another bug

dateUtils are a part of ui-components and if there is a place where we expect client's timezone then it will lead to another bug

Maybe we could add any test to cover this bug case?

Maybe we could add any test to cover this bug case?

Please add a changelog entry.

Please add a changelog entry.

Can't we use dateUtils.toStringDate instead of creating a new function?

Can't we use dateUtils.toStringDate instead of creating a new function?

OLMIS-6750: Fixed processing periods for different timezones
OLMIS-6750: Fixed processing periods for different timezones
OLMIS-6790 Enabled creating lots with lot code that is partly included in any existing lot code
OLMIS-6790 Enabled creating lots with lot code that is partly included in any existing lot code
maybe 'existing' or sth similar would be better?

maybe 'existing' or sth similar would be better?

it could be assertTrue

it could be assertTrue

OLMIS-6771 Update Spring Boot version to 2.x
OLMIS-6771 Update Spring Boot version to 2.x