dadair-ca / perm Goto Github PK

Currently, PERM has only been manually tested. It needs a full suite of tests to provide developer confidence now that it is in production.

Should add coverage and build status tokens to the Github page.

The administrator should have a dashboard that shows relevant stats about the session:

• Gauge of shift drops (should be net 0)
• Leaderboard of students

The user roles system is quite inflexible right now with [student, command, nurse, admin], since people can only have one role. It would make more sense to allow combinations of roles, such as a nurse that is also an admin, so they can coordinate the nurses.

Something that may be better:

• student
  • new
  • command
  • standard
• nurse
• admin

Currently, the Submit Feedback button uses a mailto: link, which opens up the system's default mailer. This is generally bad if the system is used on public computers (which will happen more with increased patient-logging features in the future). It should just be a contact form.

Resource routes seem a bit off right now. For example, users can see a dashboard of their shifts at

/shifts

But that same view is almost completely duplicated at

/users/:id/

These views (and potentially others) should be combined, where the view changes slightly depending on resource ownership and administrative rights.

Shifts should be part of a session, not free-floating. This would allow the application to track student performance within sessions.

Should have two tabs when creating shifts, one where you can create a 'Recurring Shift', and one where you can create a 'Single Shift'.

The datepickers don't work in Firefox, for example.

Really only useful if there was a mistake generating shifts in the first place, but still useful to be able to delete shifts that are not owned by a user.

This causes a few issues:

• Only 100 emails a day (scale issues with more students)
• May be marked as spam

System does not allow a shift from 11:00PM to 2:00AM.

Some templates are repeated, almost verbatim, in different views.

Examples:

<template name="shiftItemForUser">
  <tr>
    {{> shiftRow}}
    <td>
      <button class="deleteShiftButton btn btn-danger btn-sm">Delete Shift</button>
      <button class="dropShiftButton btn btn-warning btn-sm">Drop User</button>
    </td>
  </tr>
</template>

<template name="shiftItemOwned">
  <tr>
    {{> shiftRow}}
    <td>
      <button class="btn btn-danger btn-sm" data-toggle="modal"
              data-target="#{{_id}}-dropModal">Drop Shift</button>
      ...
    </td>
  </tr>
</template>

Users should be able to interact with shifts directly within the calendar view. For example, students should be able to click a dropped shift, and grab it.

Currently, pemrap.com is aliased to pemrap.herokuapp.com, so once the user navigates to pemrap.com, they are presented with pemrap.herokuapp.com. I want pemrap.com to be the only prefix.

Current:

Shift: {
  _id,
  ownerId,
  when: {
    day (string: "YYYY-MM-DD"),
    start (string: "h:mmA")
  },
  duration,
  type
}

This just complicates event scheduling and sorting. It should be simplified to:

Shift: {
  _id,
  ownerId,
  start (ISODate format),
  end (ISODate format),
  type
}

The user list is currently a huge single table. The resource should be paginated so that screen space is preserved and the application scales better.

A search field should also be provided so the administrator can jump immediately to a user.

It would be nice for PERM to be a hub for all PEMRAP activity, including:

• shift calendar
• study descriptions
• patient logging

Should have a log of activities that the administrator can look through. Something like a live news feed on the administration page. Each user-page would also have a list of that user's recent activity.

Even if it is now 2014-09-14 14:00, a user cannot pick up a shift at 2014-09-14 18:00 since only shifts at later DATES are available for pick up.

Users should be given a status flag of Active/Inactive, so that rather than deleting students from the system, Jian can flag them as Inactive, which disables their login and removes them from the mailing list. They will also be removed from the users#index list, and puts them in a separate list (on the same page).