platelet-app / platelet Goto Github PK

A delivery may be one product, and a number of units, which is quite possible. In addition we also need to know the number of boxes so we can organise the right vehicle type

The GraphQL schema needs to be migrated to V2 before automatic deployments will work again on AWS.

https://docs.amplify.aws/cli/migration/transformer-migration/

During creation of a new task, a postcode lookup service could be used to help the coordinator find and enter an address more quickly

The user should be able to fill out a form with feedback on the app.

There could be an icon in the top bar somewhere that opens a form in a dialog.

The form would need to make a request to a lambda function that sends the email to an email address in an env variable.

5. When selecting any of the ‘Actions’ for a job it would be good to be prompted to automatically update other jobs:
   a. Picked up: If there is more than one job for the rider at that location.
   b. Delivered: If there is more than one job that is already picked up, being delivered to the location by this rider. This is very good when delivering to a pathology lab.
   c. Rider Home: Mark him as home for all completed jobs.

There needs to be a view that shows a table of statistics from a user set timeline.

There is already a component that connected to the old API in src/scenes/Statistics

It needs to be updated to work with the new API. This could be done either by making queries to DataStore or with a lambda function.

https://github.com/platelet-app/platelet-api/blob/master/app/api/statistics/statistics_utilities/statistics_functions.py

This is the old code that calculated statistics. It could be adapted to a lambda with connections to dyanmodb instead of sqlalchemy.

GraphQL schema does not support multi-tenanted access. The tenants are the individual charities primarily. It might be helpful to build in support for multiple organisations that comprise of multiple groups.

e.g Blood Bike charities > Freewheelers, SERV, etc...

this would allow tenants of certain organisations to collaborate with other groups, provided they are within the same organisation umbrella.

The app needs to be set up properly for localisation so that it can be translated into other languages.

1. It would be good to have the phone number auto-populating (but editable), based on the pick-up location. This would be enhanced by having a re-shuffle on the ‘Create new’ tabs:
   a. The pick-up location should be on the first tab with the name, then there will be an opportunity to auto populate the telephone number. After all, that is part of the caller info.
   b. The urgency should then be moved to the third tab along with the destination. It’s often the last thing you ask.

The login page uses the default Amplify styling and needs to be updated to look nicer and match the rest of the app.

For us we know the registrations of vehicles in another system, for the task we need to record if it was a Car, Bike, Fleet Car or Fleet Bike. Statistically that is important for us

There is no implementation to allow coordinators to set the scheduled pick up, deliver at or deliver by on a task.

This should be integrated into the task overview and guided setup.

Navigating to a page with comments on, socket communication works for comment updates. If the page is refreshed or loaded directly socket communication is disabled.

I think this is because the message to subscribe to comments on a parent object is sent before the socket is connected. Some refactoring work needs to be done on the socket middleware to prevent this from happening.

The lists of users/vehicles/locations could be made to look more consistent with each other and a way for the user to filter them and find things more quickly.

Filtering could also search by extra keys like rider responsibility, bike manufacture, or location address line 1.

The task overview should only allow certain actions for someone that is assigned to it as a rider compared to a coordinator.

The rider should only be able to update items under the Actions panel.

The React Context feature may be good for this so that checks don't need to be made in each component.

https://reactjs.org/docs/context.html

There needs to be a view for external users to make requests for jobs. The guided setup view could be recycled for this.

When the guided setup is open, the back button should close it (with confirmation if necessary) instead of navigating back in the history.

A new scene needs to be made so that coordinators can look through older tasks that are no longer displayed on the dashboard.

A paginated table view might work best.

The ComfirmationDialog component should prevent back navigation when the back button is pressed, and instead close itself.

A establishment may call for a task, that comes from and goes to different locations. We need to record the establsihment that makes the request

There is no delete mechanism in place for users, locations, rider responsibilty or deilverables. They need to be removed without compromising any connections to other tables.

Deleted users also need to be disabled and deleted from cognito.

There could also be a disable user function.

AddressAndContactDetails may not need to be a model and could be refactor to either a type or by placing fields directly on other models

Critical item for H and B is time rider leaves home, without it you are not always seeing where someoen is ahead of the first pickup

The dashboard shows every active task in the In Progress tab and up to a week of tasks in the Completed tab.

There needs to be a way for the user to only show tasks that need to be done today or to show all tasks.

We could add a second tab between In Progress and Completed named something like "Future Tasks". The In Progress tab could show only today's tasks and Future Tasks display anything not due today (or just everything?).

There could be a feature that generates reports either in spreadsheet or PDF format.

Need to decide what data should be included and how it will be presented.

Cognito needs to be updated to support multi-tenanted access. An group ID should be recorded against user attributes for a particular account.

May be best to implement this in the cognito post confirmation lambda.

The GraphQL schema has avatar URL strings but there may be a better way of representing image data using Amplify.

