(2931/2) Model csv actual refund comment row from csv

[mec]

Now we have a reliable model of a financial value in a csv import, we can move onto the rest of the data in a row.

This is the Actual, Refund and Commnet csv row model, it is responsible for providing a reliable interface to import a row of data that result in a new Actual, Refund or Comment and will form the base of a new importer.

The motivation here is to allow users to provide a comment in the upload when there is no actual or refund to attach that comment to - instead the comment is attached directly to the activity the row represents - this is a common user feature request that would commonly be used to explain the lack of actual or refunds in a report.

We wanted to approach this like the 'form object' design pattern, it is a standin for a model that validates in a specific context, here it is multiple models and the context is importing.

Like a form object, we can offer specific validation and errors to pass back to the user instead of relying on the underlying model validation, the main difference is that here, we do not save the records.

There is a lot of validation during this import, to summerise:

• a row can only be one of an actual, refund or 'acitivity comment'
• a refund requires a comment
• a refund can be negative (they are always saved as a negative value regardless)
• If a receiving organisation name is present, the type must also be present and vice versa
• if a receving organisation reference is present, the name must also be present
• financial quarter must be 1, 2, 3 or 4
• financial year must be a valid year
• activity RODA identifier must be present, but does not have to be a known identifier at this point

The model can be intialised from a CSV::Row instance and can then called valid? much like an ActiveModel. Calling valid? will populate the errors for use later in the import process using the same interface as the existing import.

It is worth noting that a valid Import::Csv::ActivityActualRefundComment::Row may not result in a database record, we have purposly left out any validation that involved loading another object from the database - this will allow for better perfromance as we only need to fetch related object if the row already looks valid.

The existing importer relies on the column position whereas this new one relies on the column headers, this is a significant change that is easily missed.

This work is the second in a series, next step: add a service that further validates and creates the database objects if valid.

If you want more context about the longer plan - just ask! :)

https://trello.com/c/lBZkYq5c

[shuldt]

Happy with this as we went through it in detail together, just one question on a file we didn't go over

[shuldt]

Is it correct for 'required' to be nested in 'default'?

[mec]

Yeah, it might read a bit strange! The idea is that default is not any specific value and required means the value will be required, there are a number of attributes that share this validation, we could repeat the required for each attribute but that felt like repetetion?

I am hoping someone with better content design will go over all these new error messages at some point - so I'll wait and see if the messages need to be different.