search

medic / cht-user-management

GNU Affero General Public License v3.0
3 stars 1 forks source link

CHP replacements will fail if areas under the relevant CHU don't have the required facility/chu codes #113

Open freddieptf opened 3 months ago

freddieptf commented 3 months ago

Since we don't pick the specific CHP area we're replacing when getting the facility/chu codes in https://github.com/medic/cht-user-management/blob/79527c9ad2f93c81e910b6b92a74a10350ec0958/src/config/chis-ke/gross.ts#L34, a user could add facilty/chu codes to the area they're replacing and still get a "missing facilty/chu code" error https://github.com/medic/cht-user-management/blob/79527c9ad2f93c81e910b6b92a74a10350ec0958/src/config/chis-ke/gross.ts#L24-L28

kennsippell commented 3 months ago

Hey @freddieptf I'm interested in what you think the fix should be here.

I find this all very awkward because the CHU information is directly on the CHPs. I still don't totally get all the reasons why we are doing that; if you can explain it, I'd love to know! I know at one point there was an outbound push integration for Tibabu, but I'm unclear on the state of that. Can we drop this requirement in eCHIS since we're doing integrations using OpenHIE and it won't require it?

You say above

a user could add facilty/chu codes to the area they're replacing and still get a "missing facilty/chu code" error

But I'd argue that you should be adding that information onto the CHU directly? not the CHP? Is that incorrect?

I've done some work over in https://github.com/moh-kenya/config-echis-2.0/pull/1924 to make changes to the eCHIS contact forms to make it possible to directly edit this on the CHU. Notably, you can directly edit the facility info on the CHU and when you make CHP Areas the facility code is automatically copied down.

I'm wondering what you think we should do here in cht-user-management?

Curious to hear your thoughts.

freddieptf commented 3 months ago

I find this all very awkward because the CHU information is directly on the CHPs. I still don't totally get all the reasons why we are doing that; if you can explain it, I'd love to know!

Currently most forms use the chu code present on the CHP Area. There's a data group on some forms which gets pushed to the integration service via outbound and it uses the chu code and name on the CHP area. We'd have to edit these forms to make use of the chu code available on the CHU before we're able to do things the right way.

Should we stop storing this duplicate information on the CHP Area? (info doesn't matter at all)

Yes, but we'd need to make some changes on the forms that depend on the info first

Should we look at a specific sibling instead of just one random one?

Ideally we should be looking at the place the user is trying to do a replacement for. This way a user can make sense of the error shown on the UI and fix it themselves.

freddieptf commented 3 months ago

@kennsippell Now that i look at it abit more, this was probably done because we can't access the CHU in the form input group when the user is a CHP so this fields had to be duplicated downwards to the CHP Area. Does that make sense?

kennsippell commented 3 months ago

Can you confirm if you're talking about the eCHIS App forms or the cht-user-management implementation? I think you're talking about eCHIS app forms implementation.

You can access any/all data on the CHU by using a Contact Selector in the form. Shouldn't be a problem...

kennsippell commented 3 months ago

Maybe that isn't possible actually... since the CHU doc isn't on the CHP device :(

kennsippell commented 1 month ago

Here is a video explaining how users can resolve this today with the simplified eCHIS contact forms. https://www.loom.com/share/80e130733d094e4a829bdfe063d8b1e6. It'd be great to avoid this error entirely via some of the things discussed in this ticket; but I think this is a "not that terrible" experience with the new forms.