Fails silently when creating/editing relationships with non-Person names

josephbate · October 19, 2023, 10:08am

hello Folks this week a claimed this ticket:[RA-1847] Fails silently when creating/editing relationships with non-Person names - OpenMRS Issues in relation to the talk post; Fails silently when creating/editing relationships with non-Person names (RA-1847)

in my finding the relationships fail to display for they are not registered in the data base, as you brower the data base under person, person_name and relationship don’t keep any records so will not remitt any either think this may be caused by the angular PersonService not picking up any persons registered in the relationship fields and there is no exception to catch the error

if there is any more information i can gather to simplify my work i will be glad

josephbate · October 19, 2023, 10:20am

i have created a relationship in the data base to see if it can be diplayed and it is successfull seems the problem is storing persons in the data base is what is causing these issues

tendomart · October 19, 2023, 10:29am

Share your database screenshots please.

josephbate · October 19, 2023, 10:46am

josephbate · October 19, 2023, 10:50am

as you can see it displays so i think the posting is what has an issue in summary the relationships are not save in the data base so it only happens in the front and but never in the backend

josephbate · October 28, 2023, 7:28pm

hello folks an update on this issue

i have spent some time trying to look for options on how to reslove this issue this are my findings;

this relaitonship field was designed to created relationships between the patient in question and the persions already existing in the database, that is to say the personRelationship.js and gsp are intended to create realtionships between the patient and an already exting person_name in the database. this explains why theres no display of the entended relatinships as registered by the user on the patient dashboard
Since to create a relationship we need a patient with a person_name already in existance, in order to create desired relatonships as explained in the ticket description we then must register first the sugested persons in and then relate them to the patient in the raltionship field. however the only way to create a new person is through the advance administration for there is no feature on the interface or dashboard that can carry out such a task
i suggest we change this issue from a bug to an implementation, so that we add an implementation in the relationship field that retrieves the entries and of course on the person name add birthdate and gender so as to create the person in the database first then proceed with the relationship process or create a feature on the ui dashboard that allows us to create persons to the data base to use them for relationships

either way i think this call for modification than just fixing a bug but i am waiting for more suggetiion or correction on this issue

cc. luis Oliveira Ian Bacher Ryan McCauley Daniel Kayiwa @mozzy

ruhanga · November 13, 2023, 1:06pm

Hi @josephbate, I think this issue (RA-1847) should have gotten resolved/fixed by this PR: UHM-7476, keep track of the value selected from the search results by cioan · Pull Request #134 · openmrs/openmrs-module-registrationapp · GitHub. Could you confirm this by testing with the latest Reg App Module?

Pinging in @cioan to confirm.

josephbate · November 14, 2023, 1:25pm

thank you @ruhanga let me look into that

cioan · November 16, 2023, 3:27pm

Thanks @ruhanga ! We actually ended up building a new person relationship widget that allows us to configure it with specific relationship types:

github.com

openmrs/openmrs-module-registrationapp/blob/master/omod/src/main/webapp/fragments/field/registerPersonRelationship.gsp

<%
    ui.includeJavascript("registrationapp", "field/registerPersonRelationship.js")
    ui.includeCss("registrationapp","registerPatient.css")

    def multipleValues = config.multipleValues ? config.multipleValues : false
%>

<div id="${ config.id }-container">
    <div id="${ config.id }-fields-div">
        <p>
            <input type="hidden" id="${ config.id }-selected_persons" name="selected_persons" data-display-value=""/>
        </p>
        <p>
            <input type="hidden" id="${ config.id }-relationship_type" name="relationship_type" class="rel_type" value="" data-display-value="-"/>
        </p>
        <p>
            <label for="${ config.id }-field">
                ${ config.label } <% if (config.classes && config.classes.join(' ').contains("required")) { %><span>(${ ui.message("emr.formValidation.messages.requiredField.label") })</span><% } %>
            </label>

This file has been truncated. show original

Here is an example on how this new widget could be configured:

github.com

PIH/openmrs-config-pihsl/blob/master/configuration/pih/pih-config-sierraLeone.json#L48


      
            "personAttributeTypes" : {
              "First Name of Mother": "3",
              "Telephone Number": "20"
            }
          },
          "demographics": {
            "mothersName": {
              "required": false
            }
          },
          "relationships" : [
            {
              "id": "mother",
              "label": "registration.patient.mother.label",
              "relationshipType": "9a4b3b84-8a9f-11e8-9a94-a6cf71072f73",
              "relationshipDirection": "A",
              "gender": "F",
              "multipleValues": false,
              "required": false
            },
            {

And here is the UI for the above configuration:

josephbate · November 16, 2023, 4:17pm

so you mean to say this issue was fixed its no longer neccesary @cioan

cioan · November 21, 2023, 2:16pm

@josephbate , we have written a new widget which addresses the issue you described above, and we are using the new registerPersonRelationship widget in the PIH EMR app. But we did not replace the old widget, personRelationship, in the OpenMRS ref app. We are not sure how other implementations are using this old personRelationship widget which has been around for a long time.

josephbate · November 21, 2023, 3:33pm

i think with O3 in place we might not need to even make changes, widgets will be shared across platforms yours maybe the solution to this issue for the community

CC: @ibacher