Handle multiple rotations

[dfaulken]

No description provided.

[dfaulken]

It occurs to me that we'll need some way of separating out Twilio interactions per-rotation. Perhaps a rotation-specific Twilio endpoint (this will involve reconfiguring Twilio), or perhaps using some attribute that Twilio gives us in the response (like the number that's being called?) and then referencing that to dynamically determine which rotation's currently-on-call-person's number we should return.

[dfaulken]

Code is written; @Anbranin is working on testing it and then we'll have a PR.

[dfaulken]

It also occurs to me that we don't currently have a way to handle new users who aren't added to a rotation.

I pointed out this morning that it may not make sense to validate inclusion in a single rotation at the model level, since there's a genuine use case for wanting a staff member to be able to see who's in a particular rotation without being added to it. But it occurs to me now that there's a difference between "who is in the rotation" at the object level and "who we include in generating the assignments", so that sort of validation should actually be fine, if not actually preferable for access control purposes. (Someone who is in no rotations shouldn't be allowed to see all of them, and being allowed to see none of them is useless.)

Seems like the best way forward is to validate for inclusion in (minimally) a single rotation when a new user is created.

[dfaulken]

#43. We ended up calling them rosters.