refactor(api): Made events central to workspace

[rajdip-b]

Type

enhancement

---

Description

• Refactored event fetching in tests to use EventService directly, improving test reliability.
• Added comprehensive tests for event creation across various actions (workspace, project, secret, variable, approval).
• Updated services to ensure event creation is part of the transactional operations.
• Simplified the event creation process in the codebase by directly using new event model fields.
• Updated the Prisma schema and added migration scripts for the event model refactoring.

---

Changes walkthrough

Relevant files

Enhancement

14 files event.e2e.spec.ts Refactor Event E2E Tests and Add New Test Cases                    apps/api/src/event/event.e2e.spec.ts Refactored event fetching in tests to use direct service calls instead of HTTP requests. Added tests for fetching events by source and severity. Implemented tests for creating events for various actions like workspace creation, project creation, and more. +348/-357 workspace.e2e.spec.ts Refactor Workspace Controller Tests and Add Event Assertions apps/api/src/workspace/workspace.e2e.spec.ts Refactored workspace controller tests to use EventService for fetching events. Added tests for workspace events like workspace creation, update, and role events. +167/-222 project.e2e.spec.ts Refactor Project Controller Tests with Event Assertions    apps/api/src/project/project.e2e.spec.ts Refactored project controller tests to use EventService for event assertions. Added tests for project creation, update, and deletion events. +58/-65  secret.e2e.spec.ts Refactor Secret Controller Tests and Add Event Assertions apps/api/src/secret/secret.e2e.spec.ts Refactored secret controller tests to use EventService. Added tests for secret addition, update, and deletion events. +51/-51  approval.e2e.spec.ts Refactor Approval Controller Tests with Event Assertions  apps/api/src/approval/approval.e2e.spec.ts Refactored approval controller tests to use EventService. Added tests for approval creation, update, approval, and deletion events. +101/-1  variable.e2e.spec.ts Refactor Variable Controller Tests and Add Event Assertions apps/api/src/variable/variable.e2e.spec.ts Refactored variable controller tests to use EventService. Added tests for variable addition, update, and deletion events. +51/-51  workspace.service.ts Ensure Event Creation in Workspace Service Methods              apps/api/src/workspace/service/workspace.service.ts Updated WorkspaceService methods to await createEvent calls, ensuring events are created as part of the transaction. +30/-34  environment.e2e.spec.ts Refactor Environment Controller Tests with Event Assertions apps/api/src/environment/environment.e2e.spec.ts Refactored environment controller tests to use EventService. Added tests for environment addition, update, and deletion events. +57/-45  event.service.ts Refactor Event Service for Simplified Event Fetching          apps/api/src/event/service/event.service.ts Refactored EventService to simplify event fetching logic and support filtering by source. +30/-96  workspace-role.e2e.spec.ts Refactor Workspace Role Controller Tests with Event Assertions apps/api/src/workspace-role/workspace-role.e2e.spec.ts Refactored workspace role controller tests to use EventService. Added tests for workspace role creation, update, and deletion events. +64/-1    create-event.ts Simplify Event Creation with Direct Model Field Usage        apps/api/src/common/create-event.ts Updated createEvent function to directly use new event model fields, simplifying the event creation process. +13/-79  schema.prisma Update Prisma Schema for Event Model Refactoring                  apps/api/src/prisma/schema.prisma Updated the Prisma schema to reflect changes in the event model, removing unused relations and adding new fields. +8/-44    migration.sql Database Migration for Event Model Refactoring                      apps/api/src/prisma/migrations/20240308054256_refactor_event/migration.sql Migration SQL script for refactoring the event model in the database. +85/-0    migration.sql Final Database Migration Adjustments for Event Model          apps/api/src/prisma/migrations/20240308060811_/migration.sql Additional migration SQL script for final adjustments to the event model. +14/-0

---

✨ PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[codiumai-pr-agent-free]

PR Description updated to latest commit (cd2a853)

[codiumai-pr-agent-free]

PR Review

⏱️ Estimated effort to review [1-5]	4, because the PR involves multiple significant changes across various components, including backend logic, database schema updates, and test modifications. The removal of certain features (e.g., API key events) and the refactoring of the event creation process require careful review to ensure no functionality is lost or incorrectly altered. Additionally, the introduction of new event types and modifications to existing ones necessitate a thorough examination of the event handling logic. The complexity is further increased by the database migration scripts that need to be reviewed for correctness and potential data migration issues.
🧪 Relevant tests	Yes
🔍 Possible issues	Possible Data Loss: The migration script removes certain columns and enum values from the database. If any of these columns or enums are still in use or contain critical data, this could result in data loss.
	Refactoring Risks: The significant refactoring of the event creation and handling process could introduce bugs or alter the behavior of the system in unintended ways. It's crucial to ensure that all scenarios are adequately tested, including edge cases.
	Database Migration Concerns: The database migration scripts need careful review to ensure they correctly handle the schema changes without causing data loss or corruption. Special attention should be paid to the enum modifications and column removals.
