I've done some research and I could only find one thing that would break after we implement Orderables edit. Requisition line item uses the ProgramOrderable to actually set the price per pack of itself. If we modify the ProgramsOrderable price per pack after the requisition initialization it won't be reflected in the requisition line item.
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/6ce639ba-ac8e-48df-a201-3f3d4455316a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FC141E2F-3489-42F6-B0AB-1C5577AEC431%40villagereach.org.
Hi,
just a quick comment, Nikodem.
When updating an orderable to remove one of the program-orderables association, the UI currently fails to load all requisitions that were initiated at the time the removed program-orderable was still supported (It hangs at the step that tries to find correct program on the program-orderables list). This is one of the major thing that breaks when editing an Orderable at the moment. Versioning of the Orderables (read/vread) would potentially fix this problem as well as made sure the orderables are immute at the initiate (by additionally storing and using the version of an orderable).
Best regards,
Sebastian.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/B61C618B-A25C-4F3B-89FE-909E3D7C8104%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
Sebastian
Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
To post to this group, send email to ...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/6ce639ba-ac8e-48df-a201-3f3d4455316a%40googlegroups.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 ...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FC141E2F-3489-42F6-B0AB-1C5577AEC431%40villagereach.org.
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/B61C618B-A25C-4F3B-89FE-909E3D7C8104%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
--
Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
Hi All,
The conversation quickly moved to ‘versioning the orderables’. There are cool ideas to do that using FHIR read and vread in the ticket*.
The ticket* makes the point that the ability to edit and update Orderables used to work in v3! Of course we did not have ‘versioning of the Orderables’ or FHIR support to do that.
* https://openlmis.atlassian.net/browse/OLMIS-3167
So is there a simpler way to go back and get that feature working again? Is that a smaller baby step we can take to fix the broken functionality before we take the larger step to versioning and FHIR?
The versioning and FHIR work is probably too large to introduce before 3.2.1 (release is only 3 weeks away).
-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/8A6AB6B9-DB2D-4586-9C66-738877F05665%40villagereach.org.
Josh, thanks for that. The explanation totally makes sense to me. I agree that we should proceed with planning this right and doing the work after 3.2.1.
-Brandon
Thanks for reviving this discussion and compiling the summary,
Nikodem. I think it's important that we start making progress with
the orderables edit while we are still far from the next release,
since the impact of this change will be huge.
My comment on the "identity", under "what should be editable" and
"the concern" would be that it is not something that we (as a core
product) need or should worry about too much. No matter how hard
we try, it's ultimately up to the implementer to ensure that the
edits they are making, to any instance in the system, are not
causing that instance to represent a different thing. If we wanted
to enforce that on our end, we would pretty much need to disable
the ability to edit most of the properties for all our entities
(eg. a name, a code...).
You are proposing that we make the product code immutable. I'd
personally tend towards giving more, rather than less freedom in
the edits. While the code is something that generally shouldn't
change, we already had an issue with an incorrect facility code
assigned in Malawi. I believe this will/should be the only case
where a code of any instance is edited, but it's good to have that
option if necessary, especially that editing the code doesn't have
any impact on the system as far as I know (references are by the
id). It would be great to hear what other people think though.
+1 from me for "versioning" as our strategy to edit orderables. I
think it's the cleanest solution out of the proposed ones. It can
also be implemented incrementally, without affecting other
services (support for versioning first, migrating services
one-by-one to use the orderable version second).
Best regards,
Sebastian.
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/e423e6a1-d69c-4348-93de-fa5d8a619129%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sebastian
Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
Of the 3 proposed approaches, Versioning is probably also the one I would also lean towards if we want to make an Orderable editable. I agree with Sebastian that implementers should be allowed to change the code and name. In the case of a typo in the code, it is fine to change, and the rest of our software references the UUID and not the code so I believe it does not break anything. Same with changing an orderable name.
The 4 open questions about Versioning still need some proposals, so I have a few responses to those:
• “Should we use GUUID or int to track version?”
GUUID sounds more robust to me and just as easy. The newer version could store a reference to the previous version.
• “Which changes should spawn new version?”
I think any changes should always spawn a new version. That is a safer and simpler solution rather than having a complex logic where certain field edits do NOT change the version number while other field edits DO change the version number. We might as well always make each edit a new version. Any big downsides to that?
• “Where should we store the version in object referencing a specific version of the orderable?”
We need to be clear on whether the other parts of OpenLMIS that reference an Orderable are also storing a reference to a specific version of the Orderable. To take one specific example, I think the Requisition object might want to store a specific version reference for each orderable. At the time of requisition initiation, it builds the Requisition using the latest version of each Orderable from the FTAP list. It also saves that version used. Then, if an Orderable changes over time (maybe code, maybe name), if I view an old requisition from 5 years ago, the on-screen view will show me the name and code from the exact version that was used back then.
I also have a few other points:
• We will need guidance or hard rules on which Orderable properties are NOT allowed to be mutable. Can anyone name an example?
• For GS1 Trade Item-based Orderables, what are the GS1 GDSN rules about mutability? If Tylenol ever changes its PackSize, its UPC Barcode or changes name to “Tylenol Zero Sugar” must they issue a whole new Trade Item?
• For UNSPSC/GPC/Commodity-Type-based Orderables, do those systems ever change the name of something (like how “Autism” was changed to “Autism Spectrum Disorder” in the DSM-5)?
• Finally, for now I believe we are just talking about making an individual Orderable editable. As a separate issue (later) we will also talk about how the FTAP list should be editable. But that’s a separate topic for later. (Correct me if I’m wrong.)
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/0fc3491d-3734-3bee-b1ac-6d852517ead3%40soldevelo.com.
A few responses to Brandon's other points:
For GS1 Trade Item-based Orderables, what are the GS1 GDSN rules about mutability? If Tylenol ever changes its PackSize, its UPC Barcode or changes name to “Tylenol Zero Sugar” must they issue a whole new Trade Item?
For UNSPSC/GPC/Commodity-Type-
based Orderables, do those systems ever change the name of something (like how “Autism” was changed to “Autism Spectrum Disorder” in the DSM-5)?
Finally, for now I believe we are just talking about making an individual Orderable editable. As a separate issue (later) we will also talk about how the FTAP list should be editable. But that’s a separate topic for later. (Correct me if I’m wrong.)
Best,
Josh
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/e423e6a1-d69c-4348-93de-fa5d8a619129%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sebastian Brudziński
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 view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/4bec1537-73d8-4333-a9ac-55f71047b6f0%40googlegroups.com.
1. If I modified the product name (because I found a typo) should I see this change on the product grid? In my opinion yes because this change does not modify my product.
2. If I modified the product price should I see this change on the product grid? I think no because this change modifies my budget for the given period. Also if this change will be visible, the legacy data will be corrupted.
If we assume that each change creates a new version of product, how much new entries will be in database? In the worst scenario I can modify a single property, save the product, modify the next property, save it and so on.This could create a lot of rows in table.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wP-4UJ4SbrOi0f0FZVs7zHm7OQPsd8QZQV4KDGOVTWSw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wP-4UJ4SbrOi0f0FZVs7zHm7OQPsd8QZQV4KDGOVTWSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wdzsZdQ%2BHjAFBQgat-RPyv6CCXb1QCuc03r5GkCEtihQ%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVKxLPxwYBrCz5_n%3DuHopw5MYsuBxq2m5A0twX81GfJYw%40mail.gmail.com.
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/e423e6a1-d69c-4348-93de-fa5d8a619129%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sebastian Brudziński
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/0fc3491d-3734-3bee-b1ac-6d852517ead3%40soldevelo.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/4bec1537-73d8-4333-a9ac-55f71047b6f0%40googlegroups.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/CAAdp53wP-4UJ4SbrOi0f0FZVs7zHm7OQPsd8QZQV4KDGOVTWSw%40mail.gmail.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/CAAdp53wdzsZdQ%2BHjAFBQgat-RPyv6CCXb1QCuc03r5GkCEtihQ%40mail.gmail.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/CAGOM9mVKxLPxwYBrCz5_n%3DuHopw5MYsuBxq2m5A0twX81GfJYw%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/C2A02D3A-7B97-4AB3-9E81-C941B2C2B62B%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.