Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

updated to work with calloutsSet re codegen + compiling; #401

Merged
merged 1 commit into from
Dec 30, 2024

Conversation

techsmyth
Copy link
Member

@techsmyth techsmyth commented Dec 28, 2024

additional code removal + tidy ups

Summary by CodeRabbit

Release Notes

  • Refactoring

    • Renamed multiple function and method signatures related to callouts and collaboration
    • Updated data retrieval paths from callouts to calloutsSet.callouts
    • Modified GraphQL fragments and queries to reflect new data structure
  • Data Structure Changes

    • Introduced calloutsSetId in collaboration models
    • Added new calloutsSet field in GraphQL schemas
    • Restructured how callouts are accessed and managed
  • Test Suite Updates

    • Updated test cases to align with new function and data retrieval methods
    • Maintained existing test logic and assertions
    • Ensured consistent error handling and privilege checks

Copy link

coderabbitai bot commented Dec 28, 2024

Walkthrough

The pull request introduces a comprehensive restructuring of how callouts are managed across the server-side API. The primary change involves renaming functions and fields from collaboration to calloutsSet, affecting multiple files in the server API. This modification impacts test specifications, GraphQL mutations, queries, and fragments, ensuring a consistent approach to handling callouts across different components of the system.

Changes

File/Path Change Summary
functional-api/callout/... Renamed functions like createCalloutOnCollaborationcreateCalloutOnCalloutsSet across multiple request parameter files
graphql/mutations/callout/... Updated mutation names and input types to reflect CalloutsSet context
graphql/queries/callout/... Modified queries to use calloutsSetId instead of collaborationId
graphql/fragments/... Restructured callout-related fragments to include calloutsSet wrapper
Test Specifications Updated test cases to use new function names and data access paths

Sequence Diagram

sequenceDiagram
    participant Client
    participant GraphQL API
    participant CalloutsSet
    participant Callout

    Client->>GraphQL API: CreateCalloutOnCalloutsSet
    GraphQL API->>CalloutsSet: Assign Callout
    CalloutsSet-->>GraphQL API: Return Callout ID
    GraphQL API-->>Client: Confirm Callout Creation
Loading

Possibly related PRs

Suggested Reviewers

  • Comoque1
  • ccanos

Poem

🐰 Hop, skip, and a callout's leap,
From collaboration's old keep,
To calloutsSet, a brand new home,
Where data structures freely roam!
Refactoring with rabbit's grace,
Renaming functions, setting pace! 🚀

Tip

CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command @coderabbitai generate docstrings to have CodeRabbit automatically generate docstrings for your pull request. We would love to hear your feedback on Discord.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

🧹 Nitpick comments (24)
server-api/src/graphql/mutations/journeys/subspace.ts (1)

58-59: Consider typing for calloutsSetData.
Defining a dedicated interface or type for calloutsSetData can improve maintainability and make it more explicit that this data is intentionally empty now, but may be extended in the future.

