redcross / dcsops Goto Github PK

When creating incidents in NorCen, occasionally DCSOps doesn't recognize an address, especially in the Dakotas. When this happens, DCSOps defaults to the message that we don't dispatch for that area and provides the number for National. When we remove the street address and only use the city/state for the query, then DCSOps provides the County, Region, and POC to hand off the incident. Can DCSOps be programmed to just query for the city/state when identifying the County and POC and disregard the street address? That way dispatchers won't mistakenly hand off an incident to National when we should actually be dispatching it.

When a user submits an incident report with an error, the "Structure Type" field becomes blank even if it was filled out before. User corrects original error, hits submit, and gets error about structure type field. User is angry.

Doesn't submit required field "Min Desired Sign-Ups"

The dispatchers often forget they there is a --reply with yes or no message added to their recruitment message. Show a sample message that includes the chapter's defined appending message to help in preventing duplication.

Some slots appear as "MM/DD/YYYY" instead of showing date, field is too short to show full date.

To show trends, responder history page should show calls to responders in the order they happened. Also, will need to adapt to only show last N responses (maybe with a lifetime percent), since Ed Silva is already running off the page.

When recruiting would be nice to have a position filter on the responder console to filter through the flexed suggestions. Then the console could be used to recruit any position loaded in from Volunteer Connection by geography. Right now our console is showing nearly all trainees and only have two or three slots to work within for a full fledged responder recruitment.

Create a message management console that allows dispatcher to see and manage all SMS for their chapter. Have an outbox, inbox, etc. Be able to communicate directly with anyone outside of a particular incident. Filters for messages that dispatcher sent and receive replies for in X period of time. Be able to assign (or re-assign) messages to incidents, including being able to apply to more than one incident at a time.

This will be a new tab for recording detailed client service delivery info in the incident report. A simple proposed mockup is attached to this issue.

Steps:

• Create a Case model with name fields, unit #, phone number, CAC # (do the CC luhn check on this field), assistance given. This belongs_to incident
• Create an Assistance Model with class, type, unit, qty, subtotal fields that belongs_to Case
• Create the edit UI for the incident report. Each case should display statically (not in a form), but upon clicking edit or add a form is displayed which allows the user to make changes. Clicking save posts the changes back to the server and goes back to the static display (this same remote form mechanic as Timeline uses)
• Add this data to the existing Cases tab when viewing an Incident

Suggestions from user on improvements that can be made to the scheduling calendar:

On the calendar the numeric day of the week is printed directly about the 1st shift (12 A - 6 A). I’d like to see the numeric day of the week printed in the upper left hand corner which would be consistent with most calendars. (Place more emphasis on this for finding this easier in a large calendar)

Regarding the DAT calendar - each week is separated by a solid line. I would like to see each week separated by either a darker solid line or perhaps a double line. At a glance this would help to make each week stand out from the previous as well as the following week.

When editing or creating a client in DCSOps, the cost for livable assistance is incorrect. It should be 50 x quantity. It appears to be 50 x 1, then + 35, then + 20 for each additional client after that. Livable X 4 should equal 200. Right now Livable x 4 equals 115.

The phone number for the client is only visible in edit mode for that client. Display the phone number field in read only view. Dispatchers believe everything that is being stored for the client is displayed on the read only view, when it is hidden the data is believed to not exist. (Review other entities and determine if other items should be also shown.)

When a shift has been disabled using shift_begins/shift_ends, it still shows up in a few places:

• The main on call listing in /scheduler
• Some of the email templates (reminders, etc)

Volunteer Connection limits hours being submitted to no more than 40.0 hours per submission. Need to break down the submission of hours for anyone with more than 40 to chunks that will fit inside of the submission criteria. This will be easy for shifts that are less than 40 hours, i.e. 24 hours per day. But if you have a 24x7 for a week and 24x30 for a month, will need to figure a way to break down the hours into acceptable components for submission.

