Model & API changes for Emergency Requisition redesign

Hello everyone,

  as we approached the emergency requisition redesign topic, a discussion emerged on whether or not we should attempt to refactor them to its own REST resource AND/OR database model. When we discussed that internally at Team Parrot and briefly at the last Q&A call, the opinions differed. I wanted to quickly summarize the reasoning for and against the approaches, but feel free to add if I missed anything.

  1. The redesigned emergency requisitions will no longer use reporting fields, such as beginning balance, total consumed/received quantity, total losses and adjustments. This means that those fields will always be empty/null in the database and API responses for emergency requisitions.

  2. Due to missing fields in emergency requisitions, some validations need to be disabled if the requisition is emergency. This may require more branching and if statements if the same code as regular requisitions is reused.

  3. Refactoring emergency requisitions as its own database model may be more time consuming - the demo data needs to be re-done, some reports may need to be re-written, etc.

  4. Several of our UI screens display both emergency and regular requisitions. If emergency requisitions are its own resource, we may need to query two endpoints from multiple screens (requisitions for approval / convert, view requisitions)

  Anything else that may be problematic with either approach? Does one option or another seem more appealing to you?

I’m looking forward to hear your opinions/votes.

Best regards,

  Sebastian.
···


Sebastian Brudziński

              Senior Software Developer / Team Leader

sbrudzinski@soldevelo.com

SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

I read some resources about DDD (not know where) and now I think that emergency requisition should not be treated as a new resource. Why? Regular, emergency and approve requisitions (because we also wanted to create a new resource for requisition in the approve status) are related with the same bounded context. Because of that this does not make sense to have several classes to represent one concept - the difference is only in status and/or emergency flag.

Also other problem is with class structure. Let’s assume that we will have a BaseRequisition, RegularRequisition, EmergencyRequisition classes. Now if we decided to create ApprovedRequisition class we have to create two classes for regular and emergency requisitions. Of course we could try to design structure differently but I still think that there will be problem.

Other thought is that some problems with requisition could be related with that some code were copied from v2 with small changes, we had a small knowledge about the system, DDD etc. We could check the code after OpenLMIS 3.3 release and maybe it would be possible to clean it.

To make validations changes easier I think we could do those validations in the same way how they are done in the stock management service: one validator = one field check. With this approach it would be easier to test and understand what the given validator do.

Another consideration is migration of pre-existing emergency requisitions. We definitely need the existing Emergency Requisitions in running implementations (such as Malawi) to migrate once this update is applied.

Perhaps we should think about the new kind of Emergency Requisitions as just using a different Template that has different columns enabled/disabled. Previously we did not allow disabling some of those columns, so we could add a Requisition Template setting (that will act as a feature toggle) that will allow toggling off those previously-required fields and validations. This would allow admins to configure their Emergency Requisition template to use the new design (with fewer fields).

The old pre-existing Emergency Requisitions should continue to work. Emergency Requisitions already initiated and in progress should continue as is and their validations and calculations should work as they do today. Historical Emergency Requisitions should still be able to be viewed and have their calculations show correctly. In addition, if some programs wanted to keep using Emergency Requisitions with the old template, they should be allowed to do so. They would not be forced to change their template on the day of this upgrade. Instead, the admins could log in and toggle on the new Emergency Requisition template setting(s) at a time they choose, or roll it out program-by-program.

In summary, a “feature toggle” approach might help us ensure safe migration and back-wards compatibility of the data and configurations already in use in live implementations.

-Brandon

···

From: openlmis-dev@googlegroups.com on behalf of Łukasz Lewczyński llewczynski@soldevelo.com

Date: Thursday, February 8, 2018 at 7:18 AM

To: Sebastian Brudziński sbrudzinski@soldevelo.com

Cc:openlmis-dev@googlegroups.comopenlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign

I read some resources about DDD (not know where) and now I think that emergency requisition should not be treated as a new resource. Why? Regular, emergency and approve requisitions (because we also wanted to create a new resource for requisition in the approve status) are related with the same bounded context. Because of that this does not make sense to have several classes to represent one concept - the difference is only in status and/or emergency flag.

Also other problem is with class structure. Let’s assume that we will have a BaseRequisition, RegularRequisition, EmergencyRequisition classes. Now if we decided to create ApprovedRequisition class we have to create two classes for regular and emergency requisitions. Of course we could try to design structure differently but I still think that there will be problem.

Other thought is that some problems with requisition could be related with that some code were copied from v2 with small changes, we had a small knowledge about the system, DDD etc. We could check the code after OpenLMIS 3.3 release and maybe it would be possible to clean it.

To make validations changes easier I think we could do those validations in the same way how they are done in the stock management service: one validator = one field check. With this approach it would be easier to test and understand what the given validator do.

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

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/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.com
.

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

Agreed about the migrations.

  I believe allowing emergency requisitions to have their own requisition template would only add to the complexity. We have a set of rules on which columns need to go together, which are required, etc. All of this would need to be different for emergency requisitions - we want less strict validations, like the ability to disable reporting at all - which is not possible with regular requisition template.

  Is the old/new emergency requisition template toggle something that you see in scope for 3.3? This was never mentioned in , rather a hard-coded approach of a few, selected columns was suggested. I believe keeping old emergency requisitions as-is (still displaying old columns) was not planned as well. If we want to have those additional options, we need to update and reestimate OLMIS-3949.

Best regards,

  Sebastian.
···

