The relationship between the three tables—Administrator, AuthenticationEntity, and

Entity

Administrator:

The Administrator entity is linked to the AuthenticationEntity in a one-to-one

relationship. This means that each administrator has exactly one authentication record, and
each authentication record belongs to exactly one administrator.

A detailed documentation for a class within the com.abaudit.rest.app package of the iaudits-
app submodule,

Package: com.abaudit.rest.app
Submodule: iaudits-app
Type: REST Controller

The AuditorAppRest class is a Spring @RestController that manages HTTP requests related
to auditors and their projects. This controller provides functionality for:

1. Retrieving projects associated with auditors.

2. Updating auditor details.
3. Uploading avatars for auditors.

Annotations and Dependencies

@RestController: Marks the class as a REST controller, ensuring that each method returns
data.

@RequestMapping(value = "/api/auditor"): Sets the base path for all endpoints defined in
this controller.

Injected Services and Validators

 AuditorProjectServiceValidator: Validates requests for retrieving auditor projects.

 AuditorServiceValidator: Validates requests for updating auditor details and
uploading avatars.
 GetService getAppProjectsByAuditorService: Handles logic for retrieving projects
associated with auditors.
  PutService putAppAuditorService: Manages logic for updating auditor details.
 PostService postAppAuditorAvatarService: Handles logic for uploading auditor
avatars.

Methods

1. getAppProjectsByAuditorService

 Endpoint: GET /api/auditor/project

2. Description: Retrieves projects associated with an auditor

putAppAuditorService

 Endpoint: PUT /api/auditor

 Description: Updates auditor details.

3. postAppAuditorAvatarService

 Endpoint: POST /api/auditor/avatar

 Description: Uploads an avatar for an auditor.

REST API :

 GET /api/auditor/project

Controller Called: @RestController

@RequestMapping(value = "/api/auditor")
public class AuditorAppRest

 Controller: AuditorAppRest

Controller Method: getAppProjectsByAuditorService : @ResponseBody

