Friendly structured report

[Wambere]

IMPORTANT: Where possible all PRs must be linked to a Github issue

Fixes #263

Engineer Checklist

• I have run ./gradlew spotlessApply to check my code follows the project's style guide
• I have built and run the efsity jar to verify my change fixes the issue and/or does not break the application

[Wambere]

Examples of what the results looks like:

• For users, since we actually post these one by one, we get results for each. Broken down in to which part/task was being attempted in the whole creation process, which row in your csv (the actual row, not the row number), and the error/reason

Command: python3 main.py --csv_file csv/users.csv --resource_type users --log_level info --report_response true

============================================================
============================================================
{
    "status": "Failed",
    "totalRecords": 2,
    "processedRecords": 0,
    "errorDetails": [
        {
            "task": "Create user",
            "row": "['Jane', 'Doe', 'janey', '[email protected]', '', 'Practitioner', 'true', 'a715b562-27f2-432a-b1ba-e57db35e0f93', 'test', 'demo', 'pa$$word']",
            "error": "{\"errorMessage\":\"User exists with same username\"}"
        },
        {
            "task": "Confirm Practitioner",
            "row": "['Jane', 'Doe', 'janey', '[email protected]', '', 'Practitioner', 'true', 'a715b562-27f2-432a-b1ba-e57db35e0f93', 'test', 'demo', 'pa$$word']",
            "error": "User janey is linked to 2 Practitioner(s)"
        },
        {
            "task": "Create user",
            "row": "['Jenn', 'Doe', 'jenn', '[email protected]', '99d54e3c-c26f-4500-a7f9-3f4cb788673f', 'Supervisor', 'false', 'a715b562-27f2-432a-b1ba-e57db35e0f93', 'test', 'demo', 'pa$$word']",
            "error": "{\"errorMessage\":\"User exists with same username\"}"
        }
    ]
}
============================================================
============================================================

• For pretty much everything else, because these are bulk uploads, we only get one error back which has info pointing to which row could be the issue, but not the actual row number. Again the processed records will usually be 0 since if one fails they all fail

Command: python3 main.py --csv_file csv/locations/locations_full.csv --resource_type locations --log_level info --report_response true

============================================================
============================================================
{
    "status": "Failed",
    "totalRecords": 3,
    "processedRecords": 0,
    "failedRecords": 1,
    "errorDetails": [
        {
            "severity": "error",
            "diagnostics": "HAPI-0550: HAPI-0550: HAPI-0989: Trying to update Location/6c821162-0436-5830-9b4e-ea49027e0a7d/_history/1 but this is not the current version"
        }
    ]
}
============================================================
============================================================

[peterMuriuki]

Nooice!!, my cents:

For users, since we actually post these one by one, we get results for each. Broken down in to which part/task was being attempted in the whole creation process, which row in your csv (the actual row, not the row number)

Regarding the rowNumber, I will let consultations with the pms guide if this meets the ux needs for identifying which record needs to change, this could happen in QA maybe. cc @dubdabasoduba @AnnieMungai

For pretty much everything else

Would update action yield a different response?. i.e. for instances where an error happens during secondary requests that are needed to inform on how the final transaction payload is built.

Also, a minor request, to standardize the errorDetails.[x] section, have same fields, some can be optional. An alternative is to add a type field so that its easier to identify how to parse the error.