https://openlmis.atlassian.net/browse/OLMIS-3949
On 08.02.2018 16:25, Brandon Bowersox-Johnson wrote:

      Another consideration is migration of pre-existing emergency requisitions. We definitely need the existing Emergency Requisitions in running implementations (such as Malawi) to migrate once this update is applied.
      Perhaps we should think about the new kind of Emergency Requisitions as just using a different Template that has different columns enabled/disabled. Previously we did not allow disabling some of those columns, so we could add a Requisition Template setting (that will act as a feature toggle) that will allow toggling off those previously-required fields and validations. This would allow admins to configure their Emergency Requisition template to use the new design (with fewer fields).
      The old pre-existing Emergency Requisitions should continue to work. Emergency Requisitions already initiated and in progress should continue as is and their validations and calculations should work as they do today. Historical Emergency Requisitions should still be able to be viewed and have their calculations show correctly. In addition, if some programs wanted to keep using Emergency Requisitions with the old template, they should be allowed to do so. They would not be forced to change their template on the day of this upgrade. Instead, the admins could log in and toggle on the new Emergency Requisition template setting(s) at a time they choose, or roll it out program-by-program.
      In summary, a “feature toggle” approach might help us ensure safe migration and back-wards compatibility of the data and configurations already in use in live implementations.

-Brandon

From:
on behalf of Łukasz Lewczyński Thursday, February 8, 2018 at 7:18 AM Sebastian Brudziński Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign

          I read some resources about DDD (not know where) and now I think that emergency requisition should not be treated as a new resource. Why? Regular, emergency and approve requisitions (because we also wanted to create a new resource for requisition in the approve status) are related with the same bounded context. Because of that this does not make sense to have several classes to represent one concept - the difference is only in status and/or emergency flag.
          Also other problem is with class structure. Let's assume that we will have a BaseRequisition, RegularRequisition, EmergencyRequisition classes. Now if we decided to create ApprovedRequisition class we have to create two classes for regular and emergency requisitions. Of course we could try to design structure differently but I still think that there will be problem.
            Other thought is that some problems with requisition could be related with that some code were copied from v2 with small changes, we had a small knowledge about the system, DDD etc. We could check the code after OpenLMIS 3.3 release and maybe it would be possible to clean it.
          To make validations changes easier I think we could do those validations in the same way how they are done in the stock management service: one validator = one field check. With this approach it would be easier to test and understand what the given validator do.
      **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

          SolDevelo** Sp. z o.o. [LLC] / [
          www.soldevelo.com](http://www.soldevelo.com)

        Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

        Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

      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/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.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/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org?utm_medium=email&utm_source=footer).

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


Sebastian Brudziński

              Senior Software Developer / Team Leader


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
openlmis-dev@googlegroups.comllewczynski@soldevelo.com
Date:
To: sbrudzinski@soldevelo.com
Cc: "openlmis-dev@googlegroups.com"openlmis-dev@googlegroups.com
Subject:

sbrudzinski@soldevelo.com


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

If we want to have backward compatibility, I think the easiest way would be to leave current requisitions resource as is and create new one for new redesigned emergency requisitions. We can add configuration setting to allow admins to switch between old way and new way. This wouldn’t force us to requisition template validations nor database migration would be needed. But I can miss something important right now.

