getter invalid error returns nested object.

[mikeywaites]

trafficstars

with a getter function on a nested field in a field.Collection, the error format is not consistent with field.invalid

def pillar_getter(session):

    if session.data and 'id' in session.data:
        pillar = Pillar.get_by_id(session.data['id']).one_or_none()
        if pillar.company.organisation_id != current_user.company.organisation_id:
            return None
        else:
            return pillar

class WeightedPillarMapper(WeightedComponentMapper):

    __type__ = PerformanceTemplatePillar

    pillar = field.Nested('PillarMapper', role='pillar_weighting', getter=pillar_getter)
    kpis = field.Collection(
        field.Nested('WeightedKpiMapper',
                     getter=kpi_getter,
                     allow_updates=True,
                     allow_create=True),
        required=False,
        default=[],
        extra_marshal_pipes={
            'process': [set_order],
            'validation': [check_for_duplicate_kpis, validate_weightings]
        },
        error_msgs = {
            'duplicate_error': 'You can\'t specify a kpi more than once in a pillar.',
            'invalid_weighting': 'Please ensure all the kpi weightings inside '
                                 'each pillar add up to 100%.'
        }
    )

If the getter fails the error message format is an object in the form of {'pillar': 'pillar not found'}. Taking an error response format from the Vizibl API we end up with

            exp = {
                'status': 400,
                'errors': [
                    {
                        'field': 'pillars',
                        'error': {"pillar": "pillar not found"}
                    }
                ]
            }

We'd expect to see consistent error format in the form of

            exp = {
                'status': 400,
                'errors': [
                    {
                        'field': 'pillars',
                        'error': "pillar not found"
                    }
                ]
            }

[mikeywaites]

#155

[mikeywaites]

Im pulling this out of the 1.2.0 release because on closer inspection this is probably more an issue of our specific use case.

There's an on-going discussion about changing the way field.invalid() works where we should revisit this #127