Bloodify

Implemented:

Implemented 2 Main Screens:

Institution Home Screen: A scrollable screen that can be updated by pulling down. Contains all requests of the institution Each request can be clicked on to redirect to transaction screen

Institution Event Screen A scrollable screen that can be updated by pulling down. Contains all events by the institution Each event can be clicked on to redirect to transaction screen Have an add button that can be clicked to redirect to create event

Also added the new Navbar for institution

Added the following models (will be merged later with Saber and Karim models):

Event
Transaction

Added some fonts, colors, styles in shared directory to be used across the application.

create UI for a transaction from and to the institute and through a post

1. user can donate to another user through the post and the institute confirms it

API

2. user can donate to an institute through

API

3. institute can give blood bags to user

API

Implemented the 3 different transaction types:

User to User donation
Institution to User donation
User to Institution donation

Details:

3 different reposotries are created (one for each transaction type) and instead of relying on the repostory interface (the one that implements the jpa repo) a new layer is added ( data access object aka dao) that helps in filtering as well as ""catching exception thrown by the repo**
A single service is created (that uses the 3 mentioned daos)
A single controller is created (that uses the menetioned service)
In order to combine the request object and the data needed from the JSON web token (aka jwt) a dto is created containing the institution email as well as the request fields
Mapping the request object to dto is done by a dedicated dto mapper
In order to transfer the dto to the model entities, model mappers are used (annotated with service)
Different exception are thrown (found in exceptions/transactionexceptions directory) to reflect potential problems that might in the different layers
A single reponse is created (TransactionResponse) that has a boolean (state) -> true in case of accepted transaction and false o.w. and a message (String) -> contains (Successful Transaction!) in case of accepted transaction or different set of message that reflect the problem happened during applying the transaction

Note: User to User is not tested using postman since it depends on the existence of post entity as well as its service. Therefore its testing is delayed until merging

Implemented

Saving user requests for blood (posts) in the DB
The user is able to update, and delete a post
Deleting posts after as soon as its expiry date has come using a scheduled operation
Deleting posts after as soon as required number of bags is collected
Searching for compatible blood types to a certain blood type in institutions

Changes in the design

Changing the hierarchy of decorator pattern so that RHD class wraps Blood Group class as it is easier in implementation
Using Blood Group as Singleton

Testing

Junit and Mockito for unit and component testing
Postman testing for API testing

Blood Finding UI

Institution search ui was added: A user can search for blood bags in institutions before creating a donation request, the institution name and location and distance and available blood bags are displayed.
Blood donation form was added: The user selects the reciepient blood type, the number of blood bags needed (max 4 per post), the expiration date (max 30 days) of the request, the institution in which the donation will take place.
api needs to be implemented.
Better naming might be done.

Implemented the event part of instituion:

Allow the creation of events
Allow the deletion of events (every 2 minutes deleteion is done to expired events)
Allow to get all the active events of an instituion

Note: some postman tests will fail due to the fact that this branch doesn't contain the transaction part

event creation in front

location pick

start date

working hours

transaction done

use case

Chat Functionality:

Chat model: messages are presisted in the database.

Notification System:

create notification history for each user
Send notification to user device if user login

Forget Password:

Email Service
PasswordResetRepo User can request to change his password, a 4-digit code is sent to him through email, then the user is asked to enter the 4 digits code and new password in order to change his password.

(New classes and method are in yellow)

Institution Statistics:

It contains 5 packages: 3 services, a common package for wrapping and an interfaces package the 3 services we collect statistics about are:

Institutions available blood bags counts for each blood type
Required blood bags in Posts with their numbers concerning a specific institution.
Transactions on blood bags types with their numbers, for: user to institution transaction (the only source for blood bags that enters institutions), and all 3 types of transactions (user -> user, user -> institution, institution ->user)