change readme file in services

docs/README.md

@@ -37,7 +37,7 @@ Below is the UML diagram showing all database relationships across the microserv
 - Microservices architecture for modularity and scalability
 - RabbitMQ for asynchronous communication between services
 - Secure and anonymous voting flow
-- Admin access for managing meetings and exporting reports
+- Admin access for managing meetings
 
 ---
 ### User Stories

housing_association/README.md

@@ -1,10 +1,13 @@
 # Housing Association Service
-The Housing Association Service manages housing associations and their residents.
-It allows adding new residents and retrieving housing details. 
-It also handles sending meeting invitations to residents using RabbitMQ, ensuring all members of a housing association are notified about upcoming meetings.
-The service can generate reports combining housing and resident information, providing an overview of each resident within their housing association.
-Data is stored in a relational database with associations linking residents to their housing units.
-The RabbitMQ integration lets invitations be published to the messaging system so other services such as the Invitation Service can process them.
-
+The Housing Association Service manages housing associations and their residents. 
+It supports adding new residents and retrieving housing details. 
+The service also sends meeting invitations to residents using RabbitMQ, 
+ensuring all members of a housing association are notified about upcoming meetings. 
+The RabbitMQ integration allows invitations to be published to the messaging system so
+other services, such as the Invitation Service, can process them.
+The Housing Association Service also plays a key role when generating a custom 
+report for each participant, by providing the required information to the Report Service.
 ### Database: 
+Data is stored in a relational database, with clear associations
+linking residents to their housing units.
 <img src="docs/images/database/housing_association.png" alt="Housing Association Diagram" width="500">

invitation/README.md

@@ -7,4 +7,7 @@ When an invitation is accepted, the resident is added as a participant in the me
 The service also communicates with other microservices and uses RabbitMQ to send notifications and distribute invitations to residents.
 
 ### Database: 
+Each invitation has a unique code as its primary key.
+The residents table is managed by the Housing Service, 
+while the meetings table belongs to the Meeting Service.
 <img src="docs/images/database/invitation.png" alt="Housing Association Diagram" width="500">

meeting/README.md

@@ -4,7 +4,6 @@ It handles adding participants, tracking meeting status, and starting question r
 The service provides meeting details to the frontend and other microservices, allowing participants to join, vote,
 and receive notifications. It communicates with the Voting and Housing services to start voting sessions and send invitations,
 and uses RabbitMQ to publish events such as participants being added or meetings ending. 
-The database stores meeting information, including name, description, start and end times, status, housing cooperative, and participant records.
-
 ### Database
+The database stores meeting information, including name, description, start and end times, status, housing cooperative, and participant records.
 <img src="docs/images/database/meeting.png" alt="Housing Association Diagram" width="500">

notification/README.md

@@ -1,11 +1,17 @@
 # Notification Service
 The Notification Service manages notifications for residents. 
-It receives messages from other services, such as voting or meetings, and stores them in the database. 
+It receives messages from voting, invitation and report service and stores them in the database. 
 Residents can retrieve all their notifications through the API, and these notifications are shown in the frontend. 
 The service uses RabbitMQ to handle incoming messages asynchronously,
 converting them into notification records that include the message content, the resident ID, 
 related meeting, and timestamp.
 
 
 ### Database:
+The notification table stores messages sent to residents 
+about specific meetings, including a unique id, the residentId, 
+the message content, a timestamp, and the related meetingId.
+The resident table belongs to the Housing Service, while the meeting table is
+managed by the Meeting Service.
+
   <img src="docs/images/database/notification.png" alt="Notification Diagram" width="500">

report/README.md

@@ -6,6 +6,6 @@ housing information, and voting results. The database stores essential informati
 including the meeting ID, name, description, start and end times, housing cooperative, and participant details.
 
 ### Database:
-
+The meeting table belongs to the Meeting Service, the housing_cooperative and resident tables are managed by the Housing Service, and the participants table is provided by the Voting Service.
 <img src="../docs/images/database/report.png" alt="Report Diagram" width="500">
 

voting/README.md

@@ -3,8 +3,8 @@ The Voting Service handles all voting functionality for meetings.
 It manages backend communication with other microservices and frontend requests from participants.
 When a meeting starts, it creates new voting sessions and provides voting questions, options, and status to participants.
 The service records votes, tracks whether voting is open or closed, and notifies the Meeting and Notification services of updates. 
-It also generates voting reports, which is used by the Report microservice.
+It also provides voting result, which is used by the Report microservice.
+### Database: 
 The database stores voting sessions, participant votes, voting status, and links to meetings and participant
 
-### Database: 
   <img src="docs/images/database/voting.png" alt="Voting Diagram" width="500">