vadrian89 / refugee_help Goto Github PK

A ticket is what the dispatcher creates in order to match refugee needs with volunteers offerings.
The dispatcher should be able to manage all tickets created by him.

Required features:

• create ticket;
• view ticket;
• view tickets list;
• update ticket;
• ticket feedback

Optional features;

• automatic ticket feedback request;

About tickets:
Tickets system is used by the group of volunteers to have a history on their activities this can help them to observe the flux of refugees and see how the needs increase or decrease.
A ticket should contain the following data:

• number of adults
• number of children
• vehicle of transport used
• the destination (this can be an adress or volunteer's housing);
• status of the ticket (created/started/finished/canceled)
• feedback related to the ticket
• remarks;

The number of adults/children, destination (address) and remarks are text fields.

The vehicle of transport used should be a card when viewed which should contain the following info:

• registration number
• number of seats available
  When user taps the tile, it should pop-up a bottom sheet with aditional info about transport and user.

When editing or creating, it should be a tile which should show containe only the:

• number of seats
• destination
• icon of the type

Tapping on the tile, while creating or editing, should show a bottom sheet from which the user should search and find the transport needed, based on the completed fields.

The status of the ticket should be related to fields in the ticket document, meaning when you want to change the status you should set the field of that status.
The order of the statuses is the following:

1. created - de thefault state
2. started - when the volunteer(s) agreed and everything is in course
3. finished - when the dispatcher or volunteer closes the ticket using the feedback pop-up
4. canceled - when the dispatcher cancels the ticket

The dispatcher and higher privileged users can call the volunteer's number through a calling button.
The volunteers can view the tickets which are related to them (either because of their transport or housing)
The dispatcher can view the tickets which were created by him.

• Implement authentication application and domain layer (sign in, sign out and authentication state subscriptions)
• Implement registration
• #8

The current implementation of the router bacem cluttered and hard to keep track of.
A new implementation is required, one which should:

• create the path automatically
• manage result on pop
• manage modals such as: dialogs and bottom sheet
• manage and make use of query parameters
• use BLoC to handle the state
• be easy to turn into a package for others to use
• be easy to extend

Implement the volunteer's profile screen, which should have the following features:

• view personal data;
• check and show if the profile is valid or not; all fields are valid, because we need to ensure the safety of the refugees;
• edit personal data;

Implement the authentication workflow:

• Sign in with e-mail and password;
• Sign in with Google on Android;
• Sign in with Google on web;
• Sign in with Apple on IOS;
• Reset password;
• Automatic session check and redirect;
• Ensure is responsive;

Initial, planned, features:

• #2
• #3
• #4
• #5
• #6
• #7
• Administrator: User management

Transport and housing search screens only show the items for the current user.

It should show all available items from all users matching the filters.

To find transport, the user should be able to search by:

• available seats
• transport category

Aditionally by:

• destination

The list tile should contain the following data:

• available seats
• transport category
• destination list

Aditional elements:

• a button for fast calling the volunteer
• a button to view full information about the transport

When using the browser/mouse to navigate back, from tickets/add/transport path and up it returns wrongly.

All volunteers can add their housing for refugees.
This includes the following features:

• add housing;
• view housing;
• edit housing;
• delete housing;
• list the volunteer's added housing;

When a volunteer finishes a ticket he can change the status of it, by adding a feedback.
This feedback can be: issues with the refugee, feature request for the app, etc.
When he wants to send the feedback, a pop-up will ask him if he wants to change the status of his: car, nr of available housing spaces, rooms, etc.

Required features:

• Dropdown selector for type of feedback; Inital types: Refugee problems, App problems, App feedback, Other;
• TextField to add his feedback;
• Request status change when pressing save;

Clicking very on next/back buttons triggers list stream multiple times with the initial first/last document cursors which makes the stream return the wrong page.

The offending code:

Future<void> fetchList({TicketRequest? request, bool isTable = false}) async {
    if (_stateInProgress) {
      return;
    }
    emit(ListTicketsState.loading((request != null) ? "retrieving_data".tr() : ""));
    await _listSub?.cancel();
    if (request?.goBack ?? false) {
      _currentPage--;
    } else {
      _currentPage++;
    }
    if (_currentPage == 0) {
      _paginationInfo = null;
    }
    _listSub = _repository
        .listStream(
          userId: _userId,
          limit: isTable ? _pageLimit : _limit,
          request: (request ?? const TicketRequest()).copyWith(
            type: _type,
            paginationInfo: _paginationInfo,
          ),
        )
        .listen(_parseListSub);
  }

Need to stop the propagation on the presentation side.

All volunteers can add their vehicles used for transporting the refugees to certain destinations.
This includes the following features:

• add vehicle;
• view vehicle;
• edit vehicle;
• delete vehicle;
• list the volunteer's added vehicles;