Requisition service 3.1.3 release request

Hello everyone,

  the Malawi team has recently contributed a change to the requisition service that allows service-level tokens to retrieve data for certain endpoints. This is a change that is required by our custom reports and those endpoints are used from our custom module. Unfortunately, we cannot work on a snapshotted version of the requisition service as it also brings the changes required to the latest reference data (with orderables refactor) for which we are not ready just yet and which won't work with ref data 5.0.0. Would it be possible to have the Requisition service 3.1.3 release, containing just the changes up to enabling service-level tokens?

Regards,

  Sebastian Brudzinski.

···


      Sebastian Brudziński

    Software Developer / Team Leader

SolDevelo Sp. z o. o. [LLC]

     Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98  81-451, Gdynia

     [http://www.soldevelo.com](http://www.SolDevelo.com)

               Place of registration: Regional Court for the City of Gdansk            KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,            Share capital: 60,000.00 PLN

sbrudzinski@soldevelo.com

Hello,

  I know that we didn't want to worry about inter-service dependencies for now, but I believe this case highlights a real issue - a PATCH change in requisitions requires a MAJOR update to reference data. For implementations, the reality is that this is not a PATCH change, it is a MAJOR change - the requisition version means very little here.

  I think that we should start thinking about this - it would be easy to hack up a solution that gets the version of the reference data and makes the call based on its version - until we deprecate support.

  Going through the bing bang release with reference data might also be a solution that makes this problem go away - but it won't eliminate it completely.

What does everyone else think?

Regards,

Paweł

···

On 17.05.2017 16:17, Sebastian Brudziński wrote:

Hello everyone,

    the Malawi team has recently contributed a change to the requisition service that allows service-level tokens to retrieve data for certain endpoints. This is a change that is required by our custom reports and those endpoints are used from our custom module. Unfortunately, we cannot work on a snapshotted version of the requisition service as it also brings the changes required to the latest reference data (with orderables refactor) for which we are not ready just yet and which won't work with ref data 5.0.0. Would it be possible to have the Requisition service 3.1.3 release, containing just the changes up to enabling service-level tokens?

Regards,

    Sebastian Brudzinski.
  -- You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to . To post to this group, send email to . To view this discussion on the web visit . For more options, visit .


Paweł Gesek

    Technical Project Manager

      / +48 690 020 875

SolDevelo Sp. z o. o. [LLC]

     Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98  81-451, Gdynia

     [http://www.soldevelo.com](http://www.SolDevelo.com)

               Place of registration: Regional Court for the City of Gdansk            KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,            Share capital: 60,000.00 PLN


        Sebastian Brudziński

                  Software Developer / Team Leader

        SolDevelo Sp. z o. o. [LLC]

       Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98              81-451, Gdynia

       [http://www.soldevelo.com](http://www.SolDevelo.com)

                   Place of registration: Regional Court for the City of Gdansk              KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,  Share capital: 60,000.00 PLN

sbrudzinski@soldevelo.com

openlmis-dev+unsubscribe@googlegroups.com
openlmis-dev@googlegroups.com
https://groups.google.com/d/msgid/openlmis-dev/fa5a267e-9db9-2214-d480-8050907e4e7d%40soldevelo.com
https://groups.google.com/d/optout
pgesek@soldevelo.com

Hi,
What Paweł said make a lot of sense. First of all, each microservice version should make it clear what version of a different microservice it require and when there are some breaking changes in other microservices that require changes in the microservice, we should consider if the microservice SNAPSHOT version (future release) still needs to supports old version of dependent microservice. The best solution here is not producing breaking API changes or think about supports for graceful failures (fault tolerance).

Best Regards,

Paweł

···

On Thursday, May 18, 2017 at 11:11:28 AM UTC+2, Paweł Gesek wrote:

Hello,

  I know that we didn't want to worry about inter-service dependencies for now, but I believe this case highlights a real issue - a PATCH change in requisitions requires a MAJOR update to reference data. For implementations, the reality is that this is not a PATCH change, it is a MAJOR change - the requisition version means very little here.
  I think that we should start thinking about this - it would be easy to hack up a solution that gets the version of the reference data and makes the call based on its version - until we deprecate support.
  Going through the bing bang release with reference data might also be a solution that makes this problem go away - but it won't eliminate it completely.

What does everyone else think?

Regards,

Paweł


  On 17.05.2017 16:17, Sebastian Brudziński wrote:

Hello everyone,

    the Malawi team has recently contributed a change to the requisition service that allows service-level tokens to retrieve data for certain endpoints. This is a change that is required by our custom reports and those endpoints are used from our custom module. Unfortunately, we cannot work on a snapshotted version of the requisition service as it also brings the changes required to the latest reference data (with orderables refactor) for which we are not ready just yet and which won't work with ref data 5.0.0. Would it be possible to have the Requisition service 3.1.3 release, containing just the changes up to enabling service-level tokens?

Regards,

    Sebastian Brudzinski.


        Sebastian Brudziński

                  Software Developer / Team Leader

       sbrud...@soldevelo.com
        SolDevelo Sp. z o. o. [LLC]

       Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98              81-451, Gdynia

       [http://www.soldevelo.com](http://www.SolDevelo.com)



                   Place of registration: Regional Court for the City of Gdansk              KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,  Share capital: 60,000.00 PLN

  You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

  To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

  To post to this group, send email to openlm...@googlegroups.com.

  To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/fa5a267e-9db9-2214-d480-8050907e4e7d%40soldevelo.com](https://groups.google.com/d/msgid/openlmis-dev/fa5a267e-9db9-2214-d480-8050907e4e7d%40soldevelo.com?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Paweł Gesek

    Technical Project Manager


     pge...@soldevelo.com / +48 690 020 875

SolDevelo Sp. z o. o. [LLC]

     Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98  81-451, Gdynia


     [http://www.soldevelo.com](http://www.SolDevelo.com)



               Place of registration: Regional Court for the City of Gdansk            KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,            Share capital: 60,000.00 PLN

The patch release for Malawi didn’t find a problem in semantic versioning that I can see. Requisition Service was working on v3.1.3, which had a planned dependency on Reference Data v6.0.0. For Malawi they suddenly needed a Requisition v3.1.3 that worked with Reference Data v5.0.1. This was outside of the working plan for v3.1.3. While we were able to accommodate that, it should be clear that we don’t want to encourage this - we cut down on what I believe is significant overhead when we have a simple plan and we stick to it. This release cycle was only a sprint long after-all.

We’ve stayed away from building a custom tool to detect another Service’s version as it doesn’t feel like it’ll have much benefit at the moment. I still feel that way, as such a tool wouldn’t have told us anything we didn’t already know in this instance. I do think Service’s should provide a list of the dependent services+version they expect to work with - likely in the README. I also feel that aside from the decision we’ve made in Reference Data to do a “big bang” release to get search endpoints paginated and supporting extra data’s POST operation, we generally should prefer to not break contracts - that is don’t try to release new major versions of components. There’s always downstream effects and more work.

So far what I’ve learned out of this, is that it would be nice if contract tests would still work when trying to release outside the original plan - so that for example when I released 3.1.3, contract tests knew to run with Reference Data v5.0.1. I’ve put in a stub ticket for this here: https://openlmis.atlassian.net/browse/OLMIS-2542 . This feels non-trivial to me, but perhaps someone has a spark of inspiration to make this easy?

Best,
Josh

···

On Thursday, May 18, 2017 at 5:45:25 AM UTC-7, Paweł Albecki wrote:

Hi,
What Paweł said make a lot of sense. First of all, each microservice version should make it clear what version of a different microservice it require and when there are some breaking changes in other microservices that require changes in the microservice, we should consider if the microservice SNAPSHOT version (future release) still needs to supports old version of dependent microservice. The best solution here is not producing breaking API changes or think about supports for graceful failures (fault tolerance).

Best Regards,

Paweł

On Thursday, May 18, 2017 at 11:11:28 AM UTC+2, Paweł Gesek wrote:

Hello,

  I know that we didn't want to worry about inter-service dependencies for now, but I believe this case highlights a real issue - a PATCH change in requisitions requires a MAJOR update to reference data. For implementations, the reality is that this is not a PATCH change, it is a MAJOR change - the requisition version means very little here.
  I think that we should start thinking about this - it would be easy to hack up a solution that gets the version of the reference data and makes the call based on its version - until we deprecate support.
  Going through the bing bang release with reference data might also be a solution that makes this problem go away - but it won't eliminate it completely.

What does everyone else think?

Regards,

Paweł


  On 17.05.2017 16:17, Sebastian Brudziński wrote:

Hello everyone,

    the Malawi team has recently contributed a change to the requisition service that allows service-level tokens to retrieve data for certain endpoints. This is a change that is required by our custom reports and those endpoints are used from our custom module. Unfortunately, we cannot work on a snapshotted version of the requisition service as it also brings the changes required to the latest reference data (with orderables refactor) for which we are not ready just yet and which won't work with ref data 5.0.0. Would it be possible to have the Requisition service 3.1.3 release, containing just the changes up to enabling service-level tokens?

Regards,

    Sebastian Brudzinski.


        Sebastian Brudziński

                  Software Developer / Team Leader

       sbrud...@soldevelo.com
        SolDevelo Sp. z o. o. [LLC]

       Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98              81-451, Gdynia

       [http://www.soldevelo.com](http://www.SolDevelo.com)



                   Place of registration: Regional Court for the City of Gdansk              KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,  Share capital: 60,000.00 PLN

  You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

  To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

  To post to this group, send email to openlm...@googlegroups.com.

  To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/fa5a267e-9db9-2214-d480-8050907e4e7d%40soldevelo.com](https://groups.google.com/d/msgid/openlmis-dev/fa5a267e-9db9-2214-d480-8050907e4e7d%40soldevelo.com?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Paweł Gesek

    Technical Project Manager


     pge...@soldevelo.com / +48 690 020 875

SolDevelo Sp. z o. o. [LLC]

     Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98  81-451, Gdynia


     [http://www.soldevelo.com](http://www.SolDevelo.com)



               Place of registration: Regional Court for the City of Gdansk            KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,            Share capital: 60,000.00 PLN

+1 for adding dependency info into the README of each component. That’s a simple thing we can update each time we release, just like we update the CHANGELOG. Then those README files will be a historical record of which component versions worked with which others. I think that’s a simple task with a big benefit for this situation.

-Brandon

···

From: openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

Date: Friday, May 19, 2017 at 12:34 AM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Requisition service 3.1.3 release request

The patch release for Malawi didn’t find a problem in semantic versioning that I can see. Requisition Service was working on v3.1.3, which had a planned dependency on Reference Data v6.0.0. For Malawi they suddenly needed a Requisition v3.1.3 that worked with Reference Data v5.0.1. This was outside of the working plan for v3.1.3. While we were able to accommodate that, it should be clear that we don’t want to encourage this - we cut down on what I believe is significant overhead when we have a simple plan and we stick to it. This release cycle was only a sprint long after-all.

We’ve stayed away from building a custom tool to detect another Service’s version as it doesn’t feel like it’ll have much benefit at the moment. I still feel that way, as such a tool wouldn’t have told us anything we didn’t already know in this instance. I do think Service’s should provide a list of the dependent services+version they expect to work with - likely in the README. I also feel that aside from the decision we’ve made in Reference Data to do a “big bang” release to get search endpoints paginated and supporting extra data’s POST operation, we generally should prefer to not break contracts - that is don’t try to release new major versions of components. There’s always downstream effects and more work.

So far what I’ve learned out of this, is that it would be nice if contract tests would still work when trying to release outside the original plan - so that for example when I released 3.1.3, contract tests knew to run with Reference Data v5.0.1. I’ve put in a stub ticket for this here: https://openlmis.atlassian.net/browse/OLMIS-2542 . This feels non-trivial to me, but perhaps someone has a spark of inspiration to make this easy?

Best,

Josh

On Thursday, May 18, 2017 at 5:45:25 AM UTC-7, Paweł Albecki wrote:

Hi,

What Paweł said make a lot of sense. First of all, each microservice version should make it clear what version of a different microservice it require and when there are some breaking changes in other microservices that require changes in the microservice, we should consider if the microservice SNAPSHOT version (future release) still needs to supports old version of dependent microservice. The best solution here is not producing breaking API changes or think about supports for graceful failures (fault tolerance).

Best Regards,

Paweł

On Thursday, May 18, 2017 at 11:11:28 AM UTC+2, Paweł Gesek wrote:

Hello,

I know that we didn’t want to worry about inter-service dependencies for now, but I believe this case highlights a real issue - a PATCH change in requisitions requires a MAJOR update to reference data. For implementations, the reality is that this is not a PATCH change, it is a MAJOR change - the requisition version means very little here.

I think that we should start thinking about this - it would be easy to hack up a solution that gets the version of the reference data and makes the call based on its version - until we deprecate support.

Going through the bing bang release with reference data might also be a solution that makes this problem go away - but it won’t eliminate it completely.

What does everyone else think?

Regards,

Paweł

On 17.05.2017 16:17, Sebastian Brudziński wrote:

Hello everyone,

the Malawi team has recently contributed a change to the requisition service that allows service-level tokens to retrieve data for certain endpoints. This is a change that is required by our custom reports and those endpoints are used from our custom module. Unfortunately, we cannot work on a snapshotted version of the requisition service as it also brings the changes required to the latest reference data (with orderables refactor) for which we are not ready just yet and which won’t work with ref data 5.0.0. Would it be possible to have the Requisition service 3.1.3 release, containing just the changes up to enabling service-level tokens?

Regards,

Sebastian Brudzinski.

Sebastian Brudziński

Software Developer / Team Leader

sbrud...@soldevelo.com

SolDevelo Sp. z o. o. [LLC]

Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia

http://www.soldevelo.com

Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/fa5a267e-9db9-2214-d480-8050907e4e7d%40soldevelo.com
.

For more options, visit
https://groups.google.com/d/optout
.

Paweł Gesek

Technical Project Manager

pge...@soldevelo.com / +48 690 020 875

SolDevelo Sp. z o. o. [LLC]

Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia

http://www.soldevelo.com

Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/6238674b-b909-43c9-9b3e-1ef6520aa575%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

I think the problem is that Malawi tried to update one service independently based on the service version it was working towards - and this wasn’t possible, due to a patch version forcing a major update to reference data - the version ignores this coupling.

If we list out the dependency versions and the dependency versions of the new version  the component is working towards, this will help, but it still makes things complicated for implementers trying to figure out if they can apply a patch to a given service.

Regards,

Paweł
···

On 19.05.2017 00:39, Brandon Bowersox-Johnson wrote:

        +1 for adding dependency info into the README of each component. That’s a simple thing we can update each time we release, just like we update the CHANGELOG. Then those README files will be a historical record of which component versions worked with which others. I think that’s a simple task with a big benefit for this situation.

-Brandon

**From:
**
on behalf of Josh Zamor Friday, May 19, 2017 at 12:34 AM OpenLMIS Dev Re: [openlmis-dev] Requisition service 3.1.3 release request

        The patch release for Malawi didn't find a problem in semantic versioning that I can see.  Requisition Service was working on v3.1.3, which had a planned dependency on Reference Data v6.0.0.  For Malawi they suddenly needed a Requisition v3.1.3 that worked with Reference Data v5.0.1.  This was outside of the working plan for v3.1.3.  While we were able to accommodate that, it should be clear that we don't want to encourage this - we cut down on what I believe is significant overhead when we have a simple plan and we stick to it.  This release cycle was only a sprint long after-all.



        We've stayed away from building a custom tool to detect another Service's version as it doesn't feel like it'll have much benefit at the moment.  I still feel that way, as such a tool wouldn't have told us anything we didn't already know in this instance.  I do think Service's should provide a list of the dependent services+version they expect to work with - likely in the README.  I also feel that aside from the decision we've made in Reference Data to do a "big bang" release to get search endpoints paginated and supporting extra data's POST operation, we generally should prefer to not break contracts - that is don't try to release new major versions of components.  There's always downstream effects and more work.



        So far what I've learned out of this, is that it would be nice if contract tests would still work when trying to release outside the original plan - so that for example when I released 3.1.3, contract tests knew to run with Reference Data v5.0.1.  I've put in a stub ticket for this here:  .  This feels non-trivial to me, but perhaps someone has a spark of inspiration to make this easy? Best, Josh On Thursday, May 18, 2017 at 5:45:25 AM UTC-7, Paweł Albecki wrote:

Hi,

              What Paweł said make a lot of sense. First of all, each microservice version should make it clear what version of a different microservice                   it require and when there are some breaking changes in other microservices that require changes in the microservice, we should consider if the microservice SNAPSHOT version (future release) still needs to supports old version of dependent microservice. The best solution here is not producing breaking API changes or think about supports for graceful failures (fault tolerance).

Best Regards,

Paweł

              On Thursday, May 18, 2017 at 11:11:28 AM UTC+2, Paweł Gesek wrote:

Hello,

                  I know that we didn't want to worry about inter-service dependencies for now, but I believe this case highlights a real issue - a PATCH change in requisitions requires a MAJOR update to reference data. For implementations, the reality is that this is not a PATCH change, it is a MAJOR change - the requisition version means very little here.
                  I think that we should start thinking about this - it would be easy to hack up a solution that gets the version of the reference data and makes the call based on its version - until we deprecate support.
                  Going through the bing bang release with reference data might also be a solution that makes this problem go away - but it won't eliminate it completely.
                  What does everyone else think?



                  Regards,

                  Paweł
                    On 17.05.2017 16:17, Sebastian Brudziński wrote:

Hello everyone,

                    the Malawi team has recently contributed a change to the requisition service that allows service-level tokens to retrieve data for certain endpoints. This is a change that is required by our custom reports and those endpoints are used from our custom module. Unfortunately, we cannot work on a snapshotted version of the requisition service as it also brings the changes required to the latest reference data (with orderables refactor) for which we are not ready just yet and which won't work with ref data 5.0.0. Would it be possible to have the Requisition service 3.1.3 release, containing just the changes up to enabling service-level tokens?

Regards,

                    Sebastian Brudzinski.

Sebastian Brudziński

                      Software Developer / Team Leader

SolDevelo Sp. z o. o. [LLC]

                      Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia

                      [http://www.soldevelo.com](http://www.SolDevelo.com)



                      Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN

                    You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

                    To unsubscribe from this group and stop receiving emails from it, send an email to . To post to this group, send email to . To view this discussion on the web visit . For more options, visit .

Paweł Gesek

                      Technical Project Manager

                       / +48 690 020 875

SolDevelo Sp. z o. o. [LLC]

                      Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia

                      [http://www.soldevelo.com](http://www.SolDevelo.com)



                      Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN

      You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

      To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

      To post to this group, send email to
        openlmis-dev@googlegroups.com.

      To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/6238674b-b909-43c9-9b3e-1ef6520aa575%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/6238674b-b909-43c9-9b3e-1ef6520aa575%40googlegroups.com?utm_medium=email&utm_source=footer).

      For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

  You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

  To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

  To post to this group, send email to openlmis-dev@googlegroups.com.

  To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/EDD525B8-9E0D-4E2C-845F-11A113E0630E%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/EDD525B8-9E0D-4E2C-845F-11A113E0630E%40villagereach.org?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Paweł Gesek

    Technical Project Manager

      / +48 690 020 875

SolDevelo Sp. z o. o. [LLC]

     Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98  81-451, Gdynia

     [http://www.soldevelo.com](http://www.SolDevelo.com)

               Place of registration: Regional Court for the City of Gdansk            KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,            Share capital: 60,000.00 PLN

openlmis-dev@googlegroups.comjosh.zamor@villagereach.org
Date:
To: openlmis-dev@googlegroups.com
Subject:

https://openlmis.atlassian.net/browse/OLMIS-2542

sbrud...@soldevelo.com

openlmis-dev...@googlegroups.com
openlm...@googlegroups.com

https://groups.google.com/d/msgid/openlmis-dev/fa5a267e-9db9-2214-d480-8050907e4e7d%40soldevelo.com


https://groups.google.com/d/optout

pge...@soldevelo.com

pgesek@soldevelo.com