elsa-core
elsa-core copied to clipboard
elsa-workflows
Elsa 3 Task Overview
The following is a preliminary overview of outstanding tasks for the Elsa 3.0 release candidate version.
3.0 RC2
See also the 3.0 RC2 milestone
- [x] Documentation to get started #3904
- [x] Fix pagination #3890
- [x] Bulk delete workflow instances #3883
- [x] Workflow Contexts #3903
- [x] Fix Unpublish button #3897
- [x] Workflow journal
- [x] FlowNode
- [x] SendEmail activity
- [x] Import/export UI
- [x] Proto Actor cleanup #3584
- [x] Object serialization
- [x] MassTransit activities
- [x] Azure Service Bus activities
- [x] Automatic token refresh from designer
- [x] Elasticsearch provider for workflow state + execution log #3579
- [x] HTTP Endpoint Body #3627
- [x] Intellisense for JavaScript #2975
- [x] Task activity #3591
- [x] Publish Event activity #3590
- [x] Correlation activity #3488
- [x] Webhooks #3592
- [x] Activity definition input/output
- [x] Run Workflow activity #3698
- [x] Activity cancellation #3393
- [x] Refactor jobs
- [x] API key authorization
3.x
- [ ] Multitenancy
- [ ] Input validation
- [ ] Retention & archiving policies
- [ ] RabbitMQ activities
- [ ] Intellisense: JavaScript
- [ ] Intellisense: C#
- [ ] Intellisense: Python
- [ ] Intellisense: Liquid
- [x] Parallel ForEach #1059
- [ ] Scoped variable UI
- [x] Run workflow from designer
- [ ] Define JS functions from designer
- [ ] Secrets management
- [ ] Settings management
- [ ] User Task activities
Else v2 currently stores the .Net activity type as a string in the type property in the json, and in the database as well I believe. I'm worried that not storing the namespace with it will cause issues if a third-party creates an activity that happens to use the same class name. Can Elsa v3 be updated to use the full namespace?
@johnwc
Else v2 currently stores the .Net activity type as a string in the type property in the json, and in the database as well I believe
That's more or less the case - the activity type is based on the .NET type name, but technically it can be set to a user-defined value. The activity type provider that reflects on IActivity implementations uses this as a convention, but it honors whatever activity type name is provided in the [ActivityAttribute] (if present).
I'm worried that not storing the namespace with it will cause issues if a third-party creates an activity that happens to use the same class name. Can Elsa v3 be updated to use the full namespace?
I had the same worry! Yes, Elsa 3 uses activity type namespacing. The recommendation here is for activity authors to explicitly provide a namespace. For example, the WriteLine activity is declared as follows:
/// <summary>
/// Write a line of text to the console.
/// </summary>
[Activity("Elsa", "Console", "Write a line of text to the console.")]
public class WriteLine : Activity
{
...
}
The first argument is the namespace, the second argument the category, the third argument is a description. It also allows you to define a custom activity type name, but when omitted, will default to the class name.
The same goes for the namespace, actually: when omitted, the full namespace of the .NET type is used. But, I prefer short namespaces (like "Elsa") - it's easier on the eyes, and still provides a good level of isolation from custom / third-party activities I think.
@sfmskywalker nice! That all sounds perfect, is this only in v3 or can I start doing this in v2 activities?
If you hadn't already implemented this, other than storing the namespace/name. I was going to suggest forcing a developer to set an id as a GUID in the ActivityAttribute, and that is what is used in workflow definitions. Much how COM objects work.
@johnwc
is this only in v3 or can I start doing this in v2 activities?
Although V2 doesn't explicitly model namespacing, it does allow you to provide a custom activity type name, which could include a prefix (e.g. "MyLib.MyActivity"). I haven't tested this, but should work :)
I was going to suggest forcing a developer to set an id as a GUID in the ActivityAttribute, and that is what is used in workflow definitions. Much how COM objects work
That would definitely avoid name clashing. The only downside I think is that of readability while troubleshooting - a GUID is less descriptive than a technical name. At the same time, this may be solved separately using proper diagnostic tools.
It's an interesting idea we may yet explore.
I asked this in another thread but figured this was more appropriate. Shouldn't there be a checkbox for multitenancy support in the 3.x section? Since it's security related, usually it seems safest to try to create APIs with tenant filters, etc. up-front so we don't forget everywhere it needs to be applied later.
Yes but probably not straight away as part of the first release. Maybe 3.1, or 3.2, etc. depending on availability of time. There are a million things to do still.
@goodsxx It does, as of November 25th, via 5ac5272a7b1b8d0ec517002092c760102af02216 pushed by @mohdali 👍🏻