nharper / allegro Goto Github PK

Add the 3 columns - missed monday rehearsals (and retreat), attended sectionals(/optional rehearsals), and total absences

Basic CRUD operations

The AttendanceRecord model has a validation on it validates_uniqueness_of :performer, :scope => :rehearsal with the intention of making sure there is at most one row for a (performer_id, rehearsal_id) pair. Running this SQL query: SELECT c, performer_id, rehearsal_id FROM (SELECT COUNT(*) AS c, performer_id, rehearsal_id FROM attendance_records GROUP BY performer_id, rehearsal_id) AS t WHERE c > 1 should return 0 rows, but it does not.

Most likely, there is a race condition in RehearsalsController lines 158-164. My hypothesis is that two requests coming in (to update data for the same rehearsal at the same time) hit the AttendanceRecord.where statement, and both make new record objects. When the records get saved, each request is trying to insert a new row, and the second request to insert a new row for a particular (performer_id, rehearsal_id) pair fails the validation.

Twice when using the rails console to move someone inactive to active, I've noticed the chorus number field is cleared. This was probably done so that if there was a dupe CN between an active and an inactive member, there wouldn't be a conflict, but that shouldn't happen (the CN should still "belong" to the member who is inactive, or that member should be alumni). Try changing this logic so inactive performers still have chorus numbers in their registrations.

Make sure all N+1 query slowness issues are at least marked in the code with TODOs, and then fix them.

For each Performer, include

• name/photo/other info in Performer model
• link to Groupanizer
• list of their Registrations

The staff would like to be able to show custom messages/reminders to specific members on the tablets when they check in to rehearsal (e.g. reminding certain members to pay their invoices).

This needs a new model for the messages (message:string, seen:bool, performer:references), ui for staff to add messages for members, a change to the check-in ui to show the message, and changes in controllers to make that all happen.

Open questions:

• When to stop showing the message? Should the user ack the message, should it be automatically ack'd when displayed, does it only go away when staff removes it, or something else?
• Should messages ever be displayed at check-out? (i.e. to help traffic flow, don't show them)
• What to do when user acks message on check-in and they check out on a different tablet? That tablet won't know the ack, and could show it again.

Currently, the "Create final attendance records" only creates AttendanceRecords if none exist. If the button is clicked before all RawAttendanceRecords have been uploaded, then incorrect AttendanceRecords will be created. The button intentionally doesn't override existing AttendanceRecords so that manually overridden records don't get deleted, but it should be safe to change records from present=false to present=true.

There at least needs to be an indicator that the computation has finished. (Right now, when the computation is complete, the user ends up back on the same page with only the browser's loading indicator to show that it worked.)

The current table view for attendance (e.g. /concerts/6/attendance) has a lot of information, but it could be improved.

Some of the problems that should get solved:

• When scrolling down the page, headers are not visible
• Optional rehearsals are indistinguishable at a glance from required rehearsals

This should be handled in the same case statement as “Alumni”

Put together a testing strategy and write tests (unit, integration, ui, etc)

Some rehearsals (retreat) count as more than one rehearsal - add a field to the Reheasal model to keep track of this, and use it when calculating number of missed rehearsals.

The report should include a list of members with number of absences, sorted by the number of absences (descending).

For rehearsals like an all-day rehearsal or retreat where it's worth 2 rehearsals (i.e. the Rehearsal has a weight of 2), some members only show up for half and get half credit. There should be a way for a section coordinator to record this half credit.

This requires changes to the AttendanceRecord model - instead of the "present" bool, a "weight" field is needed. The weight field could either be normalized (where 0 is not present and 1 is present for the whole rehearsal), or it could be a raw weight value (for a Rehearsal with weight N, the AttendanceRecord weight could be up to N).

Like on the "take attendance" pages, the raw attendance view/reconciliation should also update when the <select> changes between present and absent.

If someone checks in twice late, the amount of time they are late gets double counted when computing how much time was missed from rehearsal. This should only be counted once (using the earlier time, i.e. assume they were present from when they first checked in). Ditto for check-out times.

UI changes:

• member-facing:
  • numpad takes up too much space - hide behind "forgot card" button
  • confirm manual entry
  • fix font issue on numpad backspace and enter buttons
  • only display one member at a time (and make name, photo, etc. larger)
  • better ui for errors
• admin:
  • add "admin" panel - for switching between checkin/checkout, uploading data, future features
  • some way to scroll through list of all data about to be submitted
  • better handling of updated appcache
  • loading indicator when saving things to appcache in background
  • better ui for errors (both member errors and errors from admin interaction, e.g. upload)
  • improve re-login flow

Improvements to make it more app-like:

• disable scrolling
• disable zoom (i.e. pinch to zoom)
• go fullscreen
• disable back button (probably not needed if we're fullscreen)
• prevent screen from sleeping (if possible)

Potential new features:

• load all rehearsals and ability to switch between which rehearsal is active
• automatically switch between checkin and checkout based on time

Take a message template and the attendance data for a performer in a concert so far, and generate an email that could be sent to that performer.

e.g. When I go to /concerts/N/attendance and change the selection, if I reload the page it should take me back to the same selection. This probably means changing the hash of the url and putting that in history, and when the page loads, check the hash to see what the selection should be.

When a member’s attendance goes up or down offer the e-mail address and the count with the increase or decrease (when we have makeups)

Two possible design ideas for this:

• After each rehearsal, have a list of "what's changed", and use that for knowing what needs to be sent
• Track when emails get sent, and then there can be a complete list of what needs to be sent

The first option is probably easier to implement, and for SCs manually sending emails, it doesn't require the SC to indicate that they sent an email. However, if a SC misses a week, they have to look at the "what's changed" list from each week that they forgot to send emails. The second option solves this problem, but SCs would have to tell allegro when they sent an email, or emails would need to be sent through allegro.

Use start/end date combo along with rehearsal type (required vs optional) for logic in raw_attendance view/controller.

When uploading raw checkin/out timestamps from a tablet, if the request is interrupted before the server responds, some but not all of the data gets uploaded. This problem is coupled with the problem that there's no UI to indicate how the upload is going.

Ideally the whole upload would be wrapped in a transaction so that if the request is interrupted there is no partial upload - either it all goes through or none of it does.

This helper is used in the raw attendance view. Either the helper should be changed to handle a nil weight, or the Rehearsal model should be changed to require a weight (and then check that all Rehearsal records in prod have a weight).

Raw attendance timestamps are uploaded with a field indicating a type (checkin or checkout). This doesn't affect any calculations, but the view is still using this field.

This report should show all tap in and tap out times, list presences/absences, and total missed count.

Once a User successfully logs in via a login token, the token is supposed to be cleared. This regressed in a503ce1 and tokens are no longer getting cleared.

Basic CRUD operations

Ability to copy Registrations from previous Concert?