openlmis-referencedata-ui

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Update Togglz API path

Changed version to 5.6.4-SNAPSHOT

Patch release 5.6.3

Bumped version to 5.6.3-SNAPSHOT

Released 5.6.2

Revert "Released referencedata-ui 5.6.2-RC1"

This reverts commit ef0be1802d13931864bee43586926fae91261dea.

Released referencedata-ui 5.6.2-RC1

OLMIS-6750: Fixed typo in changelog

"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));
});
});

OLMIS-6750: Updated changelog

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-6750: Fixed processing periods for different timezones

OLMIS-6696: Added caching a promise when calling for permission strings.
OLMIS-6696: Added caching a promise when calling for permission strings.
OLMIS-6696: Set dataPromise as null after clearing cached permissions and moved return statement.

Please take a look now.

Please take a look now.

OLMIS-6696: Refactored a unit test.

Please change this string concatenation inside toHaveBeenCalledWith function. Perhaps it would be better to save permissions in a variable after calling this.permissionService.load and then use thi...

Please change this string concatenation inside toHaveBeenCalledWith function. Perhaps it would be better to save permissions in a variable after calling this.permissionService.load and then use this variable in 'toHaveBeenCalledWith' and also check if this variable has correct data (just like it is done in other tests here).

OLMIS-6696: Added caching a promise when calling for permission strings.

Bumped version to 5.6.2-SNAPSHOT

Release 5.6.1

Revert "Released referencedata-ui service 5.6.1-RC1"

This reverts commit 3e8333be0a617bcd67d08056a5aa988f1447e5c7.