-collaborationData: {
+collaborationData: {
   addTutorialCallouts: true,
-  calloutsSetData: {},
+  calloutsSetData: {} as CalloutsSetData, // or some interface
},
server-api/src/functional-api/callout/whiteboard/whiteboard-callout.params.request.ts (1)

7-17: Consider aligning the function name for consistency with the new parameter.

You have replaced collaborationID with calloutsSetID, which is consistent with the emerging terminology around "calloutsSet." However, the function name remains createWhiteboardCallout, whereas in various other files you have renamed similar functions to reflect the new naming convention (e.g., createCalloutOnCalloutsSet). For consistency and clarity, consider updating this function name or adding a comment to clarify the parameter’s purpose.

server-api/src/functional-api/journey/subspace/subspace.request.params.ts (2)

59-59: No operation on this newly introduced blank line.

This line appears to be a new blank line. No specific issue is found here, but ensure it’s intentional or remove it if unnecessary.


96-96: Clarify the usage of the empty calloutsSetData object.

An empty object is introduced for calloutsSetData. If it’s a placeholder for future data, consider adding a short comment indicating its intended purpose. Otherwise, remove it if not needed to avoid confusion.

server-api/src/functional-api/subscriptions/create-subsubspace.it-spec.ts (2)

10-10: Minor formatting nitpick regarding extra semicolon.
There appears to be a double semicolon after the import of UniqueIDGenerator. Consider removing the extra semicolon for consistency and cleanliness.

-import { UniqueIDGenerator } from '@alkemio/tests-lib';;
+import { UniqueIDGenerator } from '@alkemio/tests-lib';

90-90: Clarify user role usage.
Here, an explicit TestUser.SPACE_ADMIN is passed as the last argument. If the intention is to confirm role-specific behavior, consider adding a test case that checks unauthorized or negative paths, ensuring coverage of user role constraints.

server-api/src/functional-api/journey/space/space.request.params.ts (1)

34-34: Question the purpose of empty calloutsSetData.
Initializing an empty {} as calloutsSetData might indicate a placeholder or future usage. If you intend to populate it dynamically, consider clarifying or adding inline comments to describe how it will be leveraged.

server-api/src/functional-api/roleset/user/user2.it-spec.ts (3)

197-198: Naming consistency check.

Here, the variable name oppRes might lead to confusion, since it's created via createSubspace. Consider aligning the variable name (e.g., subspaceRes or subsubspaceRes).

-      const oppRes = await createSubspace(
+      const subsubspaceRes = await createSubspace(

207-208: Naming consistency check.

Similarly, here the variable naming suggests "opportunity" (oppRes2) but is actually obtaining a sub-subspace. Consider renaming for clarity.

-      const oppRes2 = await createSubspace(
+      const subsubspaceRes2 = await createSubspace(

217-218: Naming consistency check.

Again, rename oppRes3 to something that clearly indicates you're creating a sub-subspace, so it’s easier to maintain.

-      const oppRes3 = await createSubspace(
+      const subsubspaceRes3 = await createSubspace(
server-api/src/functional-api/activity-logs/challenge-activity-logs.it-spec.ts (1)

Line range hint 151-221: Retained comments on test steps.

The skip comment indicates updates for whiteboard callouts. Make sure the reference to createCalloutOnCalloutsSet in these lines also handles any future logic for whiteboard-based callouts. Otherwise, looks consistent.

server-api/src/functional-api/activity-logs/space-activity-logs.it-spec.ts (1)

87-90: Check test coverage for creation edge cases.

While switching to createCalloutOnCalloutsSet, consider adding or verifying tests for possible failure modes or invalid parameters passed to the function.

server-api/src/functional-api/activity-logs/opportunity-activity-logs.it-spec.ts (1)

96-100: Test coverage for success/failure states.

While creating a callout, consider a scenario to test behavior if createCalloutOnCalloutsSet fails or returns unexpected data. Helps ensure robust coverage.

server-api/src/scenario/TestScenarioFactory.ts (1)

305-313: Be consistent with naming to avoid confusion.
Here, a second “post” callout is created with createCalloutOnCalloutsSet. The variable name creatPostCallout is slightly misspelled. Consider renaming to createPostCallout or postCalloutData for consistency.

-    const creatPostCallout = await createCalloutOnCalloutsSet(
+    const createPostCallout = await createCalloutOnCalloutsSet(
server-api/src/functional-api/templates/post/post-templates.it-spec.ts (1)

293-293: Maintain index usage checks.
Same indexing pattern on callouts?.[0]. Ensure tests handle empty arrays gracefully.

server-api/src/functional-api/callout/callouts.it-spec.ts (7)

63-66: Consider null-checks on the response.
You're directly accessing res.data?.createCalloutOnCalloutsSet. Ensure that you handle potential null or undefined values from upstream calls, especially in a production environment.


81-89: Reuse logic for test consistency.
Both lines create a callout, retrieve its ID, and verify updates. There’s no immediate issue, but you could refactor creation logic into a common helper to reduce repetition.


114-117: Consider uniform naming for res variable.
The code uses res for multiple requests. For readability, you could rename it to resCalloutSpace or a more descriptive name. This is minor but helps clarity.


163-177: Commented-out code regarding creation calls.
These lines suggest prospective tests or placeholders. If these are no longer needed, consider removing them to keep the codebase clean. Otherwise, add clarifying comments or a TODO to restore them later.


232-232: Encourage consistent debug logging.
If an assertion fails, extra logging can help diagnose issues. Consider logging res to see the entire result whenever a create callout fails.


293-296: Reuse naming for clarity.
If you’re capturing “res” for subspace or subsubspace usage, consider clarifying as “resSubspaceCallout” to avoid confusion with space-level calls.


323-329: Optional advanced test coverage.
You could add additional checks on res.data to ensure the returned callout includes correct attributes beyond just the ID. This is not mandatory, just a suggestion for more comprehensive testing.

server-api/src/functional-api/callout/post/post-on-callout.it-spec.ts (1)

99-99: Validate nested arrays before indexing.
Here, calloutsSet.callouts?.[0] could be undefined if no callouts exist. Consider a safer approach if test data can be unpredictable.

server-api/src/graphql/fragments/callout/calloutOnCollaborationWithStorageConfig.graphql (1)

3-18: LGTM! Consider updating fragment documentation

The restructuring to use calloutsSet and addition of __typename fields improves type safety and debugging capabilities.

Consider adding a comment describing the new structure and relationship between calloutsSet and callouts for better documentation:

+# Fragment for accessing callout storage configuration through the new calloutsSet structure
 fragment CalloutOnCollaborationWithStorageConfig on Collaboration {
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6831912 and 80b24eb.

⛔ Files ignored due to path filters (2)
  • server-api/src/core/generated/alkemio-schema.ts is excluded by !**/generated/**
  • server-api/src/core/generated/graphql.ts is excluded by !**/generated/**
📒 Files selected for processing (51)
  • server-api/src/functional-api/activity-logs/challenge-activity-logs.it-spec.ts (7 hunks)
  • server-api/src/functional-api/activity-logs/opportunity-activity-logs.it-spec.ts (7 hunks)
  • server-api/src/functional-api/activity-logs/space-activity-logs.it-spec.ts (7 hunks)
  • server-api/src/functional-api/callout/call-for-whiteboards/whiteboard-collection-callout.params.request.ts (1 hunks)
  • server-api/src/functional-api/callout/callouts.it-spec.ts (16 hunks)
  • server-api/src/functional-api/callout/callouts.request.params.ts (6 hunks)
  • server-api/src/functional-api/callout/collection-of-links/collection-of-links-callout.params.request.ts (1 hunks)
  • server-api/src/functional-api/callout/lock-state/close-state-callouts.it-spec.ts (4 hunks)
  • server-api/src/functional-api/callout/post/post-collection-callout.params.request.ts (1 hunks)
  • server-api/src/functional-api/callout/post/post-on-callout.it-spec.ts (4 hunks)
  • server-api/src/functional-api/callout/post/post.request.params.ts (1 hunks)
  • server-api/src/functional-api/callout/whiteboard/whiteboard-callout.params.request.ts (1 hunks)
  • server-api/src/functional-api/callout/whiteboard/whiteboardRt-callout.params.request.ts (0 hunks)
  • server-api/src/functional-api/journey/space/space.request.params.ts (1 hunks)
  • server-api/src/functional-api/journey/subspace/subspace.request.params.ts (2 hunks)
  • server-api/src/functional-api/journey/subsubspace/subsubspace.it-spec.ts (1 hunks)
  • server-api/src/functional-api/journey/subsubspace/subsubspace.request.params.ts (0 hunks)
  • server-api/src/functional-api/notifications/callouts/callouts.it-spec.ts (11 hunks)
  • server-api/src/functional-api/notifications/callouts/whiteboard.it-spec.ts (5 hunks)
  • server-api/src/functional-api/roleset/user/user2.it-spec.ts (3 hunks)
  • server-api/src/functional-api/search/search.it-spec.ts (1 hunks)
  • server-api/src/functional-api/storage/auth/private-space-document-auth.it-spec.ts (8 hunks)
  • server-api/src/functional-api/storage/auth/private-space-private-ch-document-auth.it-spec.ts (8 hunks)
  • server-api/src/functional-api/storage/auth/private-space-public-ch-document-auth.it-spec.ts (8 hunks)
  • server-api/src/functional-api/storage/auth/public-space-document-auth.it-spec.ts (8 hunks)
  • server-api/src/functional-api/storage/auth/public-space-private-ch-document-auth.it-spec.ts (8 hunks)
  • server-api/src/functional-api/storage/auth/public-space-public-ch-document-auth.it-spec.ts (8 hunks)
  • server-api/src/functional-api/subscriptions/create-subsubspace.it-spec.ts (2 hunks)
  • server-api/src/functional-api/templates/collaboration/collaboration-template-testdata.ts (0 hunks)
  • server-api/src/functional-api/templates/post/post-templates.it-spec.ts (4 hunks)
  • server-api/src/graphql/fragments/callout/calloutOnCollaborationWithStorageConfig.graphql (1 hunks)
  • server-api/src/graphql/fragments/callout/linkContributionInCallouStorageConfig.graphql (1 hunks)
  • server-api/src/graphql/fragments/callout/postCardCallouStorageConfig.graphql (1 hunks)
  • server-api/src/graphql/fragments/callout/whiteboardCalloutStorageConfig.graphql (1 hunks)
  • server-api/src/graphql/fragments/callout/whiteboardCalloutWithStorageConfig.graphql (1 hunks)
  • server-api/src/graphql/fragments/collaboration/collaborationData.graphql (1 hunks)
  • server-api/src/graphql/mutations/callout/callout/createCalloutOnCollaboration.graphql (1 hunks)
  • server-api/src/graphql/mutations/journeys/subspace.ts (1 hunks)
  • server-api/src/graphql/mutations/journeys/subsubspace.ts (0 hunks)
  • server-api/src/graphql/queries/callout/ChallengeCallout.graphql (0 hunks)
  • server-api/src/graphql/queries/callout/OpportunityCallout.graphql (0 hunks)
  • server-api/src/graphql/queries/callout/SpaceCallout.graphql (1 hunks)
  • server-api/src/graphql/queries/callout/getCallouts.graphql (2 hunks)
  • server-api/src/graphql/queries/callout/getCollaborationCallouts.graphql (0 hunks)
  • server-api/src/graphql/queries/callout/getPostPerJourney.graphql (0 hunks)
  • server-api/src/graphql/queries/callout/getSpaceCallouts.graphql (0 hunks)
  • server-api/src/graphql/queries/community/getOpportunityAvailableMembers.graphql (0 hunks)
  • server-api/src/graphql/queries/journeys/opportunity/opportunityData.graphql (0 hunks)
  • server-api/src/scenario/TestScenarioFactory.ts (6 hunks)
  • server-api/src/scenario/TestSetupUtils.ts (2 hunks)
  • server-api/src/scenario/models/SpaceModel.ts (1 hunks)
💤 Files with no reviewable changes (11)
  • server-api/src/graphql/queries/journeys/opportunity/opportunityData.graphql
  • server-api/src/graphql/queries/callout/getPostPerJourney.graphql
  • server-api/src/graphql/queries/community/getOpportunityAvailableMembers.graphql
  • server-api/src/graphql/queries/callout/OpportunityCallout.graphql
  • server-api/src/graphql/queries/callout/ChallengeCallout.graphql
  • server-api/src/functional-api/callout/whiteboard/whiteboardRt-callout.params.request.ts
  • server-api/src/graphql/mutations/journeys/subsubspace.ts
  • server-api/src/graphql/queries/callout/getSpaceCallouts.graphql
  • server-api/src/graphql/queries/callout/getCollaborationCallouts.graphql
  • server-api/src/functional-api/templates/collaboration/collaboration-template-testdata.ts
  • server-api/src/functional-api/journey/subsubspace/subsubspace.request.params.ts
🔇 Additional comments (134)
server-api/src/graphql/fragments/callout/whiteboardCalloutWithStorageConfig.graphql (2)

Line range hint 5-17: LGTM: Proper type safety with __typename

The nested structure maintains proper type information with __typename fields at each level, which is good for type safety and client-side type checking.


3-4: Verify variable definition for $calloutId

The query uses $calloutId variable which should be defined in the parent operation. Let's verify its usage.

✅ Verification successful

Let me also check the fragment definition and its usage:


Variable $calloutId is properly defined in parent operation

Looking at the search results, I found that the fragment WhiteboardCalloutWithStorageConfig is used in the query WhiteboardCalloutStorageConfig defined in getWhiteboardCalloutDocumentAndStorageData.graphql. This query properly defines the $calloutId variable as UUID! type:

query WhiteboardCalloutStorageConfig($calloutId: UUID!) {
  lookup {
    callout(ID: $calloutId) {
      id
      framing {
        whiteboard {
          profile {
            ...ProfileStorageConfig
          }
        }
      }
    }
  }
}

The variable is correctly defined in the parent operation and matches the usage in the fragment.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check how $calloutId is defined and used across operations
# Search for operations using this fragment and the variable
rg -t graphql "calloutId.*\n.*WhiteboardCalloutWithStorageConfig" -A 5 -B 5

Length of output: 269


Script:

#!/bin/bash
# Search for operations using WhiteboardCalloutWithStorageConfig fragment
rg -U -t graphql "WhiteboardCalloutWithStorageConfig"

# Search for files containing $calloutId variable definition
rg -t graphql "\\\$calloutId.*:.*ID\\\!"

Length of output: 157


Script:

# Check the fragment definition
cat "server-api/src/graphql/fragments/callout/whiteboardCalloutWithStorageConfig.graphql"

# Find all GraphQL files that might be using this fragment
fd -e graphql -x cat {} \; -x echo "=== {} ===" \;

Length of output: 65688


Script:

#!/bin/bash
# Search for operations using this fragment and check variable definitions
rg -l "WhiteboardCalloutWithStorageConfig" | xargs rg -A 10 "\\\$calloutId.*:.*ID"

# Let's also check files that might be using this fragment
fd -e graphql -x grep -l "WhiteboardCalloutWithStorageConfig" {} \;

Length of output: 8621

server-api/src/scenario/models/SpaceModel.ts (1)

15-15: Looks good.
Adding calloutsSetId to the collaboration object aligns with the shift to a more explicit naming convention. Ensure the property is consistently used across the codebase.

If you want to confirm there are no remaining references to the old approach, consider this quick search:

✅ Verification successful

Property naming is consistent across the codebase

The search results show that the calloutsSetId property is consistently used within the collaboration object across the codebase, particularly in test scenarios and functional API tests. The property naming follows the explicit convention as intended.

The other occurrences of collaboration.*Id in the codebase are for different properties (calloutPostId, calloutPostCommentsId, calloutPostCollectionId, etc.) and are used consistently in their respective contexts.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify there's no remaining usage of old 'collaboration' references where 'calloutsSetId' is needed
rg "collaboration.*Id"

Length of output: 24160

server-api/src/functional-api/callout/post/post-collection-callout.params.request.ts (2)

7-7: Parameter rename aligns with new structure.
Renaming from collaborationID to calloutsSetID is consistent with the updated naming convention.


14-17: New call to CreateCalloutOnCalloutsSet.
This matches the parameter rename and ensures the code references the new calloutsSetID appropriately. Confirm that no upstream/downstream calls are still referencing the old function name.

✅ Verification successful

Let me verify if there are any actual usages of the old function name in the codebase, rather than just type definitions.


Let me try a different approach to find any actual usages of the old function name.


Function rename appears to be clean with no lingering references

Based on the verification results, the old function name CreateCalloutOnCollaboration only appears in generated type definition files (client-web/src/core/generated/) and not in any actual usage in the codebase. This suggests that the rename to CreateCalloutOnCalloutsSet has been properly implemented across the codebase with no remaining references to the old function name in the source code.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Checking for references to the old 'CreateCalloutOnCollaboration' usage
rg "CreateCalloutOnCollaboration"

Length of output: 1328


Script:

#!/bin/bash
# Search for actual function calls to CreateCalloutOnCollaboration
ast-grep --pattern 'CreateCalloutOnCollaboration('

# Also check for any GraphQL mutation definitions
rg 'mutation.*CreateCalloutOnCollaboration'

Length of output: 98


Script:

#!/bin/bash
# Search for any file content containing CreateCalloutOnCollaboration, excluding generated files
rg "CreateCalloutOnCollaboration" --type ts --glob '!**/generated/**'

# Also check for any GraphQL files that might contain the old mutation
fd -e graphql -x cat {} \; | rg "CreateCalloutOnCollaboration"

Length of output: 135

server-api/src/functional-api/callout/collection-of-links/collection-of-links-callout.params.request.ts (2)

7-7: Parameter rename is coherent with the codebase shift.
Changing the parameter to calloutsSetID ensures clarity for link collection callouts as well. Good work.


14-17: Check for leftover references to CreateCalloutOnCollaboration.
Renaming to CreateCalloutOnCalloutsSet is correct and aligns with the new approach. Double-check that no other references still point to the old function name.

✅ Verification successful

Let me verify if these references are in generated files or if there are any other occurrences in non-generated files.


No action needed - references only exist in generated files

The old function name CreateCalloutOnCollaboration only appears in generated GraphQL schema files (client-web/src/core/generated/). These files will be automatically updated when the GraphQL schema is regenerated. No manual cleanup is required in the source code.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Searching the codebase for any references to the old function name
rg "CreateCalloutOnCollaboration"

Length of output: 1328


Script:

#!/bin/bash
# Exclude generated files and search for the old function name
rg "CreateCalloutOnCollaboration" --type ts --glob '!**/generated/**'

Length of output: 69

server-api/src/scenario/TestSetupUtils.ts (2)

7-7: New import for callouts data recognized.

The new import getCalloutsData replaces the older collaboration-based approach, aligning with the calloutsSet terminology from the rest of the code changes. This appears consistent.


89-98: Handle scenarios where no matching callout is found.

You filter the array (filteredCallout) and then immediately access [0].id. If the array is empty, this may result in undefined behavior. Consider a defensive check or explicit error handling for when no matching callout is found to avoid potential runtime errors.

server-api/src/functional-api/subscriptions/create-subsubspace.it-spec.ts (1)

83-83: Validate that new subspace creation is properly tested.
You’ve introduced a createSubspace call. Ensure that any subsequent test cases or scenarios reflect this updated creation method. Verify that all references of the prior function are replaced, and that the tests account for potential failures in subspace creation.

server-api/src/functional-api/callout/callouts.request.params.ts (3)

57-58: New function signature looks correct.
Renaming the function to createCalloutOnCalloutsSet is consistent with the rest of the updates. Confirm that all external references to the old method name are likewise updated.


84-87: Ensure consistent merging of default and custom parameters.
When spreading defaultCallout together with user-supplied options, verify that the user’s values override defaults where needed. For instance, if the user provides a different callout type or enableComments setting, ensure that the merged object reflects that.


102-103: Confirm consistent naming of retrieval parameters.
Changing to getCalloutsData with calloutsSetId is clear, but ensure references from older function calls or naming patterns are either removed or transitioned to the new naming in test scenarios.

Also applies to: 112-112

server-api/src/functional-api/journey/subsubspace/subsubspace.it-spec.ts (1)

168-168: Maintain test consistency on newly introduced subspace creation.
Replacing createSubsubspace with createSubspace is logical. Confirm that downstream validations and test assertions accurately reflect “subspace” vs. “subsubspace” nomenclature to avoid confusion.

server-api/src/functional-api/activity-logs/challenge-activity-logs.it-spec.ts (1)

19-19: Consistent function renaming confirmed.

Renaming createCalloutOnCollaboration to createCalloutOnCalloutsSet aligns with the new naming convention. No further issues found.

server-api/src/functional-api/activity-logs/space-activity-logs.it-spec.ts (2)

17-17: Function import alignment.

The import now correctly points to createCalloutOnCalloutsSet. This aligns with removing the old reference. Good to go.


Line range hint 164-232: Comprehensive rename in whiteboard scenario.

All references to createCalloutOnCollaboration appear replaced. If you encounter any new callout types, ensure consistent naming in your test coverage.
[approve]

server-api/src/functional-api/activity-logs/opportunity-activity-logs.it-spec.ts (2)

15-15: Synchronized import with new function name.

The import change to createCalloutOnCalloutsSet is consistent with the updated API. No issues spotted here.


Line range hint 154-223: Ensure upcoming whiteboard tests align.

The portion of code under test.skip references future enhancements for whiteboard flow. Once reactivated, confirm that createCalloutOnCalloutsSet usage remains consistent for any additional callout logic.

server-api/src/scenario/TestScenarioFactory.ts (5)

2-3: Use caution with import references.
It looks like the import references for createCalloutOnCalloutsSet and createWhiteboardCalloutOnCalloutsSet are correctly aligned with the new function names. Just ensure that all references to the old function names (createCalloutOnCollaboration, etc.) have been fully replaced across the codebase.


253-253: Ensure correct assignment of calloutsSetId.
Setting calloutsSetId from spaceData?.collaboration.calloutsSet?.id appears correct. Verify that spaceData?.collaboration.calloutsSet is not null before accessing .id.


Line range hint 262-276: Review creation of post collection callout logic.
You are now creating a post collection callout by calling createCalloutOnCalloutsSet. All looks fine. Just confirm that the legacy references to a “collaboration ID” are replaced with the relevant calloutsSetId when appropriate.


Line range hint 283-298: Confirm correct usage of createWhiteboardCalloutOnCalloutsSet.
The introduced lines correctly utilize calloutsSetId and store the ID in collaboration.calloutWhiteboardId. Looks consistent.


424-424: Ensure structured initialization.
calloutsSetId is properly initialized to an empty string. This is appropriate if a callouts set is not yet created, but confirm that logic accounts for the possibility of calloutsSetId remaining empty if creation fails.

server-api/src/functional-api/callout/lock-state/close-state-callouts.it-spec.ts (5)

5-5: Confirm correct import statement.
Importing createCalloutOnCalloutsSet aligns with the new function signature. Make sure all references to the old function are fully removed.


87-93: Successful callout creation.
Using createCalloutOnCalloutsSet with baseScenario.space.collaboration.id might be fine if collaboration.id and calloutsSetId have distinct usage. Verify that the correct ID is passed if the function expects the callouts set identifier.


105-105: Validate updated object path.
Accessing calloutsSet.callouts?.[0] ensures the new structure is used. Confirm the calling function or scenario still expects this updated shape.


113-116: Maintain ID consistency.
Again, passing baseScenario.space.collaboration.id to createCalloutOnCalloutsSet is correct only if that ID is truly the callouts set. If not, update accordingly.


129-129: Ensure correct data structure.
Accessing postsData.data?.space.collaboration?.calloutsSet.callouts?.[0] is consistent with the new approach. Valid usage if the callouts are always in the first array item for these tests.

server-api/src/functional-api/notifications/callouts/whiteboard.it-spec.ts (4)

7-7: Updated import for whiteboard callouts.
Confirmed addition of createWhiteboardCalloutOnCalloutsSet matches the new naming convention. Good alignment with updateCalloutVisibility.


Line range hint 83-97: Creating space whiteboard callout.
You're referencing baseScenario.space.collaboration.calloutsSetId to create a whiteboard callout. This is correct if that ID indeed references the callouts set. The subsequent assignment of whiteboardCollectionSpaceCalloutId from createCalloutOnCalloutsSet.id is coherent.


Line range hint 104-118: Ensure subspace usage is correct.
Here, you repeat the pattern for subspace, referencing baseScenario.subspace.collaboration.calloutsSetId. This is consistent if subspace collaboration also has a valid calloutsSetId.
[approve]


Line range hint 125-139: Create whiteboard callout on subsubspace.
Following the same logic for subsubspace is consistent. Make sure resSubsubspace.data?.createCalloutOnCalloutsSet is not null before usage.

server-api/src/functional-api/templates/post/post-templates.it-spec.ts (3)

201-201: Check updated path for contributions.
calloutsSet.callouts?.[0].contributions? is consistent with the updated API structure. Ensure the index [0] usage is stable if multiple callouts exist.


271-271: Confirm no side effects of updated path.
Again, referencing the updated path at calloutsSet.callouts?.[0].contributions is correct given the new naming. Looks good.


328-328: Validate removal logic.
Even after deleting a template, the associated post remains in calloutsSet.callouts?.[0].contributions. This is correct per your domain logic, ensuring the post's data remains unaffected by template deletion.

server-api/src/functional-api/callout/callouts.it-spec.ts (19)

4-6: Consistent import usage verified.
These imports align with the updated function names for creating and retrieving callout data. No issues found.


73-73: Validate array access.
You're indexing callouts?.[0]. Be mindful if callouts is empty or null, as it might cause unintended behavior if it’s undefined. Consider adding a guard or fallback.


106-106: Double-check nested property paths.
Line references calloutsSet.callouts?.[0]. Make sure intermediate objects (e.g., collaboration, calloutsSet) are never null/undefined in successful scenarios.


125-125: Check array boundary conditions.
Accessing [0] again. Ensure that callouts has at least one element in all test scenarios. If callout creation fails, you might not have any items.


132-135: Confirmed callout creation logic.
No apparent issues. The function arguments match your updated schema, and ID retrieval is consistent.


136-140: Guard against undefined calloutsSetId.
Ensure baseScenario.space.collaboration.calloutsSetId is always set as expected. If not, getCalloutsData might fail silently or incorrectly.


144-148: Compare arrays carefully before and after.
You’re comparing lengths of callouts. This is good for verifying that one item was removed. No changes needed here.


203-204: Test table data references the correct string.
Both lines demonstrate the matching success message. No code issues found.


209-214: Null-safe approach recommended.
You safely use optional chaining with res.data?.createCalloutOnCalloutsSet. The code appears fine, but consider a fallback or explicit assertion if the result is unexpectedly null.


257-260: Space usage consistent with global admin.
No functional issues here. The pattern corresponds well to other calls.


316-318: Test data looks correct.
All three lines define the user roles and the expected partial success message. This matches the new method name. Looks good.


346-346: User role coverage.
This test line ensures coverage for NON_SPACE_MEMBER attempts to create a callout. No issues found.


371-374: Confirm passing the correct user role.
Everything aligns properly with TestUser.SUBSPACE_MEMBER. No apparent issues.


407-410: ID assignment is consistent.
Assigning the returned ID to calloutId here is straightforward and consistent with the rest of the file.


430-435: User role permutations are well-structured.
Your data table approach is effective for covering multiple user roles in a single test suite. No changes recommended.


440-445: Check for success status codes.
After callout creation, verifying the res for a success code (e.g., 200) might add clarity or catch edge cases in some frameworks. Otherwise, logic is fine.


462-462: Minimal test coverage ok.
One-liner usage with createCalloutOnCalloutsSet. You might expand coverage if there’s any nuance to the arguments needed here. Looks fine overall.


490-493: Ensure correct user tokens.
Since you pass TestUser.SUBSUBSPACE_ADMIN here, confirm that the user object is valid. Everything else looks consistent.


530-533: Space ID usage for subsubspace.
All references to baseScenario.subsubspace.collaboration.id appear consistent. Good approach to keep references in scenario-based variables.

server-api/src/functional-api/notifications/callouts/callouts.it-spec.ts (1)

7-7: Renamed import usage is consistent.
Importing createCalloutOnCalloutsSet aligns with the new naming conventions across the codebase. No issues spotted.

server-api/src/functional-api/callout/post/post-on-callout.it-spec.ts (3)

237-237: Maintain consistent indexing checks.
Same indexing pattern on line 237. Ensure test stability by enforcing that a callout is always created before indexing callouts?.[0].


260-260: Alignment with preceding tests.
Matches the approach seen in earlier tests to confirm the updated data after an update. No further issues found.


298-298: Sufficient for test verification.
Indexing the relevant post contribution is a standard approach for these tests. The code is consistent with prior lines.

server-api/src/functional-api/search/search.it-spec.ts (1)

138-138: Replaced subsubspace location update function.
Switching to updateSpaceLocation is consistent with the merged refactor. Verify that subsubspace location updates remain distinct if they were previously handled separately.

server-api/src/functional-api/storage/auth/public-space-document-auth.it-spec.ts (7)

300-305: Use of calloutsSetId looks correct

The move from collaboration.id to collaboration.calloutsSetId aligns with the revised callout parameter. This should ensure consistency with the updated API structure.


377-383: Consistent alignment with new naming convention

Using createCalloutOnCalloutsSet instead of the old createCalloutOnCollaboration function call is a proper reflection of the refactored API. Good job keeping it consistent.


466-471: Parameter change correctness

Updating to collaboration.calloutsSetId here maintains consistency across test scenarios and should reduce confusion between collaboration IDs and callout set IDs.


645-650: Clear disambiguation between collaboration & callout set

Changing from collaboration-based ID to callout set ID clarifies the domain concept. No issues spotted.


720-726: Consistent changes: looks good

The consistency in updated references to collaboration.calloutsSetId helps prevent confusion. This is well-executed.


793-799: Rename ensures callout framing accuracy

Switching to the new naming is coherent with the broader changes in the callout management system.


867-873: Final adjustments for callout creation

This final update maintains the same pattern: clearly referencing calloutsSetId. All set on these lines.

server-api/src/functional-api/storage/auth/private-space-document-auth.it-spec.ts (7)

300-305: Updated callout parameter

Swapping collaboration.id with collaboration.calloutsSetId aligns with the new data schema. The test setup appears correct.


378-384: Function renaming consistency

Using createCalloutOnCalloutsSet is consistent with the renamed method. No discrepancies found.


557-563: Appropriate domain-level rename

The rename from createCalloutOnCollaboration to createCalloutOnCalloutsSet is correctly reflected here, ensuring standardized naming across test files.


652-657: No issues with the callout initialization

Migrating to the new callout naming convention is done accurately. Nothing problematic in these lines.


727-733: All references updated in set

The changes are consistent—this helps avoid mismatches between collaboration IDs and callout set usage. Verified visually.


800-806: Parameter replacement is coherent

Ensuring all test lines reflect the new callout set ID prevents confusion about which parent object is being referenced. Looks good.


467-472: Correcting references to calloutsSet

Replacing collaboration.id with collaboration.calloutsSetId helps maintain clarity in the test scenarios. Keep verifying other files for leftover mentions.

✅ Verification successful

All references to calloutsSet are correctly using calloutsSetId

Based on the search results, all references to collaboration in the auth test files are consistently using collaboration.calloutsSetId. No instances of collaboration.id were found in the codebase, confirming that the changes have been properly implemented throughout the test files.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Double-check for leftover references in similar specs:
rg "collaboration\.id" server-api/src/functional-api/storage/auth

Length of output: 67


Script:

#!/bin/bash
# Let's try a broader search for collaboration references
rg -g '*.ts' "collaboration\." server-api/src/functional-api/storage/auth

Length of output: 7107


Script:

#!/bin/bash
# Let's also check for calloutsSet references to ensure consistency
rg -g '*.ts' "calloutsSet" server-api/src/functional-api/storage/auth

Length of output: 7101


Script:

#!/bin/bash
# Let's check the specific test file content
cat server-api/src/functional-api/storage/auth/private-space-document-auth.it-spec.ts

Length of output: 38589

server-api/src/functional-api/storage/auth/public-space-public-ch-document-auth.it-spec.ts (8)

333-338: Use of calloutsSetId in link callout creation

Consistent naming update from collaboration ID to calloutsSet ID. This synergy aligns well with the rest of the code changes.


414-420: Refactored test references to callouts

This test code now clearly specifies the callout set ID, minimizing future confusion in the callout creation process.


507-512: Post collection callout usage

Switching to calloutsSetId allows better alignment with the new data model. No immediate concerns.


601-607: Streamlined callout creation

The rename is consistent. All logic still flows the same, with improved clarity about callout sets.


694-699: Reference creation aligns with new IDs

Using calloutsSetId instead of a generic ID is consistent with the updated schema. Tests remain easy to track.


773-779: Visual for post callout improvements

No functional differences aside from the rename. Maintains easy reading and clarity.


850-856: Whiteboard callout test clarity

Properly pointing to calloutsSetId ensures the test is referencing the right entity. No issues spotted.


928-934: WhiteboardRt callout references

Last chunk of updated references to calloutsSetId found here. All consistent with earlier renames.

server-api/src/functional-api/storage/auth/private-space-public-ch-document-auth.it-spec.ts (8)

335-340: Callouts set ID usage confirmed

Shifting from collaboration.id to collaboration.calloutsSetId stands out as correctly aligned with the renamed function calls.


416-422: Post collection param rename

This chunk completes the rename for createPostCollectionCallout, matching the revised schema. No errors found.


509-514: Consistency across test coverage

Maintaining the calloutsSetId usage is vital for uniform test coverage. All looks right here.


603-609: Whiteboard creation alignment

Reliance on calloutsSetId is now standardized. Good job ensuring references are fully updated in the test block.


696-701: Expanded coverage with calloutsSet queries

The callout data retrieval lines are consistent with the new approach for referencing callout sets.


775-781: Refined space references for post callouts

Nothing unusual found. The rename follows standard usage of calloutsSetId.


852-858: Whiteboard callout end-to-end rename

Switching to createCalloutOnCalloutsSet maintains uniformity with the rest of the test framework.


930-936: Final rename consistency check

This final set of changes ensures no missed references remain. The tests are likely consistent and up to date.

server-api/src/functional-api/storage/auth/private-space-private-ch-document-auth.it-spec.ts (14)

342-342: Use updated "calloutsSetId" consistently.
This change from collaboration.id to collaboration.calloutsSetId aligns with the new callouts structure, ensuring correct referencing of the callout set. Make sure all related calls in other test files are also updated.


347-347: Confirm callout creation return structure.
This line now leverages createCalloutOnCalloutsSet. If you renamed the GraphQL mutation, ensure every usage matches the new structure, including the return field (?.id) to avoid any null references.


427-427: Keep function name changes uniform across codebase.
Using baseScenario.subspace.collaboration.calloutsSetId is consistent with the updated naming. Validate all test references to maintain test correctness.


433-433: Check for potential undefined returns.
When capturing calloutId from createCalloutOnCalloutsSet, confirm the response shape is the same as expected. Otherwise, tests might fail if the mutation response changes unexpectedly.


524-524: Ensure newly introduced "calloutsSetId" is valid.
The updated ID parameter is correct, but verify that the subspace has collaboration.calloutsSetId defined in all test scenarios, especially if subspace creation is optional.


529-529: Handle potential edges in callout creation.
When storing calloutId, consider verifying that the result is neither null nor undefined, particularly if server logic changes for new or existing callouts.


622-622: Use new naming consistently for createWhiteboardCollectionCallout.
Switching from older references to calloutsSetId is correct. Continue to ensure other callout creation endpoints also follow the same pattern for consistency.


628-628: Confirm correct callout data shape.
The returned calloutId might differ if the response payload has changed. Double-check references in subsequent tests that rely on this ID.


719-719: Use new parameter "calloutsSetId" for post collection callout.
This aligns the test with the new underlying callout management approach. Good job keeping naming consistent.


724-724: Validate newly created callout data.
Ensure the calloutData.framing fields have the expected shape in subsequent tests, avoiding runtime errors if fields were renamed.


802-802: Remove any stale references to collaboration.id
This updated parameter usage ensures correct referencing of the callout set. Check for leftover references in file imports or older helper functions.


808-808: Ensure consistent usage of the new callout object.
If additional test logic depends on properties of calloutId, ensure all helper methods now point to createCalloutOnCalloutsSet.


883-883: Adopt "createWhiteboardCallout" with updated callouts set.
Replacing collaboration.id with collaboration.calloutsSetId preserves consistent test coverage. This approach clarifies callouts grouping logic.


889-889: Double-check callout response mapping.
Confirm that the new naming does not break references to the framing or profile objects, particularly in subsequent storage or upload tests.

server-api/src/functional-api/storage/auth/public-space-private-ch-document-auth.it-spec.ts (16)

347-347: Confirm callout creation with "calloutsSetId".
Switching from collaboration.id to calloutsSetId is correct. Verify that the new parameter is set in the test scenario to avoid null references.


352-352: Migrate to the new creation pattern.
Relying on createCalloutOnCalloutsSet is consistent with the renamed GraphQL mutation. Check for leftover references to the old function name.


429-429: Keep consistent naming for "post collection" callout.
The updated parameter calloutsSetId ensures alignment with the reorganized data structure. Make sure all newly created callouts in subspace tests mirror this approach.


435-435: Validate calloutId usage if response changed.
Retaining the correct callout ID is essential for subsequent file upload tests. If the mutation response changed, confirm the callout data structure in resulting queries.


523-523: Use new subspace callout structure.
Renaming from createCalloutOnCollaboration to createCalloutOnCalloutsSet eliminates confusion. Good to see consistent usage throughout the file.


528-528: Double-check post creation logic.
Ensuring calloutId references the correct object is crucial. If the server or the schema changed how IDs are returned, confirm that your test references the correct path.


618-618: Adopt the new "whiteboard" callout creation approach.
Implementing calloutsSetId fosters consistency. Scan for any references to the old property in additional files or test helpers.


624-624: Check if whiteboard data shape changed.
After creation, confirm that subsequent references to whiteboardCardId remain valid. If the fields changed, update your test accordingly.


712-712: Leverage "calloutsSetId" in "post3" scenario.
Renaming clarifies that multiple callouts can exist within one set. This fosters better logical grouping.


717-717: Ensure correct callout data.
When storing calloutData, confirm the presence of framing or other nested fields is as expected. If the schema changed, adjust validation calls to match.


792-792: Maintain naming consistency for "post4" scenario.
By switching to calloutsSetId, you maintain consistent references throughout the suite. Keep the naming uniform in further expansions.


798-798: Validate bucket references post-creation.
Check that the new approach for referencing the callout’s storageBucket is stable. If the structure changed, update subsequent tests.


870-870: Switch to updated "calloutsSetId" for whiteboard callout.
The naming shift clarifies the grouping logic, especially if there are multiple callout sets. Good alignment with the overall rename.


876-876: Confirm complete usage of new field.
Be sure subsequent calls referencing the callout’s framing.whiteboard?.profile.storageBucket?.id remain intact if the schema changed the path to that data.


949-949: Uniform usage of "calloutsSetId" repeated.
Ensure the new naming is consistently used in all whiteboard callout creation tests. Minimizes confusion for future maintainers.


955-955: Check newly created callout data references.
If the new calloutData structure introduces differences in framing.whiteboard or other fields, reflect that in post-creation validation.

server-api/src/graphql/mutations/callout/callout/createCalloutOnCollaboration.graphql (1)

1-2: Rename mutation and inputs to reflect new "CalloutsSet" approach.
This rename from CreateCalloutOnCollaboration and CreateCalloutOnCollaborationInput to CreateCalloutOnCalloutsSet and CreateCalloutOnCalloutsSetInput clarifies that callout creation happens on a set of callouts. Verify that all calling code references the new naming to avoid schema mismatch.

Also applies to: 4-4

server-api/src/graphql/fragments/collaboration/collaborationData.graphql (1)

3-7: Track callouts under "calloutsSet".
Replacing callouts with calloutsSet that includes its own id field elegantly groups callouts. This improves clarity of the collaboration structure. Ensure your queries and client-side code handle the new hierarchy properly (callouts nested under calloutsSet).

server-api/src/graphql/queries/callout/SpaceCallout.graphql (1)

5-8: LGTM! Verify CalloutData fragment compatibility

The restructuring to use calloutsSet is implemented correctly and maintains the same functionality.

Let's verify the CalloutData fragment compatibility:

✅ Verification successful

Let's try with different file extensions and without the file type restriction for ripgrep to find GraphQL files and analyze the fragment compatibility.


Let's verify if other queries are using the new calloutsSet structure and where the CalloutData fragment is being used to ensure compatibility.


CalloutData fragment is compatible with the new structure

The verification shows that:

  • The CalloutData fragment is defined correctly on the Callout type and contains the expected fields
  • The new calloutsSet structure is consistently used across multiple queries and fragments in the codebase
  • The CalloutData fragment is being used correctly in both the old and new structures, including mutations and queries
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for CalloutData fragment definition and its usage
ast-grep --pattern 'fragment CalloutData on $type {
  $$$
}'

# Check for any other direct callouts usage that might need updating
rg -g '*.graphql' -l 'callouts\s*\(' --type graphql

Length of output: 148


Script:

#!/bin/bash
# Search for CalloutData fragment definition and usage with ripgrep
rg -g '*.{graphql,gql}' 'fragment CalloutData' -A 10

# Check for any other direct callouts usage that might need updating
rg -g '*.{graphql,gql}' 'callouts\s*\('

Length of output: 1703


Script:

#!/bin/bash
# Let's check the structure of other queries/fragments using calloutsSet
rg -g '*.{graphql,gql}' 'calloutsSet' -B 2 -A 2

# Check if the CalloutData fragment is used in other places
rg -g '*.{graphql,gql}' '\.\.\.CalloutData'

Length of output: 4962

server-api/src/graphql/fragments/callout/linkContributionInCallouStorageConfig.graphql (1)

Line range hint 3-19: LGTM! Verify naming consistency across codebase

The restructuring to use calloutsSet is implemented consistently with other changes, maintaining the same filtering functionality for contributions.

Let's verify naming consistency across the codebase:

✅ Verification successful

Naming and structure are consistent with the codebase changes

The verification shows that:

  1. The codebase has been consistently updated to use calloutsSet instead of direct callouts access in GraphQL queries and TypeScript code
  2. The old direct collaboration.callouts references only appear in test files and comments, which is expected during a transition
  3. The structure in the reviewed file matches the pattern used across the codebase for callout-related queries
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any remaining references to direct callouts usage that might need updating
rg -g '*.{ts,graphql}' 'collaboration\s*{\s*callouts' 

# Verify consistent usage of calloutsSet
rg -g '*.{ts,graphql}' 'calloutsSet\s*{\s*callouts'

Length of output: 361


Script:

#!/bin/bash
# Check for any remaining references to direct callouts usage that might need updating
rg -g '*.{ts,graphql}' 'collaboration.*callouts'

# Verify consistent usage of calloutsSet
rg -g '*.{ts,graphql}' 'calloutsSet.*callouts'

# Check for any inconsistencies in fragment naming
rg -g '*.graphql' 'linkContribution.*Config'

Length of output: 23266

server-api/src/graphql/fragments/callout/whiteboardCalloutStorageConfig.graphql (2)

Line range hint 3-19: LGTM: Clean restructuring with type safety

The changes appropriately wrap the existing callouts field within calloutsSet while maintaining the same internal structure. The addition of __typename fields enhances type safety and debugging capabilities.


1-1: Verify fragment type definition

The fragment is still defined on Collaboration type while accessing the new calloutsSet field. Ensure this matches your updated schema definition.

✅ Verification successful

Fragment type definition is correct

The verification confirms that the Collaboration type in the schema correctly includes the calloutsSet field as shown in the generated schema files:

export type Collaboration = {
  /** The calloutsSet with Callouts in use by this Space */
  calloutsSet: CalloutsSet;
  // ...other fields
}

The fragment definition WhiteboardInCalloutOnCollaborationWithStorageConfig on Collaboration is valid and matches the schema structure.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for Collaboration type definition to verify calloutsSet field
ast-grep --pattern 'type Collaboration {
  $$$
  calloutsSet {
    $$$
  }
  $$$
}'

Length of output: 85


Script:

#!/bin/bash
# Search for schema files containing Collaboration type definition
fd "schema.graphql|schema.gql" --type f --exec cat {} \;

# Also search for any GraphQL files that might contain type definitions
rg "type Collaboration" -A 10

Length of output: 13818

server-api/src/graphql/fragments/callout/postCardCallouStorageConfig.graphql (2)

Line range hint 3-19: LGTM: Consistent with API restructuring

The changes follow the same pattern as other files, properly wrapping the callouts field within calloutsSet and maintaining type safety with __typename fields.


10-13: Verify referenced fragments exist

The fragment references ProfileStorageConfig and ReferenceData. Ensure these fragments are maintained in the updated schema.

✅ Verification successful

Referenced fragments are properly defined in the schema

Both fragments are found in their respective files:

  • ReferenceData fragment is defined in server-api/src/graphql/fragments/references/referencesData.graphql
  • ProfileStorageConfig fragment is defined in server-api/src/graphql/fragments/profile/profileStorageConfig.graphql
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for referenced fragment definitions
ast-grep --pattern 'fragment ProfileStorageConfig on $$$'
ast-grep --pattern 'fragment ReferenceData on $$$'

Length of output: 112


Script:

#!/bin/bash
# Search for fragment definitions using ripgrep for better coverage
rg "fragment (ProfileStorageConfig|ReferenceData) on" --type graphql

Length of output: 102


Script:

#!/bin/bash
# Search for fragment definitions using ripgrep without file type filter
rg "fragment (ProfileStorageConfig|ReferenceData) on"

# Also search for files with .graphql extension to ensure we're looking in the right place
fd ".+\.graphql$"

Length of output: 15955

server-api/src/graphql/queries/callout/getCallouts.graphql (3)

1-5: LGTM: Query signature updated correctly

The parameter change from collaborationId to calloutsSetId aligns with the new data model while maintaining the same parameter type (UUID!).


Line range hint 15-65: LGTM: Fragment structure maintains necessary fields

The nested fragment structure correctly maintains all necessary fields including:

  • Authorization privileges
  • Callout details
  • Profile information
  • Tagset configuration

15-15: Verify fragment type change impact

The fragment type has changed from Collaboration to CalloutsSet. This is a breaking change that might affect clients. Ensure all consumers of this fragment are updated accordingly.

server-api/src/functional-api/callout/call-for-whiteboards/whiteboard-collection-callout.params.request.ts (3)

7-7: Parameter rename aligns with calloutsSet architecture

The parameter rename from collaborationID to calloutsSetID maintains type consistency while reflecting the new architectural approach.


Line range hint 6-38: Implementation maintains robust error handling and core functionality

The function changes are focused solely on the necessary rename points while preserving the existing error handling, whiteboard content defaults, and core functionality. This is a clean implementation of the architectural change.


14-17: Verify GraphQL schema compatibility

The mutation has been updated from CreateCalloutOnCollaboration to CreateCalloutOnCalloutsSet. Let's verify the GraphQL schema changes are in place.

✅ Verification successful

GraphQL schema changes are properly implemented

The verification shows that the GraphQL schema changes are correctly in place:

  1. The mutation file createCalloutOnCollaboration.graphql has been updated with the new mutation name and input type:
mutation CreateCalloutOnCalloutsSet(
  $calloutData: CreateCalloutOnCalloutsSetInput!
) {
  createCalloutOnCalloutsSet(calloutData: $calloutData) {
    ...CalloutData
  }
}
  1. The generated schema types reflect the changes:
  • New input type CreateCalloutOnCalloutsSetInput with calloutsSetID field
  • New mutation arguments type MutationCreateCalloutOnCalloutsSetArgs
  • All references to the old collaboration terminology have been removed from the schema
  1. The changes are consistently used across the codebase in test files and implementations.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify GraphQL schema changes for calloutsSet
# Check for any remaining references to the old collaboration terminology
# and verify the new mutation exists

# Search for old collaboration references in GraphQL files
echo "Checking for old collaboration references in GraphQL files..."
fd -e graphql -x rg -l 'CreateCalloutOnCollaboration'

# Search for the new mutation definition
echo "Verifying new mutation exists..."
fd -e graphql -x rg -l 'CreateCalloutOnCalloutsSet'

# Check for any potential missed renames in the schema
echo "Checking for any inconsistencies in naming..."
fd -e graphql -x rg -l 'collaboration.*ID|collaborationID'

Length of output: 820


Script:

#!/bin/bash
# Let's check the content of the GraphQL files to understand the schema structure

# Check the content of createCalloutOnCollaboration.graphql
echo "Content of createCalloutOnCollaboration.graphql:"
cat ./server-api/src/graphql/mutations/callout/callout/createCalloutOnCollaboration.graphql

# Let's also search for any calloutsSet related definitions
echo -e "\nSearching for calloutsSet definitions:"
rg "calloutsSet" -A 5 -B 5

# Check for any type definitions related to callouts
echo -e "\nSearching for callout type definitions:"
fd -e graphql -x rg "type.*Callout|input.*Callout" -A 3

Length of output: 75007


Script:

#!/bin/bash
# Let's check the content of the GraphQL schema files to verify the mutation changes

# Check the mutation definition
echo "Checking mutation definition:"
cat ./server-api/src/graphql/mutations/callout/callout/createCalloutOnCollaboration.graphql

# Search for input type definitions
echo -e "\nSearching for input type definitions:"
rg "input.*CreateCallout.*Input" -A 3 --type graphql

# Search for any remaining references to collaboration in schema
echo -e "\nSearching for collaboration references in schema:"
rg "collaboration.*{|type.*Collaboration" -A 5 --type graphql

Length of output: 827


Script:

#!/bin/bash
# Let's try a different approach to verify the schema changes

# Check for any remaining references to old mutation name
echo "Checking for old mutation references:"
rg "CreateCalloutOnCollaboration" -A 3

# Search for the new mutation name usage
echo -e "\nChecking for new mutation usage:"
rg "CreateCalloutOnCalloutsSet" -A 3

# Search for input type definitions without file type restriction
echo -e "\nSearching for input type definitions:"
rg "input.*CreateCallout" -A 3

# Search for collaboration references without regex quantifier
echo -e "\nSearching for collaboration references:"
rg "type.*Collaboration|collaboration.*\{" -A 5

Length of output: 70405

@@ -1,13 +1,16 @@
fragment WhiteboardCalloutWithStorageConfig on Collaboration {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Type definition needs to be updated to CalloutsSet

Based on the codebase analysis:

  1. Most fragments are still using Collaboration type, but there's evidence of migration to CalloutsSet in getCallouts.graphql
  2. The query structure shows that calloutsSet is the new parent type that contains callouts
  3. The fragment CollaborationWithCallouts is already defined on CalloutsSet, indicating the direction of the migration

The fragment WhiteboardCalloutWithStorageConfig should be updated to use CalloutsSet instead of Collaboration to maintain consistency with the new schema structure.

🔗 Analysis chain

Verify type definition consistency

The fragment is defined on the Collaboration type, but according to the changes across the codebase, it appears this should be updated to reflect the new naming convention.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if other fragments have been updated to use a different type
# Look for other fragment definitions in GraphQL files
rg -t graphql "fragment \w+ on (Collaboration|CalloutsSet)" 

Length of output: 93


Script:

#!/bin/bash
# Search for fragment definitions in all files, without relying on file type
rg "fragment \w+ on (Collaboration|CalloutsSet)" --type-add 'gql:*.{graphql,gql}' -t gql

Length of output: 1112


Script:

#!/bin/bash
# Look for any GraphQL schema definitions or type definitions
rg "type (Collaboration|CalloutsSet)" --type-add 'gql:*.{graphql,gql}' -t gql

Length of output: 79


Script:

#!/bin/bash
# Find all GraphQL files that might contain relevant type information
fd "\.(graphql|gql)$" --exec grep -l "Collaboration\|CalloutsSet" {} \;

Length of output: 1625


Script:

#!/bin/bash
# Let's check the schema definition to understand the type hierarchy
fd "schema\.graphql$" --exec cat {}

Length of output: 39


Script:

#!/bin/bash
# Check the content of getCallouts.graphql since it shows a fragment on CalloutsSet
cat server-api/src/graphql/queries/callout/getCallouts.graphql

Length of output: 943

@@ -152,7 +152,7 @@ export const postDataPerSpaceCallout = async (
spaceCalloutId
);
const spacePosts =
responseQuery?.data?.space?.collaboration?.callouts?.[0]?.contributions?.filter(
responseQuery?.data?.space?.collaboration?.calloutsSet.callouts?.[0]?.contributions?.filter(
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Ensure safe access to nested properties on calloutsSet.

The code now drills into responseQuery?.data?.space?.collaboration?.calloutsSet.callouts?.[0]?.contributions. If calloutsSet is undefined or null, this may trigger a runtime error. Consider using optional chaining for calloutsSet as well or introducing a null-check to ensure safe property access.

-    responseQuery?.data?.space?.collaboration?.calloutsSet.callouts?.[0]?.contributions?.filter(
+    responseQuery?.data?.space?.collaboration?.calloutsSet?.callouts?.[0]?.contributions?.filter(
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
responseQuery?.data?.space?.collaboration?.calloutsSet.callouts?.[0]?.contributions?.filter(
responseQuery?.data?.space?.collaboration?.calloutsSet?.callouts?.[0]?.contributions?.filter(

Comment on lines +142 to +143
export const createWhiteboardCalloutOnCalloutsSet = async (
calloutsSetID: string,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Be mindful of overwriting user-supplied “framing” in createWhiteboardCalloutOnCalloutsSet.
The code merges ...defaultWhiteboard and ...options, but then overwrites framing with a hardcoded object. If user-provided framing details are relevant, consider merging them carefully rather than hardcoding.

-          framing: {
-            profile: {
-              displayName: 'default callout display name',
-              description: 'callout description',
-            },
-          },
+          framing: {
+            ...(defaultWhiteboard.framing ?? {}),
+            ...(options?.framing ?? {}),
+          },

Also applies to: 163-166

Comment on lines +91 to +94
const res = await createCalloutOnCalloutsSet(
baseScenario.subspace.collaboration.id
);
calloutId = res?.data?.createCalloutOnCollaboration.id ?? '';
calloutId = res?.data?.createCalloutOnCalloutsSet.id ?? '';
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Found references to old function that need to be updated

The old function createCalloutOnCollaboration is still being used in several test files under the testOld/non-functional/orphaned-data/ directory:

  • opportunity-delete.it-spec.ts
  • hub-delete.it-spec.ts
  • challenge-delete.it-spec.ts

These files need to be updated to use the new createCalloutOnCalloutsSet function, which is properly exported and widely used across the codebase.

🔗 Analysis chain

Verify partial usage.

Ensure all references to createCalloutOnCollaboration are replaced with createCalloutOnCalloutsSet. The local usage here looks good.


Let me verify the usage of the old function name in the test files.


Let me check if the new function createCalloutOnCalloutsSet is properly exported and available.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verifying references to old function name across the codebase
rg "createCalloutOnCollaboration"

Length of output: 1295


Script:

#!/bin/bash
# Check if the old function is still exported from the request params file
rg -A 2 "export.*createCalloutOnCollaboration" "server-api/src/functional-api/callout/callouts.request.params.ts"

# Check the content of the test files to understand the context
fd "opportunity-delete.it-spec.ts|hub-delete.it-spec.ts|challenge-delete.it-spec.ts" testOld/non-functional/orphaned-data --exec cat {}

Length of output: 12333


Script:

#!/bin/bash
# Check the exports in the callouts request params file
rg -A 2 "export.*createCalloutOnCalloutsSet" "server-api/src/functional-api/callout/callouts.request.params.ts"

# Check if there are any other files using the new function name
rg "createCalloutOnCalloutsSet"

Length of output: 22396

Comment on lines +556 to +562
baseScenario.space.collaboration.calloutsSetId,
'whiteboard11',
'Whiteboard collection Callout1',
TestUser.GLOBAL_ADMIN
);

calloutId = hu.data?.createCalloutOnCollaboration?.id ?? '';
calloutId = hu.data?.createCalloutOnCalloutsSet?.id ?? '';
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

References to old createCalloutOnCollaboration need to be updated

The search results show that there are still references to the old createCalloutOnCollaboration function in several test files under the testOld directory and in generated schema files:

  • testOld/non-functional/orphaned-data/opportunity/opportunity-delete.it-spec.ts
  • testOld/non-functional/orphaned-data/hub/hub-delete.it-spec.ts
  • testOld/non-functional/orphaned-data/challenge/challenge-delete.it-spec.ts
  • client-web/src/core/generated/alkemio-schema.ts
  • client-web/src/core/generated/graphql.ts

These references need to be updated to use the new function name for consistency.

Note: The collaboration.id references found are legitimate usages for other purposes and not related to the callout creation function.

🔗 Analysis chain

Ensure references to old calls are fully removed

The new parameter name is an improvement. Verify that all references to the prior createCalloutOnCollaboration calls are removed or updated in any other test files.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Searching for the old function usage or ID references:
rg "createCalloutOnCollaboration"
rg "collaboration\.id"

Length of output: 15420

@techsmyth techsmyth merged commit 8245d18 into develop Dec 30, 2024
2 checks passed
@techsmyth techsmyth deleted the server-4808 branch December 30, 2024 15:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant