Encapsulated key parameters in functions

[demiliani]

Note

Medium Risk
Low code churn, but it changes how storage account/container/key values are sourced; the new helper procedures are currently empty, so blob operations will fail until implemented.

Overview
Replaces hard-coded Azure Blob Storage identifiers (account and container) with calls to new helper procedures (GetStorageAccount, GetContainerName, GetSharedKey) when initializing ContainerClient/BlobClient and creating the container.

Adds [NonDebuggable] internal helper procedures intended to encapsulate these sensitive/configuration values, and removes the previous local GetSharedKey stub in favor of this new internal API.

^{Written by Cursor Bugbot for commit 1dd4962. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

This is the final PR Bugbot will review for you during this billing cycle

Your free Bugbot reviews will reset on March 20

Details

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Empty key parameters break blob operations

High Severity

GetStorageAccount() has an empty body, so it returns an empty Text. ContainerClient.Initialize() and BlobClient.Initialize() now receive a blank account name, and CreateContainer(GetContainerName()) can also receive blank values. This makes Azure Blob calls fail at runtime, so the codeunit can no longer perform its core storage workflow.

Additional Locations (2)

• BlobStorageMgt.codeunit.al#L14-L17
• BlobStorageMgt.codeunit.al#L29-L30

 

[cursor]

Blank container name causes request failures

High Severity

GetContainerName() now supplies the container identifier but has an empty body, so it returns blank Text. Both CreateContainer(GetContainerName()) and BlobClient.Initialize(..., GetContainerName(), ...) run with an invalid container name, causing blob/container operations to fail during normal execution.

Additional Locations (2)

• BlobStorageMgt.codeunit.al#L16-L17
• BlobStorageMgt.codeunit.al#L29-L30

 

[Copilot]

Pull request overview

This PR refactors the Blob Storage demo codeunit to avoid hardcoded Azure Storage account/container identifiers by routing those values through dedicated getter procedures.

Changes:

• Replaced hardcoded storage account and container name literals with GetStorageAccount() / GetContainerName().
• Changed the shared key accessor to [NonDebuggable] internal procedure GetSharedKey(): SecretText.
• Added new [NonDebuggable] internal getters for storage account and container name.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new GetSharedKey/GetStorageAccount/GetContainerName procedures have empty bodies, so they will return default values (empty SecretText/Text). This will cause authorization and client initialization to fail at runtime (and may even be rejected by the compiler depending on return-value assignment rules). Implement these procedures to return real configuration values (e.g., from a setup table / isolated storage / key vault), or explicitly raise an error when not configured to avoid silent misconfiguration.

Suggested change

	end;
	[NonDebuggable]
	internal procedure GetStorageAccount(): Text
	begin
	end;
	[NonDebuggable]
	internal procedure GetContainerName(): Text
	begin
	Error('Storage shared key is not configured. Please implement GetSharedKey to return a valid shared key.');
	end;
	[NonDebuggable]
	internal procedure GetStorageAccount(): Text
	begin
	Error('Storage account is not configured. Please implement GetStorageAccount to return a valid storage account name.');
	end;
	[NonDebuggable]
	internal procedure GetContainerName(): Text
	begin
	Error('Container name is not configured. Please implement GetContainerName to return a valid container name.');

[Copilot]

GetSharedKey() now has internal visibility, which broadens access to the storage account key within the extension. Unless another object must call this, keeping it local reduces the risk of accidental secret exposure/misuse and better matches the goal of encapsulating key parameters.

Suggested change

	internal procedure GetSharedKey(): SecretText
	local procedure GetSharedKey(): SecretText