openlmis-referencedata-ui

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
"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-6696: Added caching a promise when calling for permission strings.
OLMIS-6696: Added caching a promise when calling for permission strings.
Please take a look now.

Please take a look now.

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-6592: Fix for user being able to see Requisitions tab despite not having a home facility or a...
OLMIS-6592: Fix for user being able to see Requisitions tab despite not having a home facility or a...
Done

Done

I think we don't need custom params and paginationId anymore.

I think we don't need custom params and paginationId anymore.

OLMIS-6662 Added possibility to assign Role Assignments based on another User's Assigned Roles
OLMIS-6662 Added possibility to assign Role Assignments based on another User's Assigned Roles
Removed the entry

Removed the entry

This wasn't broken in v3.6 - hence no change since 3.6

This wasn't broken in v3.6 - hence no change since 3.6

OLMIS-6616: Fixed pagination bar for Role Assignments
OLMIS-6616: Fixed pagination bar for Role Assignments