This applies to the job that runs now weekly, as part of this may also want to consider changing to a daily job.

Now when you use the "Send SMS" you can no longer message the people you have tried to recruit. You cannot send a follow up message to those people. i.e. you cannot tell them "We have who we need" or "PLEASSSEEEE HELP!" to those already receiving text messages.

Don't hide the "Send SMS" after sending, add an icon that shows you have sent a message to them. Show how many messages were send with something like [1] [2] etc.

Need to make sure this falls into the recruitment engine of monitoring replies yes, no etc. See also other issue regarding a dispatchers SMS in/out box management.

They can technically overlap with daily shifts, so it can't just overwrite the whole length of the shift.

When accessing "https://www.dcsops.org/scheduler_admin/roles" system gives out a 500 error in the title bar of the browser. Cannot access the module.

Lists last shift in early July.

Reported for Sabrina Quock, also present for Laxson.

The confirmation email language needs to be updated to address issues with a single person vs. a team of individuals are signed up. The scenario was brought up by a responder trainee that was scared they would be the only person responding when they got the confirmation email. As a small change, review the language that is used to account for when they are the first sign up in the team.

Compare this with the larger issue, in this repository, of custom templates.

Under DAT Scheduling/Upcoming Shifts only 3 upcoming shifts show up. I’d like to see 4 upcoming shifts be shown. I do see that all 4 shifts are shown under All Upcoming Shifts/Listing Assignment but it would still be helpful to see 4 shifts show up under DAT Scheduling/Upcoming Shifts.

Additional comment regarding this user suggestion from our region, may want to have icon or "see all" sort of link when truncating their full shift list.

Just need to add the right span and CSS so FlyingSaucer puts it in the margin for each page.

Looking in the code I see in responder_message_service.rb that the assumption is that if the incident is open then the responder is still on scene. There is no code checks against their departed status. This should be taken into account for incidents were they are re-opened or are open for extended periods for longer events where they may be waves of responders. Without this the responders text message may go back to a previous incident they worked and may now be deployed on a newer incident.

In order to generate incident numbers when they are not provided, we need a sequence number generator. For each chapter it should store a format, and current index. Provide a button on the create incident page which generates the next sequence, formats it and fills in on the form. The format should support including the current fiscal year (July 1 - June 30), and automatically resetting to 1 at the beginning of the year.

For Volunteer Connection-recorded hours, NHQ now requires a position to be attached to each record for the hours to be counted towards Regional goals.

Attach position data to DCSOps hours exports when transferring to Volunteer Connection.

We should not be recruiting people that are already on scene. Suggestion to provide a notation that a responder is on scene and what incident number they are currently assigned.

Disable the recruitment "send sms" link for that person because the message is not going to route back to the recruiter it will go to the first incident's dispatcher.

Fix Case 'Delete' button in Add Client window. The Delete button appears as a string of text that will not permit deletion of a Client (Case) record:

Create a custom call back for voice from Twilio per phone number, so that message can be customized to tell responders who are calling back a number who they can contact in their area. Static message defined by chapter in the same spot you enter the Twilio phone number and API key. This would replace the static XML file that is used for all chapters at a system level.

Also if this looped through the same list the dispatcher console used to read off the first number as an option, phase II? A static message would be good. DATs calling back to the SMS number during recruitment happens frequently. Working on the training in June though too.

Implement some sort of hierarchy, like the VC backend:

• Everywhere
• Division
• State/"Zone"?
• Region
• Chapter
• County/"District"/"Response Region"/etc

Every resource should tie in to the hierarchy at some particular level, and users can be granted permissions at a particular level that apply to all resources below.

Shifts can optionally require you to be a member of a particular hierarchy.

Support aggregating statistics (like incident report numbers) up and across hierarchy.

This was during impersonation, have not tested with a user directly.

In incident reports click on View to a SMS message that is pending acknowledgment. Throws error over lack of access to the message. Remove "view" option from the messages or hide them all together.