When a new member does his very first job, we allocate a more experienced rider to go with him or her. What we need to record is the Buddy Rider name as well as the Rider assigned

Reciept Numbers are currently not being used, but there is an expectaion they may return, so we need that option. This goes in parallel with a photo or QR code etc

They could be converted to use ClickableTextField enabled on edit mode. Similar to how src/scenes/Task/components/LocationDetailAndSelector.js does it.

At the moment setting the time on time of call, time picked up/dropped off/rejected/cancelled/rider home allows setting the time in the future.

It should also not be possible to set the time dropped off to a value before time picked up, or rider home a value before dropped off time.

There should be a way for the user to make a duplicate of a task on the dashboard.

Unsure if the duplicate function should also copy assignments over (apart from assigning the user themselves as coordinator).

The option could be placed in the 3 dots menu for task cards.

An admin should be able to make changes to the labels on rider responsibilities and label, default unit on available deliverables.

It would be helpful if the user can enable a selection mode that allows them to select more than one task and perform actions on them.

It could be that when selection mode is enabled the user can click on a card and highlight it. Actions that can be performed appear somewhere on the dashboard.

Once the user clicks something to perform the action, a confirmation window could come up that details what is going to happen. e.g. "Mark 4 tasks as picked up?"

Actions could include anything that can be done from the Actions panel on the task overview.

3. I think Theo told me that a coord can view all previous jobs on the ‘All Tasks’ view. This view allows a simple way to pass jobs from one coord to another. Some thoughts:
   a. These are editable. While I accept that we need to have a degree of trust, I think this is open to abuse and should be restricted to a few days (seven seems to be a standard). If a disgruntled coord decided to mess stuff up, this would restrict just how much damage can be done before their access is removed.
   b. The advantage of these being editable is when passing jobs from one coord to another. The jobs can be retrieved from the ‘All Tasks’ list by the new coord. However, I think we should have the ability to bulk-transfer outstanding jobs from one coord to another. The alternative it that the outgoing coord adds the incoming coord to all the outstanding jobs one by one. I don’t see this as a particularly onerous task and if I were an incoming coord, I would add my name to all the outstanding jobs anyway, so they were on my dashboard.

The experience when using the three dot menu in mobile view is poor. You have to click the corner of the card to guess where it is.

This experience should be improved so that mobile users can easily access the menu for quick actions.

A desktop app could be made to allow coordinators to have a dedicated program running on their PC. This could have more robust offline support and use desktop notifications.

Electron may be the best choice, but other frameworks can be considered.

If another user is viewing a page while a private comment is added, the user will see the comment until they refresh the page.

A view needs to be built to show external or internal users tracking information when given a reference. Once relays are implemented it should account for those and show tracking information across the entire journey.

Information displayed could be time of pick up, time of drop off and the respective locations.

The rider responsibility is currently set by the rider. For Freewheelers EVS, this represents the shift type that they ride. Most riders have more than one shift type and it needs to be set for each shift. It doesn’t work to set this per rider only. It needs to be set per rider per shift. It would be logical for the coord to be able to do this at the start of a shift.

This information does need to be available for reporting. For example, how many jobs were on the East patch.

I see we have what we need in the FROM and TO options, even for a handover, but what we cannot do is show where a handover originates from

Passwords can only be changed by using the forgot password method. It should be possible to change password from the app itself.

Profile pictures cannot be set by users.

Need to investigate best way to implement with Amplify and develop the front end to allow profile picture uploading.

Amplify has an option to add storage and has premade UI components for displaying and uploading images.

With the service worker enabled the page always uses the cached version even when an update has been pushed.

The app could prompt the user when a new version is available to update the cache.

This would be particularly useful when using as a PWA.

A mobile app needs to be developed using React Native. It should work with DataStore and the provisioned Amplify back end.

Something minimal should be built first, to let riders update their jobs while on the move. Other features from the main app can be carried over later.

The GraphQL schema will need to support external users. An extra role should be made available.

We do report on delay reasosn when discussing our SLA with hospitals. There is a comment field, but in the event of an unforeseen delay, it would be helpful to record the time and reason for that delay

The GraphQL schema has no support for scheduled tasks. It should be updated to support setting the expected pick up date and time.

Do we need to add support for an expected delivery time or deliver before time?

At the moment there is no decided upon way to store connect task relays together.

There are two options:

• Link Task directly to Task so that each relay is connected in a linked list
• Create a parent table that links multiple Tasks together

First option is easier to implement in the schema, but can cause headaches in the front end if using the same structure. You end up having to use recursive functions to update state.

Both could be implemented to give the choice of retrieving the data either way.

The previous backend implemented both but primarily relied on the second option.

Currently there are no persistent notifications for users while on the web app.

It would be helpful for users to know when a task has been assigned to them, or a task they are assigned to receives a comment.

A notifications icon could be added to the top bar, redux-saga used to listen for notifications and Amplify for pushing notifications.