madt1m/npmbeer-pedibus

Your new Pedibus system, warmly brought to you folks by NapalmBeer© group.

npmbeer-pedibus

Your new Pedibus system, warmly brought to you folks by NapalmBeer© group.

npmbeer-pedibus's Issues

Display Line Runs in Tabs

This issue may require the reservations to be done on its last step. Requires #17 .

On the first part what must be done is to show (i.e. focus ) the first run available for the current line: this means deciding the direction (outward vs back), prepare the relative tabs for each run and finally set the focus on the tab having the (temporally speaking) closest run.
Finally, data must be correctly displayed inside the stops list, which also includes reservation data.

All of this is needed to meet a requirement for the lab:

L’applicazione di default presenta la corsa temporalmente più vicina.

Reservations Allowed After Stop Time

There is an issue with the reservations which can be booked even after the stop time as passed: this shouldn't be possible as it is specified in the requirements sheet.

Integrate PR 17 content with PR 18

This mostly means that the DataService will have to call the http.get methods inside its constructor, subscribe to them and map the received arrays into other more comfortable objects. Currently, only Lines have a "comfort" class where the Stops are handled as objects themselves (#17 ) and therefore mapped (see DataService.getLines()).
Whatsmore, something similar must be done for a Reservation class, which will have an internal Stop object.
Summing up:

• Implement OnInit Interface in DataService
• Move http.get().subscribe( ... ) (#18 ) to ngOnInit
• Move code to build Line[] currently present in getLines() (#17 ) inside previous subscribe method
• have getLines() return a this.lines$ observable
• Create a Reservation class inside app/models and do something similar. => should be authenticated? or not yet probably.

An example could be:

this.http.get<Line[]>(".url").subscribe(_lines =>{
    /*build lines: Line[] array */
    this.lines$ = of(lines);
});

Line Stops

Eventually, it would be better to shift the stops from the outward/back lists to a direct property of the line, i.e.:

line:

• stops: [{name: "A", position:{coords}}, {name: "B", position: {coords}}, etc...]
• outward: [["8:00", "8:30", ..., "9:00"], ]
• back: [["12:00", ... , "13:00"], ["16:00", ... ,"17,00"]]

However we will do this only if time allows it as a last thing

Web Socket Implementation (especially for position in real time)

Is this relevant?

https://spring.io/guides/gs/messaging-stomp-websocket/

User Presence Management

Possibily Requires to implement a User class.

Implementation of the system handling the presence of the user: each user's name will be displayed inside the stops list, by clicking or touching the user's name, we will be able to toggle it's presence at the stop -- which also means updating the db.. ?

A present user must be highlighted in some way. Furthermore we probably need a way to tell subscribed users apart. This is to meet the project requirement:

Per comodità la selezione dei bambini “presenti” viene fatta a partire dall’elenco dei bambini iscritti dove quelli prenotati sono evidenziati per distinguerli dagli altri e individuarli più comodamente.
È comunque possibile segnare come presente un bambino, anche se non prenotato (nel caso i
genitori non l’avessero segnato per distrazione).

This makes me think that we should include a button to add a child on the spot, which will also require to track the parent, possibly? must be discussed.

User profile changes endpoints (if needed, take this on and check it)

Which changes are we going to support in the user profile?

Reservation Service

Shift Related stuff completion (Repo, model, controller, service, dto ...)

Does anyone already have a model ready here? Maybe a port of the frontend Shift class would be a good idea:

export class Shift {

  dateAndTime: LocalDateTime;
  lineName: string;
  direction: string;
}

User service

Reservation Related Stuff

Let's discuss this a little bit -- dave, something you believe we should wanna add to the current reservation endpoints?

Notification system (this one might be tougher)

I guess this can be completed in steps: we can start sending to the clients a basic notification about a basic thing, just to lay down the basis.

PS -- doesn't this depend on the WebSocket task?