-
Notifications
You must be signed in to change notification settings - Fork 0
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
Conversation
…ode removal + tidy ups
WalkthroughThe 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 Changes
Sequence DiagramsequenceDiagram
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
Possibly related PRs
Suggested Reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this 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 forcalloutsSetData
.
Defining a dedicated interface or type forcalloutsSetData
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
withcalloutsSetID
, which is consistent with the emerging terminology around "calloutsSet." However, the function name remainscreateWhiteboardCallout
, 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 emptycalloutsSetData
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 ofUniqueIDGenerator
. 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 explicitTestUser.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{}
ascalloutsSetData
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 viacreateSubspace
. Consider aligning the variable name (e.g.,subspaceRes
orsubsubspaceRes
).- 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 withcreateCalloutOnCalloutsSet
. The variable namecreatPostCallout
is slightly misspelled. Consider renaming tocreatePostCallout
orpostCalloutData
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 oncallouts?.[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 accessingres.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 forres
variable.
The code usesres
for multiple requests. For readability, you could rename it toresCalloutSpace
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 loggingres
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 onres.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 documentationThe 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
andcallouts
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
⛔ 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 theCallout
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:
- The codebase has been consistently updated to use
calloutsSet
instead of directcallouts
access in GraphQL queries and TypeScript code - The old direct
collaboration.callouts
references only appear in test files and comments, which is expected during a transition - 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 inserver-api/src/graphql/fragments/references/referencesData.graphql
ProfileStorageConfig
fragment is defined inserver-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:
- The mutation file
createCalloutOnCollaboration.graphql
has been updated with the new mutation name and input type:
mutation CreateCalloutOnCalloutsSet(
$calloutData: CreateCalloutOnCalloutsSetInput!
) {
createCalloutOnCalloutsSet(calloutData: $calloutData) {
...CalloutData
}
}
- The generated schema types reflect the changes:
- New input type
CreateCalloutOnCalloutsSetInput
withcalloutsSetID
field - New mutation arguments type
MutationCreateCalloutOnCalloutsSetArgs
- All references to the old collaboration terminology have been removed from the schema
- 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 { |
There was a problem hiding this comment.
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:
- Most fragments are still using
Collaboration
type, but there's evidence of migration toCalloutsSet
ingetCallouts.graphql
- The query structure shows that
calloutsSet
is the new parent type that containscallouts
- The fragment
CollaborationWithCallouts
is already defined onCalloutsSet
, 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( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
responseQuery?.data?.space?.collaboration?.calloutsSet.callouts?.[0]?.contributions?.filter( | |
responseQuery?.data?.space?.collaboration?.calloutsSet?.callouts?.[0]?.contributions?.filter( |
export const createWhiteboardCalloutOnCalloutsSet = async ( | ||
calloutsSetID: string, |
There was a problem hiding this comment.
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
const res = await createCalloutOnCalloutsSet( | ||
baseScenario.subspace.collaboration.id | ||
); | ||
calloutId = res?.data?.createCalloutOnCollaboration.id ?? ''; | ||
calloutId = res?.data?.createCalloutOnCalloutsSet.id ?? ''; |
There was a problem hiding this comment.
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
baseScenario.space.collaboration.calloutsSetId, | ||
'whiteboard11', | ||
'Whiteboard collection Callout1', | ||
TestUser.GLOBAL_ADMIN | ||
); | ||
|
||
calloutId = hu.data?.createCalloutOnCollaboration?.id ?? ''; | ||
calloutId = hu.data?.createCalloutOnCalloutsSet?.id ?? ''; |
There was a problem hiding this comment.
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
additional code removal + tidy ups
Summary by CodeRabbit
Release Notes
Refactoring
callouts
tocalloutsSet.callouts
Data Structure Changes
calloutsSetId
in collaboration modelscalloutsSet
field in GraphQL schemasTest Suite Updates