@emmajclegg
Following our discussion, I've reviewed the module for completeness calculation. For us to implement new completion rules that reflect the recent changes of #1553 , the actual changes in the back-end would be 1 liner. However we'd need to update some of the existing unit tests and also perform some degree of manual testing.

cc: @BibhaT

For us to implement new completion rules that reflect the recent changes of #1553 , the actual changes in the back-end would be 1 liner. However we'd need to update some of the existing unit tests and also perform some degree of manual testing.

Ok thanks @PG-Momik. This sounds sensible to do in that case.

In terms of new work to pick up when you can this month, I've ordered the "proposed user story/task" Github list in rough order of priority, so this issue doesn't need to be done straight away. #1596, for example, is at the top as it's causing users to publish data with errors, so that issue would be higher impact to work on.

@emmajclegg
As mentioned in the meeting today, here are the list of elements and queries concerning them:

1. Conditions

   • In IATI Publisher, Conditions is considered complete when:
   • Attached = false
   • OR Attached = true + required fields of the optional condition subelement

2. Contact info

   • Should the completeness logic for contact info be the same as the recent changes made for location element(where location would be complete if the reference attribute is filled or any of the optional subelement is filled)
   • OR should contact info be considered complete if the type attribute is filled + any one of the optional sub element is filled.

3. Planned disbursement

   • Currently planned disbursement is considered to complete when all its required fields + planned_end is filled.
   • Should planned end be changed from optional to required
   • OR should the planned end not affect complete status.

cc: @BibhaT

Thanks for flagging these @PG-Momik - they do seem like edge cases.

1. Conditions

• In IATI Publisher, Conditions is considered complete when:
• Attached = false
• OR Attached = true + required fields of the optional condition subelement

This makes sense^^. According to the IATI schema, it looks fine to just enter "Attached = true" without the condition sub-element. But for data interpretation, I think it's expected that the condition sub-element be populated in this scenario.

2. Contact info
Similar to conditions, the IATI schema won't return an error if only the type attribute is populated, but this doesn't make much sense from an interpretation perspective. I recommend we do this:

OR should contact info be considered complete if the type attribute is filled + any one of the optional sub element is filled.

3. Planned disbursement
Having, checked the schema again, period-end is definitely an optional field. This does make sense as planned disbursements can be for a single specific date, rather than covering a period.

Therefore - the period-end date should not affect the completion status.

4. (Organisation Data) - Recipient Region Budget

Relatedly, I noticed that the recipient-region sub-element in this data entry form is marked "optional" when it should be mandatory. Can we change that to make sure the data completeness logic is correct here?

Any questions, let me know.

@emmajclegg

Relatedly, I noticed that the recipient-region sub-element in this data entry fo....

Recipient region has been changed to a non-optional subelement. However, none of the fields within this sub-element are mandatory in the current implementation; they are also optional in the schema (Recipient region in schema)

This does not impact the current changes, as the recipient region budget will be complete if the required fields within all the non-optional sub-elements are populated. Nonetheless, I wanted to flag this in case it needs to be addressed differently.

cc: @BibhaT @Sanam-07

@Sanam-07 The testables for this are:

Elements should be complete when required fields in the non-optional subelement are filled. This applies for form level as well as all the imports.

Recipient region has been changed to a non-optional subelement. However, none of the fields within this sub-element are mandatory in the current implementation; they are also optional in the schema (Recipient region in schema)

This does not impact the current changes, as the recipient region budget will be complete if the required fields within all the non-optional sub-elements are populated. Nonetheless, I wanted to flag this in case it needs to be addressed differently.

Thanks @PG-Momik . I agree with your interpretation of the schema here and think this is fine, if I'm understanding correctly. The main thing would be changing the labelling of the "Recipient Region" element to mandatory in the data entry form as users really should be completing it. I'm suggesting no special alterations to the data completeness logic though.

Any questions, let me know.

For info - this newly raised issue related to recipient-country completeness (#1634) may make sense to look at in the context of this issue.

@PG-Momik Based on todays internal discussion, I have moved the bugs findings in #1637.

Hi @emmajclegg, I have some questions regarding this issue epecially on these 2 elements:

1. Contact info

   OR should contact info be considered complete if the type attribute is filled + any one of the optional sub element is filled.

Since we'll be implementing this.
Should a required asterisk (*) be shown on the type field ?

2. Sector
   In a case where there are multiple sectors (say 2) but none of the sectors have percentage fields are not filled.
   Sector should be incomplete?

We think 'Yes' (for both of the questions raised above) and we've implemented the necessary changes accordingly and is being tested. Do let us know if any of the changes mentioned above do not seem correct.

We're also considering implementing a form validation for when there are multiple sector and both of the percentage field are empty, since 2 percentage fields cannot be 100%.

cc: @Sanam-07

@PG-Momik - I agree yes to both of those questions.

...since 2 percentage fields cannot be 100%.

I'm not sure I understand this ^^ but form validation for sector, similar to what there is for recipient country / region likely makes sense.

@emmajclegg Regarding tag

1. In the publisher, tag -> vocabulary is not a required field for completion . It does not have red *.
   

2. IATI validator throws a critical error when validating an xml that doesnt have 'vocabulary' attribute in the tag element
   

3. The IATI standard states that vocabulary is a required field.

Therefore we've currently changed tag vocabulary to be a required field for completion. Do let us know if the change mentioned above do not seem correct.

cc: @Sanam-07 @BibhaT

Hi @PG-Momik - yes, good spot. I agree vocabulary should be a required field for the tag element.

Hi @emmajclegg,

Update on the Issue:

Requirement Summary:

1. Completeness Criteria: An element is considered complete when all mandatory fields (marked with a red *) are filled.
2. Optional Sub-elements: Mandatory fields within optional sub-elements do not affect the parent element's completeness, except for specific cases (e.g., location, RR, RC, contact info).

Current Progress:

I’m currently testing both form inputs and imports for create and update scenarios. This task is quite time-intensive, with approximately effort of 30 hours spent. The testing process involves:

1. Importing datasets element by element. (elements besides result, transaction , planned-disbursement, budget have been covered for form and XML level)
2. Confirming element completeness. (elements besides result, transaction , planned-disbursement, budget have been covered for form and XML level)
3. Changing data and re-importing.
4. Reconfirming completeness.