Releasing openmrs-module-appointments 1.4.0

Software Bahmni
1

Hi,

I would like to propose if possible the release of Openmrs-module-appointments version 1.4.0.

Let me me know your thoughts on it, or if you have any objection.

2

@rohit.yawalkar @binduak we have upped the dependencies, we can release 1.4.0, right? @icrc.thonorio what additional features are you considering, or it just from master?

3

The reason why we ask this, as to due with a bug on voided patients Other development have been done, but this our main reason

4

@icrc.thonorio … do you need this PR to be merged? or ok without that? Let us know … I will try to make a release 1.4.0 without the above PR

5

We have made the release of 1.4.0

1 Like
6

Hi @angshuonline,

First of all, thank you for the new release :smiley:

Regarding this PR, I talked with Pedro, and it seems that he is still waiting for review.

If possible, do you know someone that could take a look at it?

7

I think there were some questions that we had, and Pedro was to ask folks whether such should be applied all across appointments module. I do not remember exactly but

  1. Storing the date in the server time zone (so that its easier to query and not confusing with other model …eg say a date modified)
  2. Communicating over UTC with the APIs
  3. All others like Service availability definitions, all views, all pages that take input - talking only local time, but communicating to server using UTC.

maybe @gsluthra, @binduak @akhilmalhotra you remember more of what were the asks?

8

Hi @angshuonline ,

I’ve reviewed this this with the rest of the team.

  1. PR was reviewed and service date now is being saved considering server time (same as for other date fields on OpenMRS).
  2. Communicating service times though the API is done using UTC time. We must use UTC because service time is communicated through the API using only a string (i.e.: hh24:mm).
  3. UTC is only used when sending and receiving service time. Everywhere else time is considering local time.

Would it be possible to review the PRs? If any clarification or review is needed, I’ll be available. Thanks!

Frontend module PR: AP-82 - Timezone support for service definitions start and end times by icrc-psousa · Pull Request #186 · Bahmni/openmrs-module-appointments-frontend · GitHub

Backend module PR: AP-82 - Timezone support for service definitions start and end times by icrc-psousa · Pull Request #73 · Bahmni/openmrs-module-appointments · GitHub

cc @gsluthra @binduak @akhilmalhotra

9

I had a look onto the PR for the backend. @binduak would be probably better person to look at the frontend.

Can you please help refresh some context please. questions below

  • Assuming, this is only for ‘Service Definition’ ? Considering APIs now carry UTC dates, do you transform that on the frontend and display in her locale? and visa versa - transform user locale date and send as UTC date?
  • What about individual appointment date?

Can you join the next PAT call, so we can discuss? if urgent, you can join the standup as well … @binduak

10

Hi @angshuonline @binduak ,

I’ll try to answer your 2 quations:

  1. Yes, APIs carry UTC dates and they are transformed on frontend according to user locale. It’s done both ways: user-locale > UTC when submitting to server and UTC > user-locale when loading from server.
  2. On individual appointment date, no changes were made. It was already coping well with timezone differences. We’ve tested this. I believe they’re sent through the API as ISO8601.

I’ll try to attend next PAT call so that we can discuss.