openlmis-requisition

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
OLMIS-6090: Fixed convert to order endpoint for facilities with multiple program handled by the same...
OLMIS-6090: Fixed convert to order endpoint for facilities with multiple program handled by the same...
OLMIS-6199: Update Reason Categories to include Aggregation
OLMIS-6199: Update Reason Categories to include Aggregation
OLMIS-6193: added changelog

Thanks Mateusz Kwiatkowski, this was more tedious than I thought it might be, though it does still feel safer. Thanks for taking this on.

Thanks Mateusz Kwiatkowski, this was more tedious than I thought it might be, though it does still feel safer. Thanks for taking this on.

OLMIS-6193: added passing locale to requisition status processor

this should fix problem with translating email notifications for status changes

  1. … 5 more files in changeset.
Mateusz Kwiatkowski: I'm not that familiar with this part of spring, though I don't like the warning - it makes me wonder if this setting effects Hibernate or Redis connection pools. I don't think ...

Mateusz Kwiatkowski: I'm not that familiar with this part of spring, though I don't like the warning - it makes me wonder if this setting effects Hibernate or Redis connection pools. I don't think it does, but I'd hate to hit another hard to detect threading bug. The alternative of just passing the locale in sounds safer.

As a side topic I think we need to examine how we've been using Async - a quick survey of the code suggests to me we've gone too far.

As I mentioned on Slack while doing using a @Async new thread is losing context by default. We are getting locale info from LocaleContextHolder while translating messages so this was causing missin...

As I mentioned on Slack while doing using a @Async new thread is losing context by default. We are getting locale info from LocaleContextHolder while translating messages so this was causing missing translations for email notifications. Here is a GitHub issue regarding this problem: https://github.com/spring-projects/spring-boot/issues/14079
I think we are safe to use "dispatcherServlet.setThreadContextInheritable(true);" but Javadoc says:
/**

  • Set whether to expose the LocaleContext and RequestAttributes as inheritable
  • for child threads (using an
    Unknown macro: {@link java.lang.InheritableThreadLocal}

    ).

  • <p>Default is "false", to avoid side effects on spawned background threads.
  • Switch this to "true" to enable inheritance for custom child threads which
  • are spawned during request processing and only used for this request
  • (that is, ending after their initial task, without reuse of the thread).
  • <p><b>WARNING:</b> Do not use inheritance for child threads if you are
  • accessing a thread pool which is configured to potentially add new threads
  • on demand (e.g. a JDK
    Unknown macro: {@link java.util.concurrent.ThreadPoolExecutor}

    ),

  • since this will expose the inherited context to such a pooled thread.
    */
    Alternatively, we could retrieve locale before starting a new thread and passing it there, but it would require more work.
    I would be nice if we could agree on a solution quickly as it is blocking release and I still need to include it in patch release for Angola. Also, I would need to include those changes in other services that are sending notifications asynchronously.
OLMIS-6193: added inheriting context to dispatcher servlet
OLMIS-6193: added inheriting context to dispatcher servlet
OLMIS-6178: Added messages for the SMS channel
OLMIS-6178: Added messages for the SMS channel
Released requisition service version 7.1.1

I'll resolve and I'll add some comments to openlmis/dev that highlight why v5 has a newer version of Gradle than v5.2. I know someone will be confused by this in 6 months without it.

I'll resolve and I'll add some comments to openlmis/dev that highlight why v5 has a newer version of Gradle than v5.2. I know someone will be confused by this in 6 months without it.

Josh Zamor The intention is to have Gradle 5 eventually, however, none of our services currently work with Gradle 5. We have reverted this back to Gradle 4 in order to be able to roll a patch relea...

Josh Zamor The intention is to have Gradle 5 eventually, however, none of our services currently work with Gradle 5. We have reverted this back to Gradle 4 in order to be able to roll a patch release that fixes translations, since there was a change in docker-dev as well.

From what I know Łukasz Lewczyński introduced v5 with new gradle version because it was required by a newer version of hapifhir so yes, it is used. https://github.com/OpenLMIS/openlmis-hapifhir/pul...

From what I know Łukasz Lewczyński introduced v5 with new gradle version because it was required by a newer version of hapifhir so yes, it is used.
https://github.com/OpenLMIS/openlmis-hapifhir/pull/2/files

When I say v5 of this, this == openlmis/dev

When I say v5 of this, this == openlmis/dev

I'm a bit confused - v5 of this moved to Gradle 5, and then v5.2 bumped back to gradle 4. That seems very confusing. Do we intend to remove v5? Does anything work correctly with v5?

I'm a bit confused - v5 of this moved to Gradle 5, and then v5.2 bumped back to gradle 4. That seems very confusing. Do we intend to remove v5? Does anything work correctly with v5?

OLMIS-6128: changed docker-dev version to 5.2
OLMIS-6128: changed docker-dev version to 5.2
OLMIS-6128: changed docker dev image to 5.2