Requisition template assumptions

[Łukasz Lewczyński]

Hi,

While I was preparing Malawi for the OpenLMIS 3.4 release I noticed that there is no way to initiate a requisition or view existing requisitions in the system. I checked and found out that the UI assumes that the new column which was added in OLMIS-4966 is always in the requisition template. In Malawi, this column does not exist in any template so the UI throws an error.

At first, we wanted to update the UI so it would stop assuming that the column is always in the template but after a short discussion at the problem, we decided that from now each requisition template should always have all available columns. It means if in the future we would need to add a new column we would need to remember to add the column to existing templates.

The main reason why we decided to do this in this particular way is that columns have some relations to each other, especially when we talk about calculated columns and it would add more complexity to the code because we would need to check at first if a column is in the template.

Furthermore, if a new defined column would not be added to existing templates it would be extremely difficult to add the column later because currently, this is possible only by API and we need to know about the column beforehand.

Another thing is that a requisition template created by the UI contains all available columns and if anyone would like to use the API he/she need to know exactly what to put into a request.

What are your opinions on this topic? Do you have any concerns? Do you feel like other approaches would be better?

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@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

[Chongsun Ahn]

Hey all,

So I had advocated this decision on making this assumption during our meeting yesterday when deciding what to do about the showstopper bug found (OLMIS-5148). Originally this assumption made the most sense to me, because I had thought we had been doing this in our migrations. However, I see that we have not been enforcing this requirement, but rather have been checking in the UI if columns exist or not. As a result, we are not going to make this assumption and add new available columns to all templates. Rather, we will make the UI check to see if the column exists in the template before making calculations using it.

However, there is still an obstacle of admins being able to assign new columns to existing templates. We will need to address that at some point, once implementations will want to use them in new releases.

Shalom,
Chongsun
​
-- ​
There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536   CELL: 1.206.910.0973   FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook, Twitter and our Blog

--
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/CAAdp53zkPh8S9JmKiFdh2%2B-yiN1%3Dndmi7Bqw6vmqMbTGWMA_qA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.