[cases] Add extensions for workflow case data conversions, similar to case.DataAs

[dkarkanas]

A propsed way to avoid duplicate extension code in solutions and workflow activities, when the developer wants to access typed case data from wf activities.

The naming is using prefix to avoid confusion with the "original" convertors:

Indice.Platform/src/Indice.Features.Cases.Core/Models/Responses/CasePartial.cs

Line 70 in 71e1b52

public TData DataAs<TData>() {

and

Indice.Platform/src/Indice.Features.Cases.Core/Models/Responses/CasePartial.cs

Line 84 in 71e1b52

public JsonNode? DataAsJsonNode() {

[Copilot]

Pull request overview

Adds workflow-focused extension methods to convert Integrations.Case.Data into strongly-typed objects or JsonNode, mirroring the behavior of case.DataAs in the core cases models.

Changes:

• Introduces CaseWorkflowDataAs<TData> / CaseWorkflowDataAsJsonNode extensions for Indice.Features.Cases.Workflows.Integrations.Case.
• Minor cleanup: reorder using directives in ActivityExecutionContextExtensions.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/Indice.Features.Cases.Workflows/Extensions/CasesExtensions.cs	New extensions to deserialize Integrations.Case.Data to typed objects / JsonNode.
src/Indice.Features.Cases.Workflows/Extensions/ActivityExecutionContextExtensions.cs	Reorders using directives (no functional change).

---

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

In general, to fix a “useless upcast” you remove the explicit cast where the compiler already performs an implicit conversion (typically from a derived/reference type to object or a base type) and where that cast does not affect overload resolution or generics. The goal is to preserve behavior while simplifying the code.

Here, the specific pattern is return (TData)(object)jsonElement.GetRawText(); inside CaseWorkflowDataAs<TData>. The inner (object) cast is redundant because jsonElement.GetRawText() is already a string, which implicitly converts to object. The outer cast to TData is still required to satisfy the generic return type, but the intermediate upcast is unnecessary. The best fix is to remove only the (object) cast, changing line 30 to return (TData)(jsonElement.GetRawText() as object); is not necessary; we can simply rely on the fact that C# allows an explicit cast from string to TData via the existing syntax: return (TData)(object)jsonElement.GetRawText(); can be simplified to return (TData)(object)jsonElement.GetRawText(); → return (TData)(object)jsonElement.GetRawText();? Actually the minimal and correct change is to remove the inner cast entirely: return (TData)(object)jsonElement.GetRawText(); → return (TData)jsonElement.GetRawText();. This keeps the logic intact: when TData is string, the cast to TData is valid and returns the raw JSON text; for any other TData, this line is only executed when typeof(TData) == typeof(string), so behavior is unchanged.

This requires editing only src/Indice.Features.Cases.Workflows/Extensions/CasesExtensions.cs, in the body of CaseWorkflowDataAs<TData>, replacing the specific return statement inside the if (typeof(TData) == typeof(string)) block that handles JsonElement. No new methods or imports are needed.

In general, a "useless upcast" warning is resolved by removing an explicit cast where the compiler will automatically perform the conversion (e.g., from a more derived type to a base type like object). Here, on line 38, json is a string, and C# implicitly converts string to object, so (object)json is redundant.

The best minimal fix that preserves existing behavior is to remove only the (object) upcast and keep the generic cast to TData. Specifically, change:

return (TData)(object)json;

to:

return (TData)json;

This keeps the method’s semantics the same: when TData is string, the cast is effectively a no-op; when TData is something else but typeof(TData) == typeof(string) (which cannot happen), the logic would be unreachable anyway. No changes to imports or other methods are required. The edit is confined to src/Indice.Features.Cases.Workflows/Extensions/CasesExtensions.cs, in the CaseWorkflowDataAs<TData> method, near the bottom of that method where the non-JsonElement path handles the string case.

[dkarkanas]

We discussed with @cleftheris the proposed way for this, which is to use JsonNode instead of dynamic (CaseData), and object (IntegrationCaseData).