allow other constraint to be filled

[wangf1122]

The current validation doesn't allow this other constraint field to be filled if the user didn't select "other restriction" for Access Constraint field or User Constraint field.

This pull request removes such barrier. Other validation will still stay (i.e. check other constraint's emptiness if the user select "Other restriction" for Access Constraint field or User Constraint field.)

[ianwallen]

@wangf1122 Could you explain the issue. - Based on my testing I don't see any issue.

The screenshot that you posted will be invalid because you did select other restriction for use constraint or access constraint Without your change, I can add other constraint using the following sample.

[wangf1122]

@ianwallen @josegar74

We had discussed this issue during last community meeting session. The issue is this field doesn't allow any input if the user DOES NOT select "other restriction". So the error text is not so clear. I will ask the technical writer to compose another text and update the error itself.

[wangf1122]

@josegar74 @ianwallen

There is a logic flaw in the current logic in this area. As we discussed from the last HNAP discussion session, if the user not select "other restriction" but decide to put some text to other constraint field. We should see error message saying this field needs to be empty. But it is pointed to the original none empty message. I added such scenario and message to handle this case. Here is the test result

1) If Access Constraints or Use Constraints field has no "other restriction", the error will be this

2) If Access Constraints or Use Constraints field has "other restriction" but the other constraint is empty, then error will be 👍

The code is updated and you can do some general test based on this branch of code. The text update also went thru our technical writer

[josegar74]

According to the HNAP 2.3.1 specification:

• accessConstraints (5.4.2.2): For data assessed and approved for release under the Open Government Licence - Canada accessConstraints shall be mandatory and conform to "licence; licence"

• useConstraints (5.4.2.3): For data assessed and approved for release under the Open Government Licence - Canada useConstraints shall be mandatory and conform to “licence; licence"

• otherConstraints: otherConstraints shall be provided where accessConstraints (5.4.2.2) or useConstraints (5.4.2.3) is set to "otherRestrictions."

---

From the previous rules, I understand that otherConstraints is mandatory when accessConstraints or useConstraints are set to "otherRestrictions". In other cases, can be provided optionally.

The original validation, allowed only a value in otherConstraints, if accessConstraints or useConstraints are set to "otherRestrictions", reporting an error in other cases. This seems not correct according to the previous rules.

---

The pull request keeps the original validation, but provides clear messages. Please @ianwallen and @wangf1122 verify if my previous understanding is correct based on the specification text. If so I think the validation for OtherConstraintsNoteEmpty has to be removed.

In case that OtherConstraintsNoteEmpty should be kept, I noticed this issue with the validation (empty message for the multilingual validation):

[ianwallen]

From the previous rules, I understand that otherConstraints is mandatory when accessConstraints or useConstraints are set to "otherRestrictions". In other cases, can be provided optionally.

I agree that there is no specification indicating that otherConstraints cannot be used when accessConstraints or useConstraints are not set to otherRestrictions. So it does seem like it can be optional in this case.

My only concern is how FGP currently handles this situation. I just tested FGP and it fails with this use case so if we implement this change, then FGP also has to implement the change as well.

@bo-lu - could you provide your comments on this. Thank you