🔒 Security concerns	No

---

✨ Review tool usage guide:

---

Overview:
The review tool scans the PR code changes, and generates a PR review. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.
When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

Utilizing extra instructions The review tool can be configured with extra instructions, which can be used to guide the model to a feedback tailored to the needs of your project. Be specific, clear, and concise in the instructions. With extra instructions, you are the prompter. Specify the relevant sub-tool, and the relevant aspects of the PR that you want to emphasize. Examples for extra instructions: [pr_reviewer] # /review # extra_instructions=""" In the 'possible issues' section, emphasize the following: - Does the code logic cover relevant edge cases? - Is the code logic clear and easy to understand? - Is the code logic efficient? ... """ Use triple quotes to write multi-line instructions. Use bullet points to make the instructions more readable.

How to enable\disable automation When you first install PR-Agent app, the default mode for the review tool is: pr_commands = ["/review", ...] meaning the review tool will run automatically on every PR, with the default configuration. Edit this field to enable/disable the tool, or to change the used configurations

Auto-labels The review tool can auto-generate two specific types of labels for a PR: a possible security issue label, that detects possible security issues (enable_review_labels_security flag) a Review effort [1-5]: x label, where x is the estimated effort to review the PR (enable_review_labels_effort flag)

Extra sub-tools The review tool provides a collection of possible feedbacks about a PR. It is recommended to review the possible options, and choose the ones relevant for your use case. Some of the feature that are disabled by default are quite useful, and should be considered for enabling. For example: require_score_review, require_soc2_ticket, and more.

Auto-approve PRs By invoking: /review auto_approve The tool will automatically approve the PR, and add a comment with the approval. To ensure safety, the auto-approval feature is disabled by default. To enable auto-approval, you need to actively set in a pre-defined configuration file the following: [pr_reviewer] enable_auto_approval = true (this specific flag cannot be set with a command line argument, only in the configuration file, committed to the repository) You can also enable auto-approval only if the PR meets certain requirements, such as that the estimated_review_effort is equal or below a certain threshold, by adjusting the flag: [pr_reviewer] maximal_review_effort = 5

More PR-Agent commands To invoke the PR-Agent, add a comment using one of the following commands: /review: Request a review of your Pull Request. /describe: Update the PR title and description based on the contents of the PR. /improve [--extended]: Suggest code improvements. Extended mode provides a higher quality feedback. /ask <QUESTION>: Ask a question about the PR. /update_changelog: Update the changelog based on the PR's contents. /add_docs 💎: Generate docstring for new components introduced in the PR. /generate_labels 💎: Generate labels for the PR based on the PR's contents. /analyze 💎: Automatically analyzes the PR, and presents changes walkthrough for each component. See the tools guide for more details. To list the possible configuration parameters, add a /config comment.

See the review usage page for a comprehensive guide on using this tool.

[codiumai-pr-agent-free]

PR Code Suggestions

