Feature/remove labels#20447
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
|
Thank you so much for submitting this! We've added it to our backlog to review, and our team has been notified. |
|
Thanks for submitting this PR! When we review PRs, we follow the Pipedream component guidelines. If you're not familiar, here's a quick checklist:
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds a new Pipedrive action Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Action as Remove Labels Action
participant Runtime as Pipedream Runtime ($)
participant API as Pipedrive API
User->>Action: invoke with { type, entityId, labelIdsToRemove }
Action->>Runtime: validate entityId and labelIds
alt validation fails
Runtime-->>Action: throw ConfigurationError
else validation passes
Action->>API: get<CapitalizedType>(entityId)
API-->>Action: return item (with label_ids)
Action->>Action: compute updatedLabelIds = existing - toRemove
alt no labels removed
Action->>Runtime: export $summary ("no labels removed")
Action-->>User: return original item
else labels removed
Action->>API: update<CapitalizedType>({ id: entityId, label_ids: updatedLabelIds })
API-->>Action: return updated item
Action->>Runtime: export $summary (removed/remaining counts)
Action-->>User: return updated item
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/pipedrive/actions/remove-labels/remove-labels.mjs`:
- Around line 21-26: Extract the repeated list of entity type literals into a
single shared constant (e.g., entityTypes) and use that constant for both the
options array and wherever you currently loop over the types; replace the inline
array assigned to the action's options property and the hardcoded array in the
loop (the code referencing options and the for/forEach over entity types in
remove-labels action) with references to entityTypes so the list is defined once
and reused.
- Around line 160-162: The current catch block builds message with
error?.message || JSON.stringify(error, null, 2) which can throw on circular
references; replace that fallback with a safe serializer (e.g., try {
JSON.stringify(error, null, 2) } catch { String(error) || '[unserializable
error]' }) or call a small helper like formatError(error) that returns
error.message || safe stringify || String(error); update the assignment to the
variable message used in the thrown Error(`Failed to update ${type} labels:
${message}`) so the original API failure is preserved and no new TypeError is
raised.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: ac962e7e-643f-4342-aeba-1abb5fe6797b
📒 Files selected for processing (2)
components/pipedrive/actions/remove-labels/remove-labels.mjscomponents/pipedrive/package.json
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/pipedrive/actions/remove-labels/remove-labels.mjs`:
- Around line 175-177: The file ends with the exported object returning
"updatedItem" (see the closing return updatedItem; and the trailing "}," of the
default export) but lacks a trailing newline; open
components/pipedrive/actions/remove-labels/remove-labels.mjs, go to the end
after the closing brace of the exported object (after the line "return
updatedItem;"), and add a single newline character so the file ends with a
trailing newline.
- Around line 160-169: The catch block has inconsistent indentation and an extra
space before the catch keyword; remove the double space before "catch" and
re-indent the entire catch block to match the surrounding 4-space style (align
the opening brace, the try/JSON.stringify block, the inner catch, the serialized
assignment, the message assignment, and the throw) so variables like serialized,
message, and error remain at the same indentation level as surrounding code and
the block braces are consistently aligned.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a9c908bf-b8c8-4bcf-9bf6-b3f79380ce97
📒 Files selected for processing (1)
components/pipedrive/actions/remove-labels/remove-labels.mjs
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/pipedrive/actions/remove-labels/remove-labels.mjs`:
- Around line 124-127: The code calls getItem(type) using this[`${type}Id`]
without validating the active entity ID, causing raw client errors; update the
logic so you validate the ID before any API call (mirror the labelsToRemove
check) or move the fetch into the same try/catch that raises a
ConfigurationError. Specifically, check that this[`${type}Id`] is present and
valid before invoking this.pipedriveApp[`get${capitalizedType}`] in getItem (or
call getItem inside the existing try block and throw a ConfigurationError with a
clear message when the ID is missing/stale), and keep references to getItem,
capitalizedType, this[`${type}Id`], and get${capitalizedType} to locate the
change.
- Around line 141-160: The current read-modify-write in remove-labels uses a
snapshot from this.getItem(type) and writes back label_ids (updatedLabelIds) via
this.pipedriveApp[`update${this.capitalizedType(type)}`], which can clobber
concurrent changes; update the implementation to avoid overwriting concurrent
label edits by either using the API's optimistic-concurrency mechanism (include
a version/modified timestamp if Pipedrive supports it) when calling
update${this.capitalizedType(type)}, or switch to making idempotent per-label
remove calls (call the API endpoint that removes a single label rather than
writing the whole label_ids array) after reloading the latest item state, and
ensure you compute removals against the fresh state (re-run getItem(type) just
before updates); if neither is possible, change the summary/documentation to
state this action is last-write-wins instead of implying it preserves other
labels (adjust messages around removedCount and return behavior).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0a960ead-5aba-4612-a05a-2509db6360d6
📒 Files selected for processing (1)
components/pipedrive/actions/remove-labels/remove-labels.mjs
| const item = await this.getItem(type); | ||
| const currentLabelIds = item?.label_ids ?? []; | ||
|
|
||
| const removeSet = new Set(labelsToRemove.map(String)); | ||
| const updatedLabelIds = currentLabelIds.filter( | ||
| (id) => !removeSet.has(String(id)), | ||
| ); | ||
|
|
||
| const removedCount = currentLabelIds.length - updatedLabelIds.length; | ||
| if (removedCount === 0) { | ||
| $.export("$summary", "No matching labels found on the item — nothing was changed."); | ||
| return item; | ||
| } | ||
|
|
||
| let updatedItem; | ||
| try { | ||
| const response = await this.pipedriveApp[`update${this.capitalizedType(type)}`]({ | ||
| [`${type}Id`]: this[`${type}Id`], | ||
| label_ids: updatedLabelIds, | ||
| }); |
There was a problem hiding this comment.
This read-modify-write flow can clobber concurrent label changes.
Between Line 141 and Line 157 you derive updatedLabelIds from a snapshot and then write the full label set back. If another workflow or user changes labels in that window, this PATCH overwrites the newer state and can remove labels that were never selected. Use an optimistic-concurrency check if the API exposes one, or document that this action is last-write-wins instead of claiming it preserves all other labels.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@components/pipedrive/actions/remove-labels/remove-labels.mjs` around lines
141 - 160, The current read-modify-write in remove-labels uses a snapshot from
this.getItem(type) and writes back label_ids (updatedLabelIds) via
this.pipedriveApp[`update${this.capitalizedType(type)}`], which can clobber
concurrent changes; update the implementation to avoid overwriting concurrent
label edits by either using the API's optimistic-concurrency mechanism (include
a version/modified timestamp if Pipedrive supports it) when calling
update${this.capitalizedType(type)}, or switch to making idempotent per-label
remove calls (call the API endpoint that removes a single label rather than
writing the whole label_ids array) after reloading the latest item state, and
ensure you compute removals against the fresh state (re-run getItem(type) just
before updates); if neither is possible, change the summary/documentation to
state this action is last-write-wins instead of implying it preserves other
labels (adjust messages around removedCount and return behavior).
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/pipedrive/actions/remove-labels/remove-labels.mjs`:
- Around line 190-192: The file currently ends immediately after the closing
object literal/return (the line containing "return updatedItem;" and the
subsequent "};"); add a single trailing newline character at the end of the file
so the file terminates with a newline (ensure the final "};" is followed by one
'\n'), which satisfies editor/linter expectations.
- Around line 124-128: The getItem method incorrectly assumes every SDK call
returns an object with a data property; update getItem to call
this.pipedriveApp[`get${capitalizedType}`](this[`${type}Id`]) and return the
result using the same safe fallback used elsewhere (response?.data ?? response)
so person and deal responses that come back without a data wrapper are handled;
ensure you reference getItem, capitalizedType, this.pipedriveApp and
this[`${type}Id`] when making the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: b8162ad2-35d2-458e-bb22-cc9110504dcd
📒 Files selected for processing (1)
components/pipedrive/actions/remove-labels/remove-labels.mjs
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
components/pipedrive/actions/remove-labels/remove-labels.mjs (1)
14-14:⚠️ Potential issue | 🟡 MinorAlign the “preserve other labels” copy with the last-write-wins behavior.
Line 14 now warns that concurrent edits can be overwritten, but the label prop descriptions still promise that all other labels will be preserved. That copy is no longer accurate for a destructive action and should be softened to match the concurrency disclaimer.
Also applies to: 72-103
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/pipedrive/actions/remove-labels/remove-labels.mjs` at line 14, Update the action description and the label property descriptions to reflect last-write-wins concurrency instead of guaranteeing preservation: replace the absolute phrasing in the description string (the top-level "description" value) and in the label prop text blocks (the properties that currently promise "preserves all other labels") with softer language such as "attempts to preserve other labels but concurrent edits may overwrite changes (last-write-wins)", and add a short note referencing the concurrency disclaimer already present; ensure you change the strings used in remove-labels.mjs for the top-level description and the labels-related prop descriptions (the prop names that mention labels) so the copy is consistent across the file.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/pipedrive/actions/remove-labels/remove-labels.mjs`:
- Around line 147-148: The current try block wraps both the read
(this.getItem(type)) and the subsequent update calls, causing read errors to be
misreported as update failures; move the this.getItem(type) call out of the try
so only the update operation is inside the try/catch (i.e., narrow the try to
only wrap the update call(s) that modify labels), apply the same change for the
second occurrence that wraps the other update block, and ensure the catch
rethrows or logs a message specific to failing to update labels (e.g., "Failed
to update ${type} labels: <error>").
---
Duplicate comments:
In `@components/pipedrive/actions/remove-labels/remove-labels.mjs`:
- Line 14: Update the action description and the label property descriptions to
reflect last-write-wins concurrency instead of guaranteeing preservation:
replace the absolute phrasing in the description string (the top-level
"description" value) and in the label prop text blocks (the properties that
currently promise "preserves all other labels") with softer language such as
"attempts to preserve other labels but concurrent edits may overwrite changes
(last-write-wins)", and add a short note referencing the concurrency disclaimer
already present; ensure you change the strings used in remove-labels.mjs for the
top-level description and the labels-related prop descriptions (the prop names
that mention labels) so the copy is consistent across the file.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 17976841-df56-4be1-93a3-d4168385e65f
📒 Files selected for processing (1)
components/pipedrive/actions/remove-labels/remove-labels.mjs
| try { | ||
| const item = await this.getItem(type); |
There was a problem hiding this comment.
Don’t label read failures as update failures.
This try wraps both the read at Line 148 and the write at Lines 162-166, so a fetch-side 404/permission error is rethrown as Failed to update ${type} labels. Either narrow the catch to the update call or change the message to cover both phases.
Also applies to: 172-183
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@components/pipedrive/actions/remove-labels/remove-labels.mjs` around lines
147 - 148, The current try block wraps both the read (this.getItem(type)) and
the subsequent update calls, causing read errors to be misreported as update
failures; move the this.getItem(type) call out of the try so only the update
operation is inside the try/catch (i.e., narrow the try to only wrap the update
call(s) that modify labels), apply the same change for the second occurrence
that wraps the other update block, and ensure the catch rethrows or logs a
message specific to failing to update labels (e.g., "Failed to update ${type}
labels: <error>").
| key: "pipedrive-remove-labels", | ||
| name: "Remove Labels", | ||
| description: "Removes one or more specific labels from a lead, person, deal, or organization in Pipedrive, leaving all other labels intact. **Note:** This action uses a read-modify-write pattern; concurrent label changes by other workflows or users may be overwritten. [See the documentation](https://developers.pipedrive.com/docs/api/v1)", | ||
| version: "0.1.0", |
There was a problem hiding this comment.
| version: "0.1.0", | |
| version: "0.0.1", |
| for (const entity of ENTITY_TYPES) { | ||
| props[`${entity}Id`].hidden = this.type !== entity; | ||
| props[`${entity}Id`].optional = this.type !== entity; | ||
| props[`${entity}LabelIds`].hidden = this.type !== entity; | ||
| props[`${entity}LabelIds`].optional = this.type !== entity; | ||
| } |
There was a problem hiding this comment.
This is a nice approach, but instead of using a separate set of props for each entity, it'd be better to have a single set of props that call the appropriate API request according to the selected entity type. This would avoid the need to have additionalProps() entirely, which makes the action more compatible with MCP use cases.
Basically each prop should receive the entity type as a parameter, such as:
// in app file
entityId: {
// ....
async options({ type}) {
switch (type) {
case "lead":
// ...
}
}
}
And they would receive the entityType prop's value via the third parameter of propDefinition:
entityId: {
propDefinition: [
pipedriveApp,
"entityId",
({ type }) => ({ type })
],
},
| export default { | ||
| key: "pipedrive-remove-labels", | ||
| name: "Remove Labels", | ||
| description: "Removes one or more specific labels from a lead, person, deal, or organization in Pipedrive, leaving all other labels intact. **Note:** This action uses a read-modify-write pattern; concurrent label changes by other workflows or users may be overwritten. [See the documentation](https://developers.pipedrive.com/docs/api/v1)", |
There was a problem hiding this comment.
What's the benefit of this read-modify-write pattern mentioned here - or is it something required by the Pipedrive API?
There was a problem hiding this comment.
it's required by the API.
53f85c8 to
297c69c
Compare
|
@GTFalcao done changes as you suggested please evaluate |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
components/pipedrive/actions/remove-labels/remove-labels.mjs (1)
74-111:⚠️ Potential issue | 🟡 MinorError message may misattribute read failures as update failures.
The
tryblock wraps both the fetch at line 75 and the update at lines 89-92. IfgetItem()fails (e.g., 404, permission error), the catch throws"Failed to update ${type} labels", which is misleading.Consider narrowing the try-catch to only the update call, or use a more generic message like
"Failed to remove labels from ${type}".♻️ Suggested fix
} catch (error) { if (error instanceof ConfigurationError) { throw error; } let serialized; try { serialized = JSON.stringify(error, null, 2); } catch { serialized = String(error); } const message = error?.message ?? serialized; - throw new Error(`Failed to update ${type} labels: ${message}`); + throw new Error(`Failed to remove labels from ${type}: ${message}`); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/pipedrive/actions/remove-labels/remove-labels.mjs` around lines 74 - 111, The catch currently wraps both the initial fetch (getItem) and the update call (this.pipedriveApp[`update${this.capitalizedType(type)}`]) so read errors are misreported as update failures; narrow the try-catch to only surround the update call (keep ConfigurationError rethrown) or, if you prefer fewer changes, change the thrown message to a generic one like "Failed to remove labels from ${type}" (use error?.message or serialized fallback as before) so failures from getItem are not labeled specifically as update errors.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/pipedrive/actions/add-deal/add-deal.mjs`:
- Line 9: The module's exported version string ("version") was bumped from
0.1.24 to 0.1.25 without any code changes; either revert the "version" value
back to "0.1.24" to keep releases consistent, or if the bump was intentional
update the repository's CHANGELOG (and the package/release notes) with a brief
entry explaining the reason for the isolated bump and link to this action
(referencing the "version" field in add-deal.mjs) so reviewers can see why no
functional code changed.
In `@components/pipedrive/actions/search-notes/search-notes.mjs`:
- Line 7: The version field "version: \"0.0.12\"" in
components/pipedrive/actions/search-notes/search-notes.mjs was bumped without
functional changes; either revert this version back to "0.0.11" or add a
CHANGELOG.md in the pipedrive component directory documenting the reason for the
bump (include the file/action name, e.g., search-notes action, and the nature of
the change or maintenance release notes). Update the repo so every bumped action
version is accompanied by an entry in pipedrive/CHANGELOG.md describing the
change, or undo the unnecessary version increment for the search-notes action.
---
Duplicate comments:
In `@components/pipedrive/actions/remove-labels/remove-labels.mjs`:
- Around line 74-111: The catch currently wraps both the initial fetch (getItem)
and the update call (this.pipedriveApp[`update${this.capitalizedType(type)}`])
so read errors are misreported as update failures; narrow the try-catch to only
surround the update call (keep ConfigurationError rethrown) or, if you prefer
fewer changes, change the thrown message to a generic one like "Failed to remove
labels from ${type}" (use error?.message or serialized fallback as before) so
failures from getItem are not labeled specifically as update errors.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3ddd7211-7ab9-44d0-8e20-6c23ae02d26f
📒 Files selected for processing (30)
components/pipedrive/actions/add-activity/add-activity.mjscomponents/pipedrive/actions/add-deal/add-deal.mjscomponents/pipedrive/actions/add-labels/add-labels.mjscomponents/pipedrive/actions/add-lead/add-lead.mjscomponents/pipedrive/actions/add-note/add-note.mjscomponents/pipedrive/actions/add-organization/add-organization.mjscomponents/pipedrive/actions/add-person/add-person.mjscomponents/pipedrive/actions/get-all-leads/get-all-leads.mjscomponents/pipedrive/actions/get-deal/get-deal.mjscomponents/pipedrive/actions/get-lead-by-id/get-lead-by-id.mjscomponents/pipedrive/actions/get-person-details/get-person-details.mjscomponents/pipedrive/actions/list-deals/list-deals.mjscomponents/pipedrive/actions/merge-deals/merge-deals.mjscomponents/pipedrive/actions/merge-persons/merge-persons.mjscomponents/pipedrive/actions/remove-duplicate-notes/remove-duplicate-notes.mjscomponents/pipedrive/actions/remove-labels/remove-labels.mjscomponents/pipedrive/actions/search-leads/search-leads.mjscomponents/pipedrive/actions/search-notes/search-notes.mjscomponents/pipedrive/actions/search-persons/search-persons.mjscomponents/pipedrive/actions/update-deal/update-deal.mjscomponents/pipedrive/actions/update-lead/update-lead.mjscomponents/pipedrive/actions/update-person/update-person.mjscomponents/pipedrive/package.jsoncomponents/pipedrive/pipedrive.app.mjscomponents/pipedrive/sources/new-deal-instant/new-deal-instant.mjscomponents/pipedrive/sources/new-event-instant/new-event-instant.mjscomponents/pipedrive/sources/new-person-instant/new-person-instant.mjscomponents/pipedrive/sources/updated-deal-instant/updated-deal-instant.mjscomponents/pipedrive/sources/updated-lead-instant/updated-lead-instant.mjscomponents/pipedrive/sources/updated-person-instant/updated-person-instant.mjs
| name: "Add Deal", | ||
| description: "Adds a new deal. See the Pipedrive API docs for Deals [here](https://developers.pipedrive.com/docs/api/v1/Deals#addDeal)", | ||
| version: "0.1.24", | ||
| version: "0.1.25", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check if add-deal.mjs has any non-version changes in this PR
echo "=== Checking changes to add-deal.mjs beyond version bump ==="
git diff origin/master...HEAD -- components/pipedrive/actions/add-deal/add-deal.mjs | grep -E '^\+' | grep -v '^\+\+\+' | grep -v 'version'
if [ $? -ne 0 ]; then
echo "No changes found beyond version bump"
fiRepository: PipedreamHQ/pipedream
Length of output: 222
🏁 Script executed:
# Check if other Pipedrive action files also have version bumps in this PR
git diff origin/master...HEAD -- components/pipedrive/ | grep -E 'version:|^\+\+\+' | head -50Repository: PipedreamHQ/pipedream
Length of output: 107
🏁 Script executed:
# Look for CHANGELOG or version documentation
find . -name "CHANGELOG*" -o -name "CHANGES*" | grep -i pipedriveRepository: PipedreamHQ/pipedream
Length of output: 47
🏁 Script executed:
# Check if all action files in the PR have been touched
git diff --name-only origin/master...HEAD | grep components/pipedriveRepository: PipedreamHQ/pipedream
Length of output: 107
🏁 Script executed:
# Read the add-deal.mjs file
cat components/pipedrive/actions/add-deal/add-deal.mjsRepository: PipedreamHQ/pipedream
Length of output: 4360
🏁 Script executed:
# Check other action files in Pipedrive for version patterns
find components/pipedrive/actions -name "*.mjs" -type f | head -10 | xargs grep -l "version:" | xargs head -15Repository: PipedreamHQ/pipedream
Length of output: 5867
🏁 Script executed:
# Look for any changelog or release documentation
find . -type f \( -name "CHANGELOG*" -o -name "changelog*" -o -name "RELEASES*" \) | head -20Repository: PipedreamHQ/pipedream
Length of output: 1516
Clarify the reason for isolated version bump without code changes.
This file's version was bumped from 0.1.24 to 0.1.25 without any functional modifications to the action code. Other similar Pipedrive actions (e.g., add-activity.mjs at 0.1.24) remain unchanged, making this isolated version bump inconsistent. If this was unintended, revert the version. If intentional, provide a CHANGELOG entry documenting the change and explain the reason.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@components/pipedrive/actions/add-deal/add-deal.mjs` at line 9, The module's
exported version string ("version") was bumped from 0.1.24 to 0.1.25 without any
code changes; either revert the "version" value back to "0.1.24" to keep
releases consistent, or if the bump was intentional update the repository's
CHANGELOG (and the package/release notes) with a brief entry explaining the
reason for the isolated bump and link to this action (referencing the "version"
field in add-deal.mjs) so reviewers can see why no functional code changed.
|
@GTFalcao please review |
|
Hello Team, |
|
@Name-18 follow up on this request :) |
Summary
Added a new Remove Labels action for Pipedrive that allows users to remove one or multiple labels from an existing entity without affecting the remaining labels.
This supports:
The action preserves all other assigned labels and updates only the selected ones.
Why
Previously, the available actions only supported:
There was no way to selectively remove specific labels while keeping others intact.
Example:
Current labels:
label1, label2, label3, label4Remove:
label2, label4Result:
label1, label3Changes Made
remove-labelsactionTesting
Tested with multiple entities and multiple label combinations to ensure:
Summary by CodeRabbit
New Features
Chores