Model & API changes for Emergency Requisition redesign
Sebastian Brudziński
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
sbrud...@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
Łukasz Lewczyński
Brandon Bowersox-Johnson
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
--
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/CAAdp53y_Jr2%3DZrc6V99-4uv%3D%2Bt5XxvGP8UqeM_UVDQ3WNnpa1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Sebastian Brudziński
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.
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
sbrud...@soldevelo.com
Paweł Albecki
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 openlm...@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 openlm...@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
sbrud...@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 openlm...@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.
Brandon Bowersox-Johnson
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: <openlm...@googlegroups.com> on behalf of Paweł Albecki <palb...@soldevelo.com>
Date: Thursday, February 8, 2018 at 8:14 AM
To: Sebastian Brudziński <sbrud...@soldevelo.com>
Cc: OpenLMIS Dev <openlm...@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 <sbrud...@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: <openlm...@googlegroups.com> on behalf of Łukasz Lewczyński <llewc...@soldevelo.com>
Date: Thursday, February 8, 2018 at 7:18 AM
To: Sebastian Brudziński <sbrud...@soldevelo.com>
Cc: "openlm...@googlegroups.com" <openlm...@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...@googlegroups.com.
To post to this group, send email to
To view this discussion on the web visit
--
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
To view this discussion on the web visit
--
Sebastian Brudziński
Senior Software Developer / Team Leader
sbrud...@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...@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/8dc4c484-3986-752b-4595-222294774f38%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
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...@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/CAAJzpfmR4U_2i86ZG2yFsYNtMJx0m7chWmQd7QgKbODpEtyouA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Sebastian Brudziński
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.
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
sbrud...@soldevelo.com
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Josh Zamor
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
To view this discussion on the web visit
--
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
To view this discussion on the web visit
--
Sebastian Brudziński
Senior Software Developer / Team Leader
sbrud...@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 openlm...@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.
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
To view this discussion on the web visit
--
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 openlm...@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
sbrud...@soldevelo.com
Brandon Bowersox-Johnson
I’m okay with #1 and #2, as long as the CHANGELOG and Release Notes include that detail.
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...@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/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...@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/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
sbrud...@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...@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/8dc4c484-3986-752b-4595-222294774f38%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
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...@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/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...@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/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
sbrud...@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...@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/a9ef0e97-7910-afd7-03e3-0a16042060a5%40soldevelo.com.