Category	Suggestions
Maintainability	Reduce redundancy in event creation tests by using a helper function. Consider using a loop or a helper function to reduce the redundancy in event creation tests. Each test case for creating an event (e.g., WORKSPACE_CREATED, WORKSPACE_UPDATED) follows a very similar structure, differing only in the event type and possibly the user or workspace ID. You can create a helper function that takes these differing values as parameters and performs the test, thus reducing code duplication and making the test suite easier to maintain. apps/api/src/workspace/workspace.e2e.spec.ts [196-213] -it('should have created a WORKSPACE_CREATED event', async () => { - const response = await fetchEvents( - eventService, - user1, - workspace1.id, - EventSource.WORKSPACE - ) - ... -}) +function testEventCreation(eventType, user, workspaceId) { + it(`should have created a ${eventType} event`, async () => { + const response = await fetchEvents( + eventService, + user, + workspaceId, + EventSource.WORKSPACE + ) + ... + }); +} +testEventCreation(EventType.WORKSPACE_CREATED, user1, workspace1.id);
	Abstract common setup logic in tests to enhance readability and maintainability. To enhance the readability and maintainability of your test cases, consider abstracting the common setup logic into a separate function. This includes the repetitive tasks of fetching events and asserting their properties. By doing so, you can make your test cases more concise and focused on the specific conditions they are meant to test. apps/api/src/workspace/workspace.e2e.spec.ts [197-213] -const response = await fetchEvents( - eventService, - user1, - workspace1.id, - EventSource.WORKSPACE -) -const event = response[0] -expect(event).toBeDefined() +async function fetchAndAssertEvent(user, workspaceId, eventType) { + const response = await fetchEvents( + eventService, + user, + workspaceId, + EventSource.WORKSPACE + ) + expect(response.length).toBe(1) + const event = response[0] + expect(event.type).toBe(eventType) +} +await fetchAndAssertEvent(user1, workspace1.id, EventType.WORKSPACE_CREATED);
	Refactor event creation tests to reduce redundancy using a loop or function. Consider using a loop or a function to reduce the redundancy in event creation tests. Each test case for creating an event (PROJECT_CREATED, PROJECT_UPDATED, PROJECT_DELETED) follows a very similar structure. Refactoring this into a reusable function or loop can improve maintainability and reduce code duplication. apps/api/src/project/project.e2e.spec.ts [222-238] -it('should have created a PROJECT_CREATED event', async () => { - ... -}) +const eventTests = [ + { type: EventType.PROJECT_CREATED, id: undefined }, + { type: EventType.PROJECT_UPDATED, id: project1.id }, + { type: EventType.PROJECT_DELETED, id: project1.id }, +]; -it('should have created a PROJECT_UPDATED event', async () => { - ... -}) +eventTests.forEach(({ type, id }) => { + it(`should have created a ${type} event`, async () => { + const response = await fetchEvents(eventService, user1, workspace1.id, EventSource.PROJECT); + const event = response[0]; + expect(event.type).toBe(type); + if (id !== undefined) { + expect(event.itemId).toBe(id); + } else { + expect(event.itemId).toBeDefined(); + } + }); +}); -it('should have created a PROJECT_DELETED event', async () => { - ... -}) -
	Refactor secret event tests to reduce redundancy using a loop or function. Similar to the project event tests, consider refactoring the secret event tests (SECRET_ADDED, SECRET_UPDATED, SECRET_DELETED) to use a loop or a function for reducing redundancy and improving code maintainability. apps/api/src/secret/secret.e2e.spec.ts [361-377] -it('should have created a SECRET_ADDED event', async () => { - ... -}) +const secretEventTests = [ + { type: EventType.SECRET_ADDED, id: undefined }, + { type: EventType.SECRET_UPDATED, id: secret1.id }, + { type: EventType.SECRET_DELETED, id: secret1.id }, +]; -it('should have created a SECRET_UPDATED event', async () => { - ... -}) +secretEventTests.forEach(({ type, id }) => { + it(`should have created a ${type} event`, async () => { + const response = await fetchEvents(eventService, user1, workspace1.id, EventSource.SECRET); + const event = response[0]; + expect(event.type).toBe(type); + if (id !== undefined) { + expect(event.itemId).toBe(id); + } else { + expect(event.itemId).toBeDefined(); + } + }); +}); -it('should have created a SECRET_DELETED event', async () => { - ... -}) -
	Refactor approval event tests to reduce redundancy using a loop or function. For the approval event tests (APPROVAL_CREATED, APPROVAL_UPDATED, APPROVAL_APPROVED, APPROVAL_DELETED, APPROVAL_REJECTED), consider implementing a loop or a function to minimize redundancy and enhance code maintainability. This approach can streamline adding or updating tests in the future. apps/api/src/approval/approval.e2e.spec.ts [170-186] -it('should have created a APPROVAL_CREATED event', async () => { - ... -}) +const approvalEventTests = [ + { type: EventType.APPROVAL_CREATED, id: undefined }, + { type: EventType.APPROVAL_UPDATED, id: undefined }, + { type: EventType.APPROVAL_APPROVED, id: undefined }, + { type: EventType.APPROVAL_DELETED, id: undefined }, + { type: EventType.APPROVAL_REJECTED, id: undefined }, +]; -it('should have created a APPROVAL_UPDATED event', async () => { - ... -}) +approvalEventTests.forEach(({ type, id }) => { + it(`should have created a ${type} event`, async () => { + const response = await fetchEvents(eventService, user1, workspace1.id, EventSource.APPROVAL); + const event = response[0]; + expect(event.type).toBe(type); + if (id !== undefined) { + expect(event.itemId).toBe(id); + } else { + expect(event.itemId).toBeDefined(); + } + }); +}); -it('should have created a APPROVAL_APPROVED event', async () => { - ... -}) - -it('should have created a APPROVAL_DELETED event', async () => { - ... -}) - -it('should have created a APPROVAL_REJECTED event', async () => { - ... -}) -
	Extract event creation logic into a separate method. To improve code maintainability, consider extracting the event creation logic into a separate method. This will reduce duplication and centralize event creation, making the code easier to manage and update. apps/api/src/workspace/service/workspace.service.ts [114] -await createEvent( +await this.createWorkspaceEvent( + // Event details +);
	Extract validation logic into separate methods for better readability. To improve code readability and maintainability, consider extracting the validation logic for severity and source into separate private methods within the EventService class. apps/api/src/event/service/event.service.ts [19-25] -if (severity && !Object.values(EventSeverity).includes(severity)) { - throw new BadRequestException('Invalid "severity" value') +private validateSeverity(severity?: EventSeverity) { + if (severity && !Object.values(EventSeverity).includes(severity)) { + throw new BadRequestException('Invalid "severity" value'); + } } -if (source && !Object.values(EventSource).includes(source)) { - throw new BadRequestException('Invalid "source" value') +private validateSource(source?: EventSource) { + if (source && !Object.values(EventSource).includes(source)) { + throw new BadRequestException('Invalid "source" value'); + } }
Best practice	Validate the length of the response array in event tests to ensure robustness. To ensure the robustness of your event validation tests, consider checking the length of the response array before accessing its first element. This will prevent potential errors when the array is unexpectedly empty. Additionally, it's a good practice to validate that the array contains exactly one event (or however many you expect), as this ensures your test is accurately assessing the situation it's meant to. apps/api/src/workspace/workspace.e2e.spec.ts [204-205] +expect(response.length).toBe(1) const event = response[0] -expect(event).toBeDefined()
	Improve test setup clarity by separating eventService instantiation. For better test isolation and readability, consider separating the instantiation of eventService from the beforeAll setup block. Currently, eventService is instantiated within beforeAll, which is primarily used for setting up the test environment. Extracting the instantiation to a separate, dedicated block or function can improve the structure and clarity of your test setup. apps/api/src/workspace/workspace.e2e.spec.ts [70] -eventService = moduleRef.get(EventService) +let eventService: EventService; +beforeEach(() => { + eventService = moduleRef.get(EventService); +});
	Add assertions for all relevant event properties to ensure data integrity. To ensure that your tests accurately reflect the intended behavior of your application, consider adding assertions for the properties of the event object that are not currently being checked. For example, verifying the timestamp and metadata fields can help ensure that the events are being created with all the expected data. This can be particularly important for ensuring data integrity and for debugging purposes. apps/api/src/workspace/workspace.e2e.spec.ts [209-211] expect(event.type).toBe(EventType.WORKSPACE_CREATED) expect(event.workspaceId).toBe(workspace1.id) +expect(event.timestamp).toBeDefined() +expect(event.metadata).toBeDefined()
	Ensure response array length is checked before access in tests. For consistency and to avoid potential issues, ensure that all event-related tests check the length of the response array before accessing its elements. apps/api/src/environment/environment.e2e.spec.ts [255] +expect(response.length).toBeGreaterThan(0) const event = response[0]
	Use type assertion to avoid @ts-expect-error and maintain type safety. Consider using a type assertion for query to avoid the @ts-expect-error directive. This will help maintain type safety and make the code cleaner. You can define an interface or type that extends the existing Prisma model with the optional severity field. apps/api/src/event/service/event.service.ts [53-54] -// @ts-expect-error - Prisma does not have a type for severity -return await this.prisma.event.findMany(query) +interface EventQuery extends Prisma.EventFindManyArgs { + where: { + severity?: EventSeverity; + }; +} +return await this.prisma.event.findMany(query as EventQuery)
	Use a functional approach to construct the query for improved readability. Instead of directly modifying the query.where object, consider using a more functional approach to construct the query. This can improve code readability and make the query construction more explicit. apps/api/src/event/service/event.service.ts [49-51] -if (source) { - query.where['source'] = source +const query = { + where: { + workspaceId, + title: { + contains: search + }, + ...(source && { source }), + }, + skip: page * limit, + take: limit, + orderBy: { + timestamp: 'desc' + } }
	Add error handling for workspace authority verification for graceful failure. Consider adding error handling for the getWorkspaceWithAuthority call. In case of an error, this would allow for a more graceful failure and potentially provide more context to the caller. apps/api/src/event/service/event.service.ts [28-33] -await getWorkspaceWithAuthority( - user.id, - workspaceId, - Authority.READ_EVENT, - this.prisma -) +try { + await getWorkspaceWithAuthority( + user.id, + workspaceId, + Authority.READ_EVENT, + this.prisma + ) +} catch (error) { + throw new BadRequestException('Failed to verify workspace authority'); +}
Enhancement	Wrap createEvent calls in try-catch for error handling. Consider wrapping the createEvent calls in a try-catch block to handle potential failures gracefully. This will improve the robustness of the event creation process and ensure that the application can recover from errors related to event logging. apps/api/src/workspace/service/workspace.service.ts [114] -await createEvent( +try { + await createEvent( + // Event details + ); +} catch (error) { + this.log.error('Failed to create event', error); +}
	Add assertions for response array length in tests. To improve test reliability, consider adding assertions for the length of the response array before accessing its first element. This ensures that the test fails gracefully if no events are returned. apps/api/src/variable/variable.e2e.spec.ts [371] +expect(response.length).toBeGreaterThan(0) const event = response[0]
Bug	Use await with createEvent to prevent race conditions. Ensure that the createEvent function is awaited inside asynchronous functions to prevent potential race conditions or unhandled promises. apps/api/src/workspace/service/workspace.service.ts [114] -createEvent( +await createEvent(
Security	Add maximum limit validation to prevent potential denial of service. To ensure that the limit parameter cannot be exploited to cause a denial of service by requesting an excessive number of records, consider adding a maximum limit validation. apps/api/src/event/service/event.service.ts [43] -skip: page * limit, -take: limit, +take: Math.min(limit, 100), // Assuming 100 is the maximum allowed limit

---

✨ Improve tool usage guide:

---

Overview:
The improve tool scans the PR code changes, and automatically generates suggestions for improving the PR code. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on a PR.
When commenting, to edit configurations related to the improve tool (pr_code_suggestions section), use the following template:

/improve --pr_code_suggestions.some_config1=... --pr_code_suggestions.some_config2=...

With a configuration file, use the following template:

[pr_code_suggestions]
some_config1=...
some_config2=...

Enabling\disabling automation When you first install the app, the default mode for the improve tool is: pr_commands = ["/improve --pr_code_suggestions.summarize=true", ...] meaning the improve tool will run automatically on every PR, with summarization enabled. Delete this line to disable the tool from running automatically.

Utilizing extra instructions Extra instructions are very important for the improve tool, since they enable to guide the model to suggestions that are more relevant to the specific needs of the project. Be specific, clear, and concise in the instructions. With extra instructions, you are the prompter. Specify relevant aspects that you want the model to focus on. Examples for extra instructions: [pr_code_suggestions] # /improve # extra_instructions=""" Emphasize the following aspects: - Does the code logic cover relevant edge cases? - Is the code logic clear and easy to understand? - Is the code logic efficient? ... """ Use triple quotes to write multi-line instructions. Use bullet points to make the instructions more readable.

A note on code suggestions quality While the current AI for code is getting better and better (GPT-4), it's not flawless. Not all the suggestions will be perfect, and a user should not accept all of them automatically. Suggestions are not meant to be simplistic. Instead, they aim to give deep feedback and raise questions, ideas and thoughts to the user, who can then use his judgment, experience, and understanding of the code base. Recommended to use the 'extra_instructions' field to guide the model to suggestions that are more relevant to the specific needs of the project, or use the custom suggestions 💎 tool With large PRs, best quality will be obtained by using 'improve --extended' mode.

More PR-Agent commands To invoke the PR-Agent, add a comment using one of the following commands: /review: Request a review of your Pull Request. /describe: Update the PR title and description based on the contents of the PR. /improve [--extended]: Suggest code improvements. Extended mode provides a higher quality feedback. /ask <QUESTION>: Ask a question about the PR. /update_changelog: Update the changelog based on the PR's contents. /add_docs 💎: Generate docstring for new components introduced in the PR. /generate_labels 💎: Generate labels for the PR based on the PR's contents. /analyze 💎: Automatically analyzes the PR, and presents changes walkthrough for each component. See the tools guide for more details. To list the possible configuration parameters, add a /config comment.

See the improve usage page for a more comprehensive guide on using this tool.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ No coverage uploaded for pull request base (approval-and-event@4abf251). Click here to learn what that means.

Additional details and impacted files

@@                  Coverage Diff                  @@
##             approval-and-event     #159   +/-   ##
=====================================================
  Coverage                      ?   94.77%           
=====================================================
  Files                         ?       90           
  Lines                         ?     1991           
  Branches                      ?      394           
=====================================================
  Hits                          ?     1887           
  Misses                        ?      104           
  Partials                      ?        0           

Flag	Coverage Δ
api-e2e-tests	94.77% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
5 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
5.0% Duplication on New Code

See analysis details on SonarCloud