On Thu, Feb 8, 2018 at 4:45 PM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Agreed about the migrations.

  I believe allowing emergency requisitions to have their own requisition template would only add to the complexity. We have a set of rules on which columns need to go together, which are required, etc. All of this would need to be different for emergency requisitions - we want less strict validations, like the ability to disable reporting at all - which is not possible with regular requisition template.
  Is the old/new emergency requisition template toggle something that you see in scope for 3.3? This was never mentioned in [https://openlmis.atlassian.net/browse/OLMIS-3949](https://openlmis.atlassian.net/browse/OLMIS-3949) , rather a hard-coded approach of a few, selected columns was suggested. I believe keeping old emergency requisitions as-is (still displaying old columns) was not planned as well. If we want to have those additional options, we need to update and reestimate OLMIS-3949.

Best regards,

  Sebastian.
  On 08.02.2018 16:25, Brandon Bowersox-Johnson wrote:
      Another consideration is migration of pre-existing emergency requisitions. We definitely need the existing Emergency Requisitions in running implementations (such as Malawi) to migrate once this update is applied.
      Perhaps we should think about the new kind of Emergency Requisitions as just using a different Template that has different columns enabled/disabled. Previously we did not allow disabling some of those columns, so we could add a Requisition Template setting (that will act as a feature toggle) that will allow toggling off those previously-required fields and validations. This would allow admins to configure their Emergency Requisition template to use the new design (with fewer fields).
      The old pre-existing Emergency Requisitions should continue to work. Emergency Requisitions already initiated and in progress should continue as is and their validations and calculations should work as they do today. Historical Emergency Requisitions should still be able to be viewed and have their calculations show correctly. In addition, if some programs wanted to keep using Emergency Requisitions with the old template, they should be allowed to do so. They would not be forced to change their template on the day of this upgrade. Instead, the admins could log in and toggle on the new Emergency Requisition template setting(s) at a time they choose, or roll it out program-by-program.
      In summary, a “feature toggle” approach might help us ensure safe migration and back-wards compatibility of the data and configurations already in use in live implementations.

-Brandon

From: openlmis-dev@googlegroups.com
on behalf of Łukasz Lewczyński llewczynski@soldevelo.com

          **Date:** Thursday, February 8, 2018 at 7:18 AM

          **To:**               Sebastian Brudziński <sbrudzinski@soldevelo.com>

          **Cc:** "openlmis-dev@googlegroups.com"
          <openlmis-dev@googlegroups.com>

          **Subject:**               Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign
          I read some resources about DDD (not know where) and now I think that emergency requisition should not be treated as a new resource. Why? Regular, emergency and approve requisitions (because we also wanted to create a new resource for requisition in the approve status) are related with the same bounded context. Because of that this does not make sense to have several classes to represent one concept - the difference is only in status and/or emergency flag.
          Also other problem is with class structure. Let's assume that we will have a BaseRequisition, RegularRequisition, EmergencyRequisition classes. Now if we decided to create ApprovedRequisition class we have to create two classes for regular and emergency requisitions. Of course we could try to design structure differently but I still think that there will be problem.
            Other thought is that some problems with requisition could be related with that some code were copied from v2 with small changes, we had a small knowledge about the system, DDD etc. We could check the code after OpenLMIS 3.3 release and maybe it would be possible to clean it.
          To make validations changes easier I think we could do those validations in the same way how they are done in the stock management service: one validator = one field check. With this approach it would be easier to test and understand what the given validator do.
      **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

          SolDevelo** Sp. z o.o. [LLC] / [
          www.soldevelo.com](http://www.soldevelo.com)

        [Al. Zwycięstwa 96/98](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g), 81-451, Gdynia, Poland

        Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

      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/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.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/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org?utm_medium=email&utm_source=footer).

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


Sebastian Brudziński

              Senior Software Developer / Team Leader

     sbrudzinski@soldevelo.com


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

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/8dc4c484-3986-752b-4595-222294774f38%40soldevelo.com.

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

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com

I discussed migration / backwards compatibility with Mary Jo, and here is a short summary of the minimum requirements from her and the Product Committee:

Must Have:

  • Historical emergency requisitions can still be opened and viewed after this upgrade. (You can view and print all their columns; hopefully that is already part of their snapshot.)

  • New requisitions initiated after this upgrade use the new business rules in OLMIS-3949.

  • A warning in Release Notes/CHANGELOG tells implementers that Emergency Requisitions have a mandatory redesign/change.

  • In-progress emergency requisitions at the time of this upgrade are not necessarily supported. (Mary Jo says it is acceptable for the Release Notes/CHANGELOG to tell Implementers they have to finish/approve all in-progress Emergency Requisitions before applying this software upgrade. PC
    noted
    this.)

Not Needed:

  • In-progress emergency requisitions at the time of this upgrade could continue through submit/authorize/approve workflow. (Nice to have/optional.)

  • Administrators could have a toggle in Program Settings to toggle Emergency Requisitions between old way and new way.

In the future , Emergency Requisitions will likely be expanded to have configurable templates. Administrators will eventually be able to toggle columns on or off and change template settings. I believe we want a lot of this business logic to be shared between Emergency Requisitions and Regular Requisitions. We want the ability to add new improvements that can apply to both Emergency and Regular without duplicating code.

Here are my 2 cents about our approach based on this:

(1) Having a toggle to switch between old and new way is not required, but I believe it is a safer technical way to implement this feature change (as a toggle) rather than a forced hard-coded change.

(2) Because we still want lots of shared logic and shared features across Emergency and Regular Requisitions now and into the future, I suggest that Emergency Requisitions should not be a separate database model with separate REST resources. But the Dev Forum is a great place to discuss all this and I welcome other ideas.

-Brandon

···

From: openlmis-dev@googlegroups.com on behalf of Paweł Albecki palbecki@soldevelo.com

Date: Thursday, February 8, 2018 at 8:14 AM

To: Sebastian Brudziński sbrudzinski@soldevelo.com

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign

If we want to have backward compatibility, I think the easiest way would be to leave current requisitions resource as is and create new one for new redesigned emergency requisitions. We can add configuration setting to allow admins to switch between old way and new way. This wouldn’t force us to requisition template validations nor database migration would be needed. But I can miss something important right now.

On Thu, Feb 8, 2018 at 4:45 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com > wrote:

Agreed about the migrations.

I believe allowing emergency requisitions to have their own requisition template would only add to the complexity. We have a set of rules on which columns need to go together, which are required, etc. All of this would need to be different for emergency requisitions - we want less strict validations, like the ability to disable reporting at all - which is not possible with regular requisition template.

Is the old/new emergency requisition template toggle something that you see in scope for 3.3? This was never mentioned in https://openlmis.atlassian.net/browse/OLMIS-3949
, rather a hard-coded approach of a few, selected columns was suggested. I believe keeping old emergency requisitions as-is (still displaying old columns) was not planned as well. If we want to have those additional options, we need to update and reestimate OLMIS-3949.

Best regards,

Sebastian.

On 08.02.2018 16:25, Brandon Bowersox-Johnson wrote:

Another consideration is migration of pre-existing emergency requisitions. We definitely need the existing Emergency Requisitions in running implementations (such as Malawi) to migrate once this update is applied.

Perhaps we should think about the new kind of Emergency Requisitions as just using a different Template that has different columns enabled/disabled. Previously we did not allow disabling some of those columns, so we could add a Requisition Template setting (that will act as a feature toggle) that will allow toggling off those previously-required fields and validations. This would allow admins to configure their Emergency Requisition template to use the new design (with fewer fields).

The old pre-existing Emergency Requisitions should continue to work. Emergency Requisitions already initiated and in progress should continue as is and their validations and calculations should work as they do today. Historical Emergency Requisitions should still be able to be viewed and have their calculations show correctly. In addition, if some programs wanted to keep using Emergency Requisitions with the old template, they should be allowed to do so. They would not be forced to change their template on the day of this upgrade. Instead, the admins could log in and toggle on the new Emergency Requisition template setting(s) at a time they choose, or roll it out program-by-program.

In summary, a “feature toggle” approach might help us ensure safe migration and back-wards compatibility of the data and configurations already in use in live implementations.

-Brandon

From: openlmis-dev@googlegroups.com
on behalf of Łukasz Lewczyński llewczynski@soldevelo.com

Date: Thursday, February 8, 2018 at 7:18 AM

To: Sebastian Brudziński sbrudzinski@soldevelo.com

Cc:openlmis-dev@googlegroups.com
openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign

I read some resources about DDD (not know where) and now I think that emergency requisition should not be treated as a new resource. Why? Regular, emergency and approve requisitions (because we also wanted to create a new resource for requisition in the approve status) are related with the same bounded context. Because of that this does not make sense to have several classes to represent one concept - the difference is only in status and/or emergency flag.

Also other problem is with class structure. Let’s assume that we will have a BaseRequisition, RegularRequisition, EmergencyRequisition classes. Now if we decided to create ApprovedRequisition class we have to create two classes for regular and emergency requisitions. Of course we could try to design structure differently but I still think that there will be problem.

Other thought is that some problems with requisition could be related with that some code were copied from v2 with small changes, we had a small knowledge about the system, DDD etc. We could check the code after OpenLMIS 3.3 release and maybe it would be possible to clean it.

To make validations changes easier I think we could do those validations in the same way how they are done in the stock management service: one validator = one field check. With this approach it would be easier to test and understand what the given validator do.

**http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98 , 81-451, Gdynia, Poland

Phone: +48 58 782 45 40
/ Fax: +48 58 782 45 41

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/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.com.

For more options, visit 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/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org.

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

Sebastian Brudziński

Senior Software Developer / Team Leader

sbrudzinski@soldevelo.com

**http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96 /98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

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/8dc4c484-3986-752b-4595-222294774f38%40soldevelo.com.

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

Paweł Albecki

Software Developer

palbecki@soldevelo.com

**http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

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/CAAJzpfmR4U_2i86ZG2yFsYNtMJx0m7chWmQd7QgKbODpEtyouA%40mail.gmail.com.

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

Thanks for the clarifications, Brandon.

  I don't think that supporting in-progress, emergency requisitions on the update day will be an issue. That is, if we agree that:

  1) the already initiated, emergency requisitions will have all the available products added

  2) only the ordering columns will be displayed for them (same as for any new, emergency requisitions)

  Based on the clarifications and comments, I'm leaning towards not making emergency requisitions its own rest resource / database model and I'm going to design the tickets with that in mind. If anyone has any issues with that, please let me know.

