Stronger Update Validation

[hemangandhi]

In lieu of #29 and #22 ... we should watch out for some things in updates.

Namely, fields can be removed by skilled enough frontend users.

Also, the travel field is open to anything... that should change.

[TresTres]

Questions:

Is travelling_from rigid? Front end checks if that field exists for validation, and nothing with a travelling_from fields is returning when calling read

The update example has one field being updated, but tests returned a '$set' is empty... message if less than two fields are sent in the updates field. Is this on purpose / is the example inaccurate?

Users are only counted as registered when they have agreed to both the MLH Code of Conduct and Data Sharing policies. Front-end is in control of validating this (and it probably shouldn't) by updating the registration_status field to unregistered if one of these is unchecked. However, reading the same user resets the registration_status to registered. Is this also on purpose?

[hemangandhi]

Answers: wtf?!

Travelling from is not yet rigid. This might happen later on because we don't have time to get to it by Saturday. I don't want to try to figure out an API in the next few hours.

The $set stuff had to do with stringifying, I believe we talked about this. Did this work?

We can't avoid the frontend doing this since we do not have any notion of the checkboxes on the backend. Also, reading should not change anything. That has literally never happened. There is a small chance it's in some sort of day-of handling logic, so I'll re-deploy with that gotten rid of (if I can).

But yeah, without more data and reading your queries, there's not that much I can say.

[hemangandhi]

Some specifics:

• No changes to auth field allowed.
• travelling_from must have a valid city + state in the US as formatted_addr and mode should be either bus, train, or car.

[hemangandhi]

See also: #55

We should report invalid parts of the queries passed in.

[mjrb]

@hemangandhi is this fixed by #53 ?

[hemangandhi]

Yes