Attached screen shot.

This is a fairly simple rework of the existing _form_responders template which edits ResponderAssignments:

• Add the UI to the inline report view
• Add phone numbers and miles from incident as columns to the lists of responders (Incidents and People already should have lat/lng associated with them, so just need to install the geokit gem to do distance calculation)
• Ajaxify the form using inline controls

Currently, the presence of a DatIncident causes all Incident and DatIncident data to validate. We want to allow data to be saved in an intermediate state, and only validate the whole thing when marking the incident as complete.

A rough sketch of implementation:

• Add a string field to Incident called 'status' that defaults to something like 'open'
• Set up delegated validator to only care about a limited set of fields when status is 'open'
• The existing, full set of validations should be used when status is 'closed'
• The current one-shot incident form should always attempt to set status to closed so that it gets all the validations
• The in-place editable form should have UI to 'close' the incident which will check the validations
• Only once status changes to closed should the IncidentReportFiled action be triggered

Update to support of latest version of Font Awesome Icon set.

Add the ability for a subscriber to customize what they get with the report:

• Weekly or daily
• Include deployments?
• Filter by geographic region
• "Send one now!"

ApplicationHelper has one builder for a bootstrap-editable select box. Move this to its own helper and add more for text fields, text areas, check boxes. This will be needed for the editable incident report.

"can't be blank and is not a number," is rightly reported to be a confusing way of saying that the submission may not be blank and must be a number.

Manage voice services like a Vodacall way, in which could use for responders and clients to get routed back to the dispatcher. Allow for outbound calling to clients and responders so there is one number only for the chapter dispatch. Create an over all management console for system, chapter and incident level.

In DatIncident, add snacks, winter kits, and drinks to tracked resource types and ensure they can be edited.

Make grid-view columns sortable by city and/or position.
Make Roster Columns Sortable

Include the current Incident timeline page to the inline editable incident report. Make sure it's functional as a remote/ajax form, and tweak the UI for adding/editing.

Currently there is UI to attach photos with incident reports, but it is just a stub, we want to build it out. I'm leaning to call it attachments so anything relevant can be attached (incident photos, paperwork, etc).

Steps to implement:

• Add the paperclip gem to Gemfile
• Create an Incidents::Attachment model that belongs_to the incident. It should have the paperclip attachment fields, name and description, and a 'attachment_type' field with assignable_values which we will use to categorize (i.e., document, scene_photo, damage_assessment_photo, etc)
• Add UI similar to the Timeline screen for adding and removing attachments to an incident.

When someone starts on this I will get credentials for Amazon S3 as the storage provider that paperclip can use. In development mode, it should just use the local filesystem.

An editable page with the same content as app/views/incidents/dat_incidents/_form_basic.html.haml, but using inline editable controls. Will need the inline editable controls from #22.

In https://www.dcsops.org/scheduler add area for small message to dispatchers. Responders can put messages like "Not available Tuesday's 10-2" or "Don't get text messages in house, call landline" etc. Show this on the ASSIGN page for individual, with phone numbers.

Right now the CAS Event field is buried and isn't visible unless you click on Type of Incident, then it appears in a pop-up. Dispatchers continue to overlook this field and don't input the CAS Event number. If it had it's own clickable row positioned just above the Type of Incident row I think we'd get better compliance on filling in that field because it would be more visible.

Additionally, can we add an example of what the CAS Event number looks like underneath where it says CAS event number in the pop-up (ex: 1116-FIR-000) so volunteers recognize what goes there? I often see case numbers pasted there instead of CAS Event numbers.

On the Incidents pages, update Regional boundary maps to reflect new Regional geographies. These North Central Division Regions have incorrect boundary maps:

Idaho-Montana

Kansas-Nebraska

Minnesota

Chicago & Northern Illinois

Central & Southern Illinois

Probably one for swap, one for signing up for a shift