
Security News
Another Round of TEA Protocol Spam Floods npm, But It’s Not a Worm
Recent coverage mislabels the latest TEA protocol spam as a worm. Here’s what’s actually happening.
@salesforce/change-case-management
Advanced tools
Manage change case records in a release management system in Salesforce using something like [Agile Accelerator](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N30000000ps3jEAA). This uses two record types on Case that to manage changes
Manage change case records in a release management system in Salesforce using something like Agile Accelerator. This uses two record types on Case that to manage changes to tools and services during a release; Change Case and Change Case Template. It creates the change case, checks the release is approved, and closes the change case when the release is in the wild.
The typical flow would be:
sfchangecase createsfchangecase checksfchangecase closeIf there is a lot of time during stage 2 (not part of the same CD process), record the change case ID to be used in step 3 and 5.
All options are configurable by environment variables and are prefixed with SF_CHANGE_CASE. All command parameters can use environment variable as defaults. They are snake cased with the prefix.
The most important environment variable is for authentication. Set SF_CHANGE_CASE_SFDX_AUTH_URL to the SFDX auth url to the org in which the change cases will be created.
All command configuration:
| Environment Variable | Description |
|---|---|
| SF_CHANGE_CASE_SFDX_AUTH_URL | The SFDX auth url to authenticate to a Salesforce org that the change cases belong to. |
| SF_CHANGE_CASE_BYPASS | Skip the change case command. |
| SF_CHANGE_CASE_DRYRUN | Run the command without making any DML to an org. Authentication is still required. |
Create command configuration:
| Environment Variable | Description |
|---|---|
| SF_CHANGE_CASE_CHANGE_RECORD_TYPE_ID | The case record type ID for a change case. This will be the different for different orgs. |
| SF_CHANGE_CASE_CHANGE_TEMPLATE_RECORD_TYPE_ID | The case record type ID for a change case template. This will be the different for different orgs. |
| SF_CHANGE_CASE_CONFIGURATION_ITEM | Full path from the configuration item, ex: Salesforce.SF_Off_Core.DeveloperTools.NPM. |
$ npm install -g @salesforce/change-case-management
$ sfchangecase COMMAND
running command...
$ sfchangecase (--version)
@salesforce/change-case-management/2.3.2 linux-x64 node-v20.19.4
$ sfchangecase --help [COMMAND]
USAGE
$ sfchangecase COMMAND
...
sfchangecase closeClose a change case and stop its implementation steps.
USAGE
$ sfchangecase close -o <value> [--json] [--flags-dir <value>] [-i <value>] [-r <value> -l <value>] [-s
Implemented - per plan|Not Implemented|Rolled back - with no impact] [--dry-run]
FLAGS
-i, --change-case-id=<value> change case id
-l, --location=<value> url of the source control location
-o, --target-org=<value> (required) For testing, you can supply a username/alias. It will also parse the org
from the environment: SF_CHANGE_CASE_SFDX_AUTH_URL
-r, --release=<value> schedule build of the new release
-s, --status=<option> [default: Implemented - per plan] What the status of the implementation steps should be
set to.
<options: Implemented - per plan|Not Implemented|Rolled back - with no impact>
--dry-run run the command without making any API calls - all calls will be 'successful'
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
See code: src/commands/close.ts
sfchangecase createcreate a change case record based on a template ID with one implementation step
USAGE
$ sfchangecase create -o <value> -i <value> -c <value> [--json] [--flags-dir <value>] [-r <value> -l
<value>] [--test-environment <value>] [--dry-run] [--service <value>]
FLAGS
-c, --configuration-item=<value> (required) Full path from the configuration item, ex:
Salesforce.SF_Off_Core.DeveloperTools.NPM
-i, --template-id=<value> (required) change case template id
-l, --location=<value> url of the source control location
-o, --target-org=<value> (required) For testing, you can supply a username/alias. It will also parse the org
from the environment: SF_CHANGE_CASE_SFDX_AUTH_URL
-r, --release=<value> schedule build of the new release
--dry-run run the command without making any API calls - all calls will be 'successful'
--service=<value> The name of the Service for this Case (Service\_\_c)
--test-environment=<value> Url to the test results for this change case. Will be added to the Change Case under
"Automated Test Environment" (Test_Environment\_\_c)
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
See code: src/commands/create.ts
FAQs
Manage change case records in a release management system in Salesforce using something like [Agile Accelerator](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N30000000ps3jEAA). This uses two record types on Case that to manage changes
The npm package @salesforce/change-case-management receives a total of 54 weekly downloads. As such, @salesforce/change-case-management popularity was classified as not popular.
We found that @salesforce/change-case-management demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 48 open source maintainers collaborating on the project.
Did you know?

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Security News
Recent coverage mislabels the latest TEA protocol spam as a worm. Here’s what’s actually happening.

Security News
PyPI adds Trusted Publishing support for GitLab Self-Managed as adoption reaches 25% of uploads

Research
/Security News
A malicious Chrome extension posing as an Ethereum wallet steals seed phrases by encoding them into Sui transactions, enabling full wallet takeover.