The code has been updated to provide clear and meaningful block reference names using the Humanizer library in the IdentityGraphService. The redundancy in assigning input/output Id's in both IdentityGraphService and InputJsonConverter has also been removed, resulting in cleaner, less convoluted code.
* add a more generic UIHandler to customize how inputAttributes can be handle by the ui
* Add IPropertyUIHandlerResolver and update PropertyUIHandlerResolver
Introduced a new interface, IPropertyUIHandlerResolver, to resolve UI options for a property. Refactored PropertyUIHandlerResolver to implement this interface and removed the unnecessary partial class structure. Also, cleaned up some unnecessary usings in various files for better code organization.
* Refactor variable name and description in InputDescriptor
The 'uISpecifications' variable in the InputDescriptor model is renamed to 'uiSpecifications' for better readability. Additionally, the associated comment was revised to explain that the dictionary is used by the UI.
* "Refactor codebase for improved organization and cleaner architecture"
The codebase has been significantly refactored, moving several classes to more appropriate namespaces for improved organization and cleaner architecture. This includes shifting UI hint handlers, activities, and memory-related components, amongst others. The changes should improve code readability and maintainability, but as this is a broad refactoring effort, thorough regression testing is advised.
* Add CheckList UIHint with associated handler and provider
This update introduces a new UIHint called CheckList to the Elsa.Workflows.Core. This includes the necessary handler and provider classes. The handler is registered in the WorkflowsFeature.cs, and the CheckList UIHint key has been added to the InputUIHints.cs. Various associated files have been created in both the Elsa.Api.Client and Elsa.Workflows.Core project to support this new UIHint.
---------
Co-authored-by: Jérémie DEVILLARD <jdevillard@users.noreply.github.com>
Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com>
Updated the WorkflowDefinitionActivityProvider code to fetch activity descriptors in a paginated manner. This change will be useful to avoid overloading system resources when interacting with large amounts of data. It retrieves a limited number of descriptors per request, looping until all are fetched.
Closes#4689
This commit refactors how expression descriptors are created and retrieved across Elsa project. The asynchronous methods have been simplified to synchronous ones removing unnecessary `ValueTask` returns. Additionally, `IExpressionDescriptorRegistryPopulator` has been removed resulting in less complexity and better performance.
* Initial version of c# expressions
* Add support for strongly-typed workflow variable accessors
* Fix type casting
* Rename c# to C# in XML comments
* Rename Globals.Context to ExecutionContext and Variables to Context
* Move RunJavaScript activity to Elsa.JavaScript
* Add RunCSharp activity
* Add CSharpOptions
* Add common workflow properties and methods
This change ensures that the WorkflowDefinitionActivity supports custom input definitions even if they use the same name as properties already present on the activity, such as WorkflowDefinitionId.
In the scenario where this resolver is used, it's not about discovering ports, but about constructing a graph from the workflow by going through each activity or activities property.
* Implement Alteration types and engine
* Implement Alteration APIs
* Refactor activity work item with support for activity input
* Serialize scheduled activities as part of workflow state
* Add signal to schedule child activity
* Implement stores for plans and jobs
* Add EF Core provider
* Add Retry endpoint
* Keep root context as always active. The root context is the workflow execution context and contains persistent variable state
* Regenerate EF Core migrations
* Handle orphaned activity execution contexts
* Refactor workflow execution factory
* Enable configuring Jint from Program
* Update ModifyVariable alteration with support for type deserialization
* Use ShortGuid for identity
* Cleanup WorkflowServer host
For most scenarios, having an activity type in the registry is necessary only when using a visual designer, and not when using programmatic workflows - unless there are activities with modifiers in place. Therefore a warning might suffice.
* Implement Incident Strategy interface and resolver
* Add ActivityIncident model
* Add IncidentCount and Incidents properties and update migrations
* Expose incident strategies API endpoint
* Update API client with Incident Strategy models
* Replace Fault with Incidents
* Register fault status when any children have faulted
* Map incident count
* Remove unnecessary AlreadyCompleted result
* Ensure next activities are scheduled only if activity completed normally
* Incident roundtrip and fix workflow instance realtime updates
* Remove unused variable
* Add integration tests
* Use NoTracking for EF Core
* Use Activity ID as Node ID for modern tooling
* Fix DispatchWorkflow activity
* Update tests and remove redundant ToolVersion
