Use of "unassignable" setup codes

wbrowa

The handling of "unassignable" setup codes on the Partner Edit Screen was raising some discussions as it is not consistent across OpenPetra and not handled in an ideal way.

Let's take the Passport Details section as an example but this applies to all other screens in the Individual Data Section:
The codes for "unassignable" Passport Types currently appear in the combobox on that screen. They need to as it is important to show values for old records that may use values that were assignable in the past. It would be nice if we could display values in that field that don't exist in the drop down list but I assume this is currently not possible. When such an unassignable value is selected then the user currently sees a warning (not an error) when he leaves the field or selects a different record. However, it is still possible to save records that use "unassignable" values. If we would make it a validation error instead of a warning then the user would not be able to go to a different row in the data grid as validation does not allow that when an error occurs.

Also, when the user edited a record with an unassignable code and went straight to the save button instead of moving to another record or tab then at the moment the Partner Edit Screen does not even show a warning as the validation message handling in this case does not include warnings (we should consider changing this though).

Any opinions how we should go about this issue? Is it handled differently in the Finance Module? We should aim for a common handling across modules. And ideally we should not allow saving of codes that are unassignable but just displaying of old ones.

Thanks,
Wolfgang

tim_ingham

The issues that come up in the finance module are a bit different: Account Codes and Cost Centres can appear on old transactions, which would not be allowed on transactions today. But in finance it's different because the user is not allowed to change those transactions.

In "Analysis Types" there's code behind a drop-down to avoid a constraints error - the user is prevented from selecting the same analysis type twice.

In the case you described it sounds like custom validation may be required: You could strengthen the warning to an error, but then suppress the error if the value has not been changed by the user (If the assigned value is the same as the one in the Database).