Best regards,

  Sebastian.
···

On 08.02.2018 21:04, Brandon Bowersox-Johnson wrote:

      I discussed migration / backwards compatibility with Mary Jo, and here is a short summary of the minimum requirements from her and the Product Committee:

Must Have:

  •         Historical emergency requisitions can still be opened and viewed after this upgrade. (You can view and print all their columns; hopefully that is already part of their snapshot.)
    
  •         New requisitions initiated after this upgrade use the new business rules in OLMIS-3949.
    
  •         A warning in Release Notes/CHANGELOG tells implementers that Emergency Requisitions have a mandatory redesign/change.
    
  •         In-progress emergency requisitions at the time of this upgrade are not necessarily supported. (Mary Jo says it is acceptable for the Release Notes/CHANGELOG to tell Implementers they have to finish/approve all in-progress Emergency Requisitions before applying this software upgrade. PC [noted](https://openlmis.atlassian.net/wiki/spaces/OP/pages/199655438/PC+January+30+2018)
            this.)
    

Not Needed:

  •         In-progress emergency requisitions at the time of this upgrade could continue through submit/authorize/approve workflow. (Nice to have/optional.)
    
  •         Administrators could have a toggle in Program Settings to toggle Emergency Requisitions between old way and new way.
    

In the future , Emergency Requisitions will likely be expanded to have configurable templates. Administrators will eventually be able to toggle columns on or off and change template settings. I believe we want a lot of this business logic to be shared between Emergency Requisitions and Regular Requisitions. We want the ability to add new improvements that can apply to both Emergency and Regular without duplicating code.

      Here are my 2 cents about our approach based on this:
      (1) Having a toggle to switch between old and new way is not required, but I believe it is a safer technical way to implement this feature change (as a toggle) rather than a forced hard-coded change.
      (2) Because we still want lots of shared logic and shared features across Emergency and Regular Requisitions now and into the future, I suggest that Emergency Requisitions should not be a separate database model with separate REST resources. But the Dev Forum is a great place to discuss all this and I welcome other ideas.

-Brandon

From:
on behalf of Paweł Albecki Thursday, February 8, 2018 at 8:14 AM Sebastian Brudziński OpenLMIS Dev Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign

            If we want to have backward compatibility, I think the easiest way would be to leave current requisitions resource as is and create new one for new redesigned emergency requisitions. We can add configuration setting to allow admins to switch between old way and new way. This wouldn't force us to                   requisition template validations nor database migration would be needed. But I can miss something important right now.
              On Thu, Feb 8, 2018 at 4:45 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com> wrote:
                  Agreed about the migrations.
                  I believe allowing emergency requisitions to have their own requisition template would only add to the complexity. We have a set of rules on which columns need to go together, which are required, etc. All of this would need to be different for emergency requisitions - we want less strict validations, like the ability to disable reporting at all - which is not possible with regular requisition template.
                  Is the old/new emergency requisition template toggle something that you see in scope for 3.3? This was never mentioned in [https://openlmis.atlassian.net/browse/OLMIS-3949](https://openlmis.atlassian.net/browse/OLMIS-3949) , rather a hard-coded approach of a few, selected columns was suggested. I believe keeping old emergency requisitions as-is (still displaying old columns) was not planned as well. If we want to have those additional options, we need to update and reestimate OLMIS-3949.
                  Best regards,

                  Sebastian.
                        On 08.02.2018 16:25, Brandon Bowersox-Johnson wrote:
                          Another consideration is migration of pre-existing emergency requisitions. We definitely need the existing Emergency Requisitions in running implementations (such as Malawi) to migrate once this update is applied.
                          Perhaps we should think about the new kind of Emergency Requisitions as just using a different Template that has different columns enabled/disabled. Previously we did not allow disabling some of those columns, so we could add a Requisition Template setting (that will act as a feature toggle) that will allow toggling off those previously-required fields and validations. This would allow admins to configure their Emergency Requisition template to use the new design (with fewer fields).
                          The old pre-existing Emergency Requisitions should continue to work. Emergency Requisitions already initiated and in progress should continue as is and their validations and calculations should work as they do today. Historical Emergency Requisitions should still be able to be viewed and have their calculations show correctly. In addition, if some programs wanted to keep using Emergency Requisitions with the old template, they should be allowed to do so. They would not be forced to change their template on the day of this upgrade. Instead, the admins could log in and toggle on the new Emergency Requisition template setting(s) at a time they choose, or roll it out program-by-program.
                          In summary, a “feature toggle” approach might help us ensure safe migration and back-wards compatibility of the data and configurations already in use in live implementations.

-Brandon

** From:** openlmis-dev@googlegroups.com
on behalf of Łukasz Lewczyński llewczynski@soldevelo.com

                              **Date:**                                   Thursday, February 8, 2018 at 7:18 AM

                              **To:** Sebastian Brudziński <sbrudzinski@soldevelo.com>

                              **Cc:** "openlmis-dev@googlegroups.com"
                            <openlmis-dev@googlegroups.com>

                              **Subject:**                                   Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign
                              I read some resources about DDD (not know where) and now I think that emergency requisition should not be treated as a new resource. Why? Regular, emergency and approve requisitions (because we also wanted to create a new resource for requisition in the approve status) are related with the same bounded context. Because of that this does not make sense to have several classes to represent one concept - the difference is only in status and/or emergency flag.
                              Also other problem is with class structure. Let's assume that we will have a BaseRequisition, RegularRequisition, EmergencyRequisition classes. Now if we decided to create ApprovedRequisition class we have to create two classes for regular and emergency requisitions. Of course we could try to design structure differently but I still think that there will be problem.
                                Other thought is that some problems with requisition could be related with that some code were copied from v2 with small changes, we had a small knowledge about the system, DDD etc. We could check the code after OpenLMIS 3.3 release and maybe it would be possible to clean it.
                              To make validations changes easier I think we could do those validations in the same way how they are done in the stock management service: one validator = one field check. With this approach it would be easier to test and understand what the given validator do.
                        **![http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

                              SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

                          [                                  Al. Zwycięstwa 96/98](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g)                                , 81-451, Gdynia, Poland

                            Phone:                                   +48 58 782 45 40 / Fax:                                   +48 58 782 45 41
                          --

                          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/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.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/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org?utm_medium=email&utm_source=footer).

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

** Sebastian Brudziński**

                      Senior Software Developer / Team Leader

                    sbrudzinski@soldevelo.com
              **![http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

                    SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

                [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                        /98, 81-451, Gdynia, Poland

                                          Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
                --

                                      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/8dc4c484-3986-752b-4595-222294774f38%40soldevelo.com](https://groups.google.com/d/msgid/openlmis-dev/8dc4c484-3986-752b-4595-222294774f38%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ł Albecki**

                            Software Developer

                          palbecki@soldevelo.com
      **![http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

            SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

          Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

          Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

        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/CAAJzpfmR4U_2i86ZG2yFsYNtMJx0m7chWmQd7QgKbODpEtyouA%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAJzpfmR4U_2i86ZG2yFsYNtMJx0m7chWmQd7QgKbODpEtyouA%40mail.gmail.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/E248A0C6-1198-45DA-9BB3-27CF232F6CA9%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/E248A0C6-1198-45DA-9BB3-27CF232F6CA9%40villagereach.org?utm_medium=email&utm_source=footer).

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


Sebastian Brudziński

              Senior Software Developer / Team Leader


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
openlmis-dev@googlegroups.compalbecki@soldevelo.com
Date:
To: sbrudzinski@soldevelo.com
Cc: openlmis-dev@googlegroups.com
Subject:

sbrudzinski@soldevelo.com

I’m late to the discussion but I agree, emergency requisitions should not be a new REST resource.

···

On Friday, February 9, 2018 at 2:41:12 AM UTC-8, Sebastian Brudziński wrote:

Thanks for the clarifications, Brandon.

  I don't think that supporting in-progress, emergency requisitions on the update day will be an issue. That is, if we agree that:

  1) the already initiated, emergency requisitions will have all the available products added

  2) only the ordering columns will be displayed for them (same as for any new, emergency requisitions)
  Based on the clarifications and comments, I'm leaning towards not making emergency requisitions its own rest resource / database model and I'm going to design the tickets with that in mind. If anyone has any issues with that, please let me know.

Best regards,

  Sebastian.
  On 08.02.2018 21:04, Brandon Bowersox-Johnson wrote:
      I discussed migration / backwards compatibility with Mary Jo, and here is a short summary of the minimum requirements from her and the Product Committee:

Must Have:

  •         Historical emergency requisitions can still be opened and viewed after this upgrade. (You can view and print all their columns; hopefully that is already part of their snapshot.)
    
  •         New requisitions initiated after this upgrade use the new business rules in OLMIS-3949.
    
  •         A warning in Release Notes/CHANGELOG tells implementers that Emergency Requisitions have a mandatory redesign/change.
    
  •         In-progress emergency requisitions at the time of this upgrade are not necessarily supported. (Mary Jo says it is acceptable for the Release Notes/CHANGELOG to tell Implementers they have to finish/approve all in-progress Emergency Requisitions before applying this software upgrade. PC [noted](https://openlmis.atlassian.net/wiki/spaces/OP/pages/199655438/PC+January+30+2018)
            this.)
    

Not Needed:

  •         In-progress emergency requisitions at the time of this upgrade could continue through submit/authorize/approve workflow. (Nice to have/optional.)
    
  •         Administrators could have a toggle in Program Settings to toggle Emergency Requisitions between old way and new way.
    

In the future , Emergency Requisitions will likely be expanded to have configurable templates. Administrators will eventually be able to toggle columns on or off and change template settings. I believe we want a lot of this business logic to be shared between Emergency Requisitions and Regular Requisitions. We want the ability to add new improvements that can apply to both Emergency and Regular without duplicating code.

      Here are my 2 cents about our approach based on this:
      (1) Having a toggle to switch between old and new way is not required, but I believe it is a safer technical way to implement this feature change (as a toggle) rather than a forced hard-coded change.
      (2) Because we still want lots of shared logic and shared features across Emergency and Regular Requisitions now and into the future, I suggest that Emergency Requisitions should not be a separate database model with separate REST resources. But the Dev Forum is a great place to discuss all this and I welcome other ideas.

-Brandon

From: openlmis-dev@googlegroups.com
on behalf of Paweł Albecki palbecki@soldevelo.com

          **Date:** Thursday, February 8, 2018 at 8:14 AM

          **To:**               Sebastian Brudziński <sbrudzinski@soldevelo.com>

          **Cc:**               OpenLMIS Dev <openlmis-dev@googlegroups.com>

          **Subject:**               Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign
            If we want to have backward compatibility, I think the easiest way would be to leave current requisitions resource as is and create new one for new redesigned emergency requisitions. We can add configuration setting to allow admins to switch between old way and new way. This wouldn't force us to                   requisition template validations nor database migration would be needed. But I can miss something important right now.
              On Thu, Feb 8, 2018 at 4:45 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com> wrote:
                  Agreed about the migrations.
                  I believe allowing emergency requisitions to have their own requisition template would only add to the complexity. We have a set of rules on which columns need to go together, which are required, etc. All of this would need to be different for emergency requisitions - we want less strict validations, like the ability to disable reporting at all - which is not possible with regular requisition template.
                  Is the old/new emergency requisition template toggle something that you see in scope for 3.3? This was never mentioned in [https://openlmis.atlassian.net/browse/OLMIS-3949](https://openlmis.atlassian.net/browse/OLMIS-3949) , rather a hard-coded approach of a few, selected columns was suggested. I believe keeping old emergency requisitions as-is (still displaying old columns) was not planned as well. If we want to have those additional options, we need to update and reestimate OLMIS-3949.
                  Best regards,

                  Sebastian.
                        On 08.02.2018 16:25, Brandon Bowersox-Johnson wrote:
                          Another consideration is migration of pre-existing emergency requisitions. We definitely need the existing Emergency Requisitions in running implementations (such as Malawi) to migrate once this update is applied.
                          Perhaps we should think about the new kind of Emergency Requisitions as just using a different Template that has different columns enabled/disabled. Previously we did not allow disabling some of those columns, so we could add a Requisition Template setting (that will act as a feature toggle) that will allow toggling off those previously-required fields and validations. This would allow admins to configure their Emergency Requisition template to use the new design (with fewer fields).
                          The old pre-existing Emergency Requisitions should continue to work. Emergency Requisitions already initiated and in progress should continue as is and their validations and calculations should work as they do today. Historical Emergency Requisitions should still be able to be viewed and have their calculations show correctly. In addition, if some programs wanted to keep using Emergency Requisitions with the old template, they should be allowed to do so. They would not be forced to change their template on the day of this upgrade. Instead, the admins could log in and toggle on the new Emergency Requisition template setting(s) at a time they choose, or roll it out program-by-program.
                          In summary, a “feature toggle” approach might help us ensure safe migration and back-wards compatibility of the data and configurations already in use in live implementations.

-Brandon

** From:** openlmis-dev@googlegroups.com
on behalf of Łukasz Lewczyński llewczynski@soldevelo.com

                              **Date:**                                   Thursday, February 8, 2018 at 7:18 AM

                              **To:** Sebastian Brudziński <sbrudzinski@soldevelo.com>

                              **Cc:** "openlmis-dev@googlegroups.com"
                            <openlmis-dev@googlegroups.com>

                              **Subject:**                                   Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign
                              I read some resources about DDD (not know where) and now I think that emergency requisition should not be treated as a new resource. Why? Regular, emergency and approve requisitions (because we also wanted to create a new resource for requisition in the approve status) are related with the same bounded context. Because of that this does not make sense to have several classes to represent one concept - the difference is only in status and/or emergency flag.
                              Also other problem is with class structure. Let's assume that we will have a BaseRequisition, RegularRequisition, EmergencyRequisition classes. Now if we decided to create ApprovedRequisition class we have to create two classes for regular and emergency requisitions. Of course we could try to design structure differently but I still think that there will be problem.
                                Other thought is that some problems with requisition could be related with that some code were copied from v2 with small changes, we had a small knowledge about the system, DDD etc. We could check the code after OpenLMIS 3.3 release and maybe it would be possible to clean it.
                              To make validations changes easier I think we could do those validations in the same way how they are done in the stock management service: one validator = one field check. With this approach it would be easier to test and understand what the given validator do.
                        **<img style="width:1.5104in;min-height:.3645in" src="https://lh3.googleusercontent.com/proxy/Kq7icsK3MEQjYLwBW84HwuYjQ8aFuyyirMOzt_ENZ5BgyyRVaFVgsbO-vnqZPEKtkcm1Gs2mKJSDSi59adej7wSt1KiO3u5QJa2SfrMvGRh8cyONHJScEXiljA=w5000-h5000" alt="http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png" width="145" border="0" height="35">

                              SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

                          [                                  Al. Zwycięstwa 96/98](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g)                                , 81-451, Gdynia, Poland

                            Phone:                                   +48 58 782 45 40 / Fax:                                   +48 58 782 45 41
                          --

                          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/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.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/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org?utm_medium=email&utm_source=footer).

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

** Sebastian Brudziński**

                      Senior Software Developer / Team Leader

                    sbrudzinski@soldevelo.com
              **<img style="width:1.5104in;min-height:.3645in" src="https://lh3.googleusercontent.com/proxy/Kq7icsK3MEQjYLwBW84HwuYjQ8aFuyyirMOzt_ENZ5BgyyRVaFVgsbO-vnqZPEKtkcm1Gs2mKJSDSi59adej7wSt1KiO3u5QJa2SfrMvGRh8cyONHJScEXiljA=w5000-h5000" alt="http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png" width="145" border="0" height="35">

                    SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

                [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)                        /98, 81-451, Gdynia, Poland

                                          Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
                --

                                      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/8dc4c484-3986-752b-4595-222294774f38%40soldevelo.com](https://groups.google.com/d/msgid/openlmis-dev/8dc4c484-3986-752b-4595-222294774f38%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ł Albecki**

                            Software Developer

                          palbecki@soldevelo.com
      **<img style="width:1.5104in;min-height:.3645in" src="https://lh3.googleusercontent.com/proxy/Kq7icsK3MEQjYLwBW84HwuYjQ8aFuyyirMOzt_ENZ5BgyyRVaFVgsbO-vnqZPEKtkcm1Gs2mKJSDSi59adej7wSt1KiO3u5QJa2SfrMvGRh8cyONHJScEXiljA=w5000-h5000" alt="http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png" width="145" border="0" height="35">

            SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

          Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

          Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

        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/CAAJzpfmR4U_2i86ZG2yFsYNtMJx0m7chWmQd7QgKbODpEtyouA%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAAJzpfmR4U_2i86ZG2yFsYNtMJx0m7chWmQd7QgKbODpEtyouA%40mail.gmail.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/E248A0C6-1198-45DA-9BB3-27CF232F6CA9%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/E248A0C6-1198-45DA-9BB3-27CF232F6CA9%40villagereach.org?utm_medium=email&utm_source=footer).

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


Sebastian Brudziński

              Senior Software Developer / Team Leader

     sbrudzinski@soldevelo.com


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

I’m okay with #1 and #2, as long as the CHANGELOG and Release Notes include that detail.

···

From: openlmis-dev@googlegroups.com on behalf of Sebastian Brudziński sbrudzinski@soldevelo.com

Date: Friday, February 9, 2018 at 2:41 AM

To:openlmis-dev@googlegroups.comopenlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign

Thanks for the clarifications, Brandon.

I don’t think that supporting in-progress, emergency requisitions on the update day will be an issue. That is, if we agree that:

  1. the already initiated, emergency requisitions will have all the available products added

  2. only the ordering columns will be displayed for them (same as for any new, emergency requisitions)

Based on the clarifications and comments, I’m leaning towards not making emergency requisitions its own rest resource / database model and I’m going to design the tickets with that in mind. If anyone has any issues with that, please let me know.

Best regards,

Sebastian.

On 08.02.2018 21:04, Brandon Bowersox-Johnson wrote:

I discussed migration / backwards compatibility with Mary Jo, and here is a short summary of the minimum requirements from her and the Product Committee:

Must Have:

  • Historical emergency requisitions can still be opened and viewed after this upgrade. (You can view and print all their columns; hopefully that is already part of their snapshot.)
  • New requisitions initiated after this upgrade use the new business rules in OLMIS-3949.
  • A warning in Release Notes/CHANGELOG tells implementers that Emergency Requisitions have a mandatory redesign/change.
  • In-progress emergency requisitions at the time of this upgrade are not necessarily supported. (Mary Jo says it is acceptable for the Release Notes/CHANGELOG to tell Implementers they have to finish/approve all in-progress Emergency Requisitions before applying this software upgrade. PC
    noted
    this.)

Not Needed:

  • In-progress emergency requisitions at the time of this upgrade could continue through submit/authorize/approve workflow. (Nice to have/optional.)
  • Administrators could have a toggle in Program Settings to toggle Emergency Requisitions between old way and new way.

In the future , Emergency Requisitions will likely be expanded to have configurable templates. Administrators will eventually be able to toggle columns on or off and change template settings. I believe we want a lot of this business logic to be shared between Emergency Requisitions and Regular Requisitions. We want the ability to add new improvements that can apply to both Emergency and Regular without duplicating code.

Here are my 2 cents about our approach based on this:

(1) Having a toggle to switch between old and new way is not required, but I believe it is a safer technical way to implement this feature change (as a toggle) rather than a forced hard-coded change.

(2) Because we still want lots of shared logic and shared features across Emergency and Regular Requisitions now and into the future, I suggest that Emergency Requisitions should not be a separate database model with separate REST resources. But the Dev Forum is a great place to discuss all this and I welcome other ideas.

-Brandon

From: openlmis-dev@googlegroups.com on behalf of Paweł Albecki palbecki@soldevelo.com

Date: Thursday, February 8, 2018 at 8:14 AM

To: Sebastian Brudziński sbrudzinski@soldevelo.com

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign

If we want to have backward compatibility, I think the easiest way would be to leave current requisitions resource as is and create new one for new redesigned emergency requisitions. We can add configuration setting to allow admins to switch between old way and new way. This wouldn’t force us to requisition template validations nor database migration would be needed. But I can miss something important right now.

On Thu, Feb 8, 2018 at 4:45 PM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Agreed about the migrations.

I believe allowing emergency requisitions to have their own requisition template would only add to the complexity. We have a set of rules on which columns need to go together, which are required, etc. All of this would need to be different for emergency requisitions - we want less strict validations, like the ability to disable reporting at all - which is not possible with regular requisition template.

Is the old/new emergency requisition template toggle something that you see in scope for 3.3? This was never mentioned in https://openlmis.atlassian.net/browse/OLMIS-3949 , rather a hard-coded approach of a few, selected columns was suggested. I believe keeping old emergency requisitions as-is (still displaying old columns) was not planned as well. If we want to have those additional options, we need to update and reestimate OLMIS-3949.

Best regards,

Sebastian.

On 08.02.2018 16:25, Brandon Bowersox-Johnson wrote:

Another consideration is migration of pre-existing emergency requisitions. We definitely need the existing Emergency Requisitions in running implementations (such as Malawi) to migrate once this update is applied.

Perhaps we should think about the new kind of Emergency Requisitions as just using a different Template that has different columns enabled/disabled. Previously we did not allow disabling some of those columns, so we could add a Requisition Template setting (that will act as a feature toggle) that will allow toggling off those previously-required fields and validations. This would allow admins to configure their Emergency Requisition template to use the new design (with fewer fields).

The old pre-existing Emergency Requisitions should continue to work. Emergency Requisitions already initiated and in progress should continue as is and their validations and calculations should work as they do today. Historical Emergency Requisitions should still be able to be viewed and have their calculations show correctly. In addition, if some programs wanted to keep using Emergency Requisitions with the old template, they should be allowed to do so. They would not be forced to change their template on the day of this upgrade. Instead, the admins could log in and toggle on the new Emergency Requisition template setting(s) at a time they choose, or roll it out program-by-program.

In summary, a “feature toggle” approach might help us ensure safe migration and back-wards compatibility of the data and configurations already in use in live implementations.

-Brandon

From: openlmis-dev@googlegroups.com on behalf of Łukasz Lewczyński llewczynski@soldevelo.com

Date: Thursday, February 8, 2018 at 7:18 AM

To: Sebastian Brudziński sbrudzinski@soldevelo.com

Cc:openlmis-dev@googlegroups.com
openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Model & API changes for Emergency Requisition redesign

I read some resources about DDD (not know where) and now I think that emergency requisition should not be treated as a new resource. Why? Regular, emergency and approve requisitions (because we also wanted to create a new resource for requisition in the approve status) are related with the same bounded context. Because of that this does not make sense to have several classes to represent one concept - the difference is only in status and/or emergency flag.

Also other problem is with class structure. Let’s assume that we will have a BaseRequisition, RegularRequisition, EmergencyRequisition classes. Now if we decided to create ApprovedRequisition class we have to create two classes for regular and emergency requisitions. Of course we could try to design structure differently but I still think that there will be problem.

Other thought is that some problems with requisition could be related with that some code were copied from v2 with small changes, we had a small knowledge about the system, DDD etc. We could check the code after OpenLMIS 3.3 release and maybe it would be possible to clean it.

To make validations changes easier I think we could do those validations in the same way how they are done in the stock management service: one validator = one field check. With this approach it would be easier to test and understand what the given validator do.

**ttp://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

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/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.com
.

For more options, visit
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/6578C431-1CD3-48D7-B3CE-203869CFC83C%40villagereach.org
.

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

Sebastian Brudziński

Senior Software Developer / Team Leader

sbrudzinski@soldevelo.com

**ttp://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

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/8dc4c484-3986-752b-4595-222294774f38%40soldevelo.com
.

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

Paweł Albecki

Software Developer

palbecki@soldevelo.com

**ttp://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

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/CAAJzpfmR4U_2i86ZG2yFsYNtMJx0m7chWmQd7QgKbODpEtyouA%40mail.gmail.com
.

For more options, visit 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/E248A0C6-1198-45DA-9BB3-27CF232F6CA9%40villagereach.org
.

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

Sebastian Brudziński

Senior Software Developer / Team Leader

sbrudzinski@soldevelo.com

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

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/a9ef0e97-7910-afd7-03e3-0a16042060a5%40soldevelo.com
.

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