Reports #233
Comments
|
Functionality request from IV Hathaway: I realize that some of the requirements have already been fulfilled. I was trying to write a thorough high level description of how the chapter report list page should function, as well as illustrate a new workflow for submitting chapter reports. Lets start with how the list page functions (I have screenshots but cannot upload them): Lets start with what chapter reports I should see here. As a member of the the Command Triad, I should be able to see all chapter reports for my chapter. I should not be able to see chapter reports from another chapter. Without knowing how your back-end database is structured I am assuming that that is currently tracked by ship. The problem is that a chapter is not a ship. A ship name is a temporary ID which a chapter goes by. If they do not already, chapters should have a unique identifier separate from the ship name. When a ship upgrades (or downgrades) they should not lose the ability to review all of their chapter history because they have changed ship name. Nor should a chapter gain access to another Chapter's reports simply because they have adopted the name which was once held by another Chapter. As I understand TRMN policy, a Command Triad member should have access only to the roster data for their own chapter. If chapter reports follow the ship name and not Chapter ID, this policy is difficult to enforce from a data management perspective. Now back to the chapter report listing screen. The first column lists the status of each report: Sent or Pending. The next column lists the date for the reporting period covered by the report. There is no heading for the next column(s) but there is at least one possibly two columns in the table. The first icon is an icon with a tool tip which says view report. This Icon is present for all reports in my list. For my single pending report I have an icon and the tool tip states "send report". These two Icons are very close together. The first icon is innocuous but the second is not. Clicking the second icon, the send report icon, immediately and without further warning submits the chapter report. As soon as this button is hit the send script executes, the date does not matter, the user is not given a choice to review the report it is simply sent out to its intended recipients. Once sent the chapter cannot create a new report for the reporting period, nor is their an option for the user to pull back a report for editing.
#3 above should not be an option. It is far too easy to submit a report from the chapter report list.
My reasoning behind requiring the user to enter their password is really twofold first it requires more from the user than a simple click. In my view this is a very good thing. In my industry (Pharma, Medicine) this is incredibly common and is used whenever we want the user to really think about what they are doing or whenever an electronic signature is required. The first case where we use it we have to be careful not to be too burdensome. For the second case, we really have no choice. When an electronic sig is required it HAS to be there. It is in this latter case that I felt requiring the users to input their passwords to submit chapter reports is appropriate. These are the official records of the organization adding a password here makes the report FEEL official, even if there really is no electronic signature involved. It really should not be possible for a user to send a report before the first day of the month in which it is due. There probably should be a 60 day limit on how LATE a report can be. This means that a report cannot be sent in early and could not be sent in after the next report is due. Consideration should be given to creating a third status for the reports. There is no reason why the system should generate an email to the intended recipients as soon as the send button is pushed. Sending the report should place the report in a "submitted" status. The system should create either a timed event (e.g., 48 hours after submission) a recurring system event (e.g., 2am on the 11th day of every even month) or both when the reports could be sent in a batch. Consideration should also be given to how the Admiralty actually processes the reports, what information do the bureaus actually need and how should they be receiving it. If there is a system of record, MEDUSA, why does an email need to be sent out to the Admiralty staff at all? Shouldn't the system be able to generate what each directorate needs on request after the data has been entered into the system? Just a thought |
Tickets related to reporting that are not part of other Epics
The text was updated successfully, but these errors were encountered: