Mateusz Kwiatkowski

OLMIS-6193: fixed translating stockout notifications
OLMIS-6193: fixed translating stockout notifications
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
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

OLMIS-6128: changed docker-dev version to 5.2
OLMIS-6128: changed docker-dev version to 5.2
No. those flags are skipping asking the user about token which is the default and recommended way of authorization, look at the bottom here: https://docs.transifex.com/client/init We are handling p...

No. those flags are skipping asking the user about token which is the default and recommended way of authorization, look at the bottom here: https://docs.transifex.com/client/init
We are handling pushing to transifex using env variables.

This seems to fix the issue with pulling from and pushing into transifex, but there is another issue. The gradle version was changed in the v5 version of docker-dev, but services are not using this...

This seems to fix the issue with pulling from and pushing into transifex, but there is another issue. The gradle version was changed in the v5 version of docker-dev, but services are not using this version. After trying to use it in referencedata build failed: http://build.openlmis.org/job/OpenLMIS-referencedata-pipeline/job/master/614/console
Not sure if I should change gradle version back to the previous one or try to change our gradle build process to work with new gradle version.

OLMIS-6128: added force and no interactive flag to transifex init
OLMIS-6128: added force and no interactive flag to transifex init
OLMIS-3641: removed supply line expand feature flag support
OLMIS-3641: removed supply line expand feature flag support
OLMIS-3641: removed supply line expand feature flag
OLMIS-3641: removed supply line expand feature flag
Revert "OLMIS-3641: added using v2 of supply lines endpoint"
Revert "OLMIS-3641: added using v2 of supply lines endpoint"
OLMIS-3641: fixed problem with sorting supply lines by supplying facility
OLMIS-3641: fixed problem with sorting supply lines by supplying facility
I don't think so. When flag would be removed we don't want to introduce new code, only remove the old version, as we would do refactor using flag.

I don't think so. When flag would be removed we don't want to introduce new code, only remove the old version, as we would do refactor using flag.

Because this info after my changes is located in supply line itself, but I cannot remove this whole resolve until we remove flag completely. The empty object is the easiest solution I think.

Because this info after my changes is located in supply line itself, but I cannot remove this whole resolve until we remove flag completely. The empty object is the easiest solution I think.