public Object getAppProjectsByAuditorService(@RequestHeader
HttpHeaders headers, HttpServletRequest request,
HttpServletResponse response) {

Validator Called:

Validator: AuditorProjectServiceValidator : @Autowired

private AuditorProjectServiceValidator
auditorProjectServiceValidator;
  Validator Method: validateGet : boolean validateGet(HttpServletRequest
request, Map<String, String> pathParamsMap) throws Exception;

Service Called:

 Service: GetAppProjectsByAuditorService:
@Service("getAppProjectsByAuditorService")
 public class GetAppProjectsByAuditorService implements GetService {

Service Method: process : @Override

public Object process(HttpHeaders header, HttpServletRequest request,
HttpServletResponse response,
Map<String, String> pathParamsMap) {

REST API :

 PUT /api/auditor

Controller Called:

 Controller: AuditorAppRest
 Controller Method: putAppAuditorService

Validator Called:

 Validator: AuditorServiceValidator
 Validator Method: validatePut

Service Called:

 Service: PutAppAuditorService
 Service Method: process

REST API :

 POST /api/auditor/avatar
Controller Called:

 Controller: AuditorAppRest
 Controller Method: postAppAuditorAvatarService

Validator Called:

 Validator: AuditorServiceValidator
 Validator Method: validatePost

Service Called:

 Service: PostAppAuditorAvatarService
 Service Method: process

1. Retrieve Administrator Details

API Endpoint /api/admin/administrator
HTTP Method GET
Description Retrieving administrator details.
Controller called : AuditorAppRest @RestController
@RequestMapping(value = "/api/auditor")
public class AuditorAppRest {

public Object
Method called: getAppProjectsByAuditorService(@RequestHeade
getAppProjectsByAuditorService r HttpHeaders headers, HttpServletRequest
request,
HttpServletResponse
response) {

Validator called : @Autowired

AuditorProjectServiceValidator private AuditorProjectServiceValidator
auditorProjectServiceValidator;

@Service("auditorProjectServiceValidator")
Validator Impl: public class
AuditorProjectServiceValidatorI
AuditorProjectServiceValidatorImpl extends
mpl
AbstractValidator implements
AuditorProjectServiceValidator {

Interface called :
public interface RestValidator {
RestValidator
 Method called : boolean validateGet(HttpServletRequest
validateGet request, Map<String, String> pathParamsMap)
throws Exception;
Service called : @Autowired
GetService @Qualifier("getAdministratorService")
protected GetService
getAdministratorService;

Method called : @Override

process public Object process(HttpHeaders
header, HttpServletRequest request,
HttpServletResponse response,
Map<String, String>
pathParamsMap) {

2. Creating new administrator entries.

API Endpoint /api/admin/administrator
HTTP Method POST
Description Récupère les détails de l'administrateur.
Controller called : AuditorAppRest @RestController
@RequestMapping(value = "/api/auditor")
public class AuditorAppRest {

Method called: public Object

postAdministratorService postAdministratorService(@RequestHeader
HttpHeaders headers, HttpServletRequest
request,
HttpServletResponse
response, @RequestBody Optional<JsonNode>
node)

Validator called : @Autowired

AuditorProjectServiceValidator private AuditorProjectServiceValidator
auditorProjectServiceValidator;

@Service("auditorProjectServiceValidator")
Validator Impl: public class
AuditorProjectServiceValidatorI
AuditorProjectServiceValidatorImpl extends
mpl
AbstractValidator implements
AuditorProjectServiceValidator {

Interface called :
public interface RestValidator {
RestValidator
 Method called : boolean validatePost(HttpServletRequest
validateGet request, Map<String, String> pathParamsMap)
throws Exception;
Service called : @Autowired
PostService @Qualifier("postAdministratorService")
protected PostService
postAdministratorService;

Method called : @Override

process public Object process(HttpHeaders
header, HttpServletRequest request,
HttpServletResponse response,
Map<String, String>
pathParamsMap) {

3. Updating existing administrator details.

API Endpoint /api/admin/administrator

HTTP Method PUT
Description Updating existing administrator details.
Controller called : AuditorAppRest @RestController
@RequestMapping(value = "/api/auditor")
public class AuditorAppRest {

Method called: public Object

putAdministratorService putAdministratorService(@RequestHeader
HttpHeaders headers, HttpServletRequest
request,
HttpServletResponse
response, @RequestBody Optional<JsonNode>
node)

Validator called : @Autowired

AuditorProjectServiceValidator private AuditorProjectServiceValidator
auditorProjectServiceValidator;

@Service("auditorProjectServiceValidator")
Validator Impl: public class
AuditorProjectServiceValidatorI
AuditorProjectServiceValidatorImpl extends
mpl
AbstractValidator implements
AuditorProjectServiceValidator {
 Interface called :
RestValidator public interface RestValidator {

Method called : boolean validatePost(HttpServletRequest

validatePut request, Map<String, String> pathParamsMap)
throws Exception;
Service called : @Autowired
PutService @Qualifier("putAdministratorService")
protected PutService
putAdministratorService;

Method called : @Override

process public Object process(HttpHeaders
header, HttpServletRequest request,
HttpServletResponse response,
Map<String, String>
pathParamsMap) {

4. Deleting administrators.
API Endpoint /api/admin/administrator
HTTP Method DELETE
Description Updating existing administrator details.
Controller called : AuditorAppRest @RestController
@RequestMapping(value = "/api/auditor")
public class AuditorAppRest {

Method called: public Object

deleteAdministratorService deleteAdministratorService(@RequestHeader
HttpHeaders headers, HttpServletRequest
request,
HttpServletResponse
response, @RequestBody Optional<JsonNode>
node)

Validator called : @Autowired

AuditorProjectServiceValidator private AuditorProjectServiceValidator
auditorProjectServiceValidator;

@Service("auditorProjectServiceValidator")
Validator Impl: public class
AuditorProjectServiceValidatorI
AuditorProjectServiceValidatorImpl extends
mpl
AbstractValidator implements
AuditorProjectServiceValidator {
 Interface called :
RestValidator public interface RestValidator {

boolean validateDelete(HttpServletRequest
Method called : request, Map<String, String> pathParamsMap)
validateDelete
throws Exception;
Service called : @Autowired
DeleteService
@Qualifier("deleteAdministratorService")
protected DeleteService
deleteAdministratorService;

Method called :
process @Override
public Object process(HttpHeaders
header, HttpServletRequest request,
HttpServletResponse response,
Map<String, String>
pathParamsMap) {

Detailed Flow

Controller (AuditorAppRest):

 Each method in this controller calls a respective validator (via dependency injection) to
validate the request parameters before delegating processing to the appropriate service.

Validator (AuditorServiceValidator):

 Defines validation rules for PUT and POST requests.

 The validator AuditorProjectServiceValidator is used for GET requests

Service (GetAppProjectsByAuditorService):

 Handles GET requests for retrieving projects by auditor, accessing the DAO to fetch
the data.

Service (PutAppAuditorService):

 Manages the update of auditor information via the process method.

Service (PostAppAuditorAvatarService):

 Handles adding an auditor's avatar through the process method, which processes and
saves files to a specific directory.

The FindingAppRest controller handles HTTP requests for managing findings in the audit
application. The controller provides functionality for:

1. Creating a new finding.

2. Retrieving existing findings.
3. Updating details of a specific finding.
4. Deleting a finding.

Annotations and Dependencies

@RestController: Marks the class as a REST controller.

@RequestMapping(value = "/api/finding"): Sets the base path for all the endpoints defined
in this controller.

Injected Services and Validators

FindingServiceValidator: Validates requests related to finding operations (creation, update,

and retrieval).
PostFindingService: Handles the logic for creating a new finding.
GetFindingService: Handles the logic for retrieving finding details.
PutFindingService: Manages the logic for updating finding information.
DeleteFindingService: Handles the logic for deleting a finding.

Methods

1. postFinding

Endpoint: POST /api/finding

2. getFindingById

Endpoint: GET /api/finding/{id}

3. putFinding

Endpoint: PUT /api/finding/{id}

 4. deleteFinding

Endpoint: DELETE /api/finding/{id}

REST API Documentation for FindingAppRest

1. GET /api/finding/test/init

 Controller Called:
o Controller: FindingAppRest
o Controller Method: getAppFindingTestInitService
 Validator Called:
o Validator: FindingTestInitServiceValidator
o Validator Method: validateGet
 Service Called:
o Service: GetAppFindingTestInitService
o Service Method: process

2. GET /api/finding

 Controller Called:
o Controller: FindingAppRest
o Controller Method: getAppFindingService
 Validator Called:
o Validator: FindingServiceValidator
o Validator Method: validateGet
 Service Called:
o Service: GetAppFindingService
o Service Method: process

3. POST /api/finding

 Controller Called:
o Controller: FindingAppRest
o Controller Method: postAppFindingService
 Validator Called:
o Validator: FindingServiceValidator
 o Validator Method: validatePost
 Service Called:
o Service: PostAppFindingService
o Service Method: process

4. PUT /api/finding/auditor

 Controller Called:
o Controller: FindingAppRest
o Controller Method: putAppFindingAuditorService
 Validator Called:
o Validator: FindingAuditorServiceValidator
o Validator Method: validatePut
 Service Called:
o Service: PutAppFindingAuditorService
o Service Method: process

5. PUT /api/finding

 Controller Called:
o Controller: FindingAppRest
o Controller Method: putAppFindingService
 Validator Called:
o Validator: FindingServiceValidator
o Validator Method: validatePut
 Service Called:
o Service: PutAppFindingService
o Service Method: process

6. DELETE /api/finding

 Controller Called:
o Controller: FindingAppRest
o Controller Method: deleteAppFindingService
 Validator Called:
 o Validator: FindingServiceValidator
o Validator Method: validateDelete
 Service Called:
o Service: DeleteAppFindingService
o Service Method: process

Detailed Flow

 Controller (FindingAppRest): Manages requests related to findings.

 Validators:
o FindingServiceValidator: Used for validating GET, POST, PUT, and
DELETE requests.
o FindingTestInitServiceValidator: Used for validating the initialization GET
request for findings.
o FindingAuditorServiceValidator: Used for validating PUT requests related
to auditors.
 Services:
o GetAppFindingTestInitService: Retrieves initial data for findings.
o GetAppFindingService: Retrieves existing findings.
o PostAppFindingService: Handles creation of new findings.
o PutAppFindingService: Updates existing findings.
o PutAppFindingAuditorService: Updates auditor-related data for findings.
o DeleteAppFindingService: Manages deletion of findings.
The FindingCommentAppRest class is a Spring @RestController that manages HTTP
requests related to comments on findings. The controller provides functionality for:

1. Creating new comments related to findings.

2. Deleting existing comments related to findings.

Annotations and Dependencies

 @RestController: Marks the class as a REST controller, ensuring that each method
returns data, typically in JSON format.
 @RequestMapping(value = "/api/finding/comment"): Sets the base path for all
endpoints defined
 in this controller.

Injected Services and Validators

 FindingCommentServiceValidator: Validates requests for creating and deleting

comments.
 DeleteService deleteAppFindingCommentService: Handles the logic for deleting
comments related to findings.
 PostService postAppFindingCommentService: Manages the logic for creating new
comments.

Methods

1. postAppFindingCommentService
o Endpoint: POST /api/finding/comment
o Handles the creation of new comments.

2. deleteAppFindingCommentService
o Endpoint: DELETE /api/finding/comment
o Manages the deletion of existing comments.
The FindingContactAppRest class is a Spring @RestController that manages HTTP
requests related to finding contacts. This controller provides functionality for :

1. Retrieving initial contact data related to findings.

2. Creating new contacts associated with findings.
3. Updating existing contacts related to findings.
4. Deleting contacts associated with findings.

Annotations and Dependencies

@RestController: Marks the class as a REST controller.

@RequestMapping(value = "/api/finding/contact"): Sets the base path for all endpoints

defined in this controller.

Injected Services and Validators

 FindingContactServiceValidator: Validates requests for creating, updating, and

deleting contacts to ensure they meet the required criteria.
 FindingContactInitServiceValidator: Validates requests for retrieving initial contact
data.
 GetService getAppFindingContactInitService: Handles logic for retrieving initial
contact data.
 PostService postAppFindingContactService: Manages logic for creating new
contacts.
 PutService putAppFindingContactService: Handles logic for updating existing
contacts.
 DeleteService deleteAppFindingContactService: Manages the logic for deleting
contacts.

Methods

1. getAppFindingContactInitService
o Endpoint: GET /api/finding/contact/init
 o Description: Retrieves initial contact data for findings.
2. postAppFindingContactService
o Endpoint: POST /api/finding/contact
o Description: Handles the creation of new contacts. Validates the incoming
request and processes the contact creation if valid.
3. putAppFindingContactService
o Endpoint: PUT /api/finding/contact
o Description: Manages the updating of existing contacts. Validates the request
and processes the update if valid.
4. deleteAppFindingContactService
o Endpoint: DELETE /api/finding/contact
o Description: Handles the deletion of existing contacts. Validates the request
and processes the deletion if valid.

REST API:

GET /api/finding/contact/init

 Controller Called:
o Controller: FindingContactAppRest
o Controller Method: getAppFindingContactInitService
 Validator Called:
o Validator: FindingContactInitServiceValidator
o Validator Method: validateGet
 Service Called:
o Service: GetAppFindingContactInitService
o Service Method: process

REST API:

POST /api/finding/contact

 Controller Called:
o Controller: FindingContactAppRest
o Controller Method: postAppFindingContactService
 Validator Called:
 o Validator: FindingContactServiceValidator
o Validator Method: validatePost
 Service Called:
o Service: PostAppFindingContactService
o Service Method: process

REST API

PUT /api/finding/contact

 Controller Called:
o Controller: FindingContactAppRest
o Controller Method: putAppFindingContactService
 Validator Called:
o Validator: FindingContactServiceValidator
o Validator Method: validatePut
 Service Called:
o Service: PutAppFindingContactService
o Service Method: process

REST API

DELETE /api/finding/contact

 Controller Called:
o Controller: FindingContactAppRest
o Controller Method: deleteAppFindingContactService
 Validator Called:
o Validator: FindingContactServiceValidator
o Validator Method: validateDelete
 Service Called:
o Service: DeleteAppFindingContactService
o Service Method: process

Detailed Flow
Controller (FindingContactAppRest): Manages requests related to finding contacts.

Validators:

o FindingContactInitServiceValidator: Used for validating GET requests.

o FindingContactServiceValidator: Used for validating POST, PUT, and
DELETE requests.

Services:

o GetAppFindingContactInitService: Retrieves initial finding contact data.

o PostAppFindingContactService: Handles creation of new finding contacts.
o PutAppFindingContactService: Updates existing finding contacts.
o DeleteAppFindingContactService: Manages deletion of finding contacts.
Iaudits-app-model
Here is a relational database table design for the Finding model, representing how the data
would be structured in a typical SQL database schema.

Column Name Data Type Description

finding_key String Unique key for the finding.
finding_workflow_step_key String Foreign key referencing the workflow step
table.
finding_response_workflow_step_ke String Foreign key referencing the response
y workflow step.
label String Title or label of the finding (encrypted at the
application level).
description TEXT Detailed description of the finding
(encrypted).
recommendation TEXT Recommendations for actions (encrypted).
response TEXT Response to the finding (encrypted).
resume TEXT Summary of the finding (encrypted).
risk TEXT Associated risk (encrypted).
comment TEXT Additional comments (encrypted).
deadline_date DATETIME Deadline for addressing the finding.
progress INT Progress status of the finding (e.g., 0-
100%).
finding_category_key String Foreign key referencing the finding
category table.
finding_classification_level_key String Foreign key referencing classification level
table.
code String Unique code for the finding (encrypted).
auditor_key String Foreign key referencing the auditor.
created_at TIMESTAMP Timestamp when the finding was created.
updated_at TIMESTAMP Last update timestamp.

Key Tables and Relationships

1. Finding Table: This table represents audit findings. Each finding is linked to various
workflows, categories, and classifications. It contains critical information such as
 labels, descriptions, recommendations, and deadlines. It also references various
entities like contacts, workflow steps, and classifications.
o Attributes:
 findingKey (Primary Key): Unique identifier for the finding.
 label: A description or title for the finding.
 recommendation, response, resume: Different fields related to the
finding’s details.
 findingCategoryKey (Foreign Key): References the FindingCategory
table.
 findingClassificationLevelKey (Foreign Key): References the
FindingClassificationLevel table.
 auditorKey (Foreign Key): References the Contact table.
 progress: An integer to track the progress of the finding.
2. FindingWorkflowStep Table: Represents the workflow steps related to a finding.
This table is essential for tracking the various stages a finding goes through in the
audit process.
o Attributes:
 findingWorkflowStepKey (Primary Key): Unique identifier for a
workflow step.
 findingKey (Foreign Key): References the Finding table.
 status: Status of the workflow step.
3. FindingResponseWorkflowStep Table: Handles the response workflows for each
finding, providing a detailed track of how the audit team and other stakeholders
respond to each finding.
o Attributes:
 findingResponseWorkflowStepKey (Primary Key).
 findingKey (Foreign Key): Links to the corresponding finding.
 responseDetails: Information on the response.
4. Contact Table: Represents people or roles that are responsible for the findings, such
as auditors, managers, or any stakeholders involved in the process.
o Attributes:
 contactKey (Primary Key): Unique identifier for each contact.
 name, role: Details of the person or role.
 5. FindingCategory Table: This table stores the different categories that each finding
can be classified under.
o Attributes:
 findingCategoryKey (Primary Key).
 categoryName: The name of the category.
6. FindingClassificationLevel Table: Stores classification levels (e.g., critical, major,
minor) for findings, which help in prioritizing the audit findings.
o Attributes:
 findingClassificationLevelKey (Primary Key).
 classificationLevel: Level of classification.
7. FindingComment Table: Stores comments related to a finding.
o Attributes:
 findingCommentKey (Primary Key).
 findingKey (Foreign Key).
 commentText: Content of the comment.
8. FindingResponseComment Table: Stores the comments related to the response
workflow of the finding.
o Attributes:
 findingResponseCommentKey (Primary Key).
 findingResponseWorkflowStepKey (Foreign Key).
 responseCommentText: Text of the response comment.

ER Diagram Overview

The ER diagram would contain the following relationships:

 One-to-Many:
o A finding can have multiple workflow steps (FindingWorkflowStep).
o A finding can have multiple response workflow steps
(FindingResponseWorkflowStep).
o A finding can have multiple contacts and comments (FindingComment,
Contact).
 Many-to-One:
o Multiple findings can belong to one category (FindingCategory).
 o Multiple findings can be classified under one classification level
(FindingClassificationLevel).

ER Diagram Key Relationships

 Finding ← One-to-Many → FindingWorkflowStep

 Finding ← One-to-Many → FindingResponseWorkflowStep
 Finding ← Many-to-One → FindingCategory
 Finding ← Many-to-One → FindingClassificationLevel
 Finding ← One-to-Many → FindingComment
 FindingResponseWorkflowStep ← One-to-Many → FindingResponseComment