-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
intro changes for smooth migration zeebe user tasks next #4723
base: main
Are you sure you want to change the base?
Conversation
👋 🤖 🤔 Hello, @christinaausley! Did you make your changes in all the right places? These files were changed only in docs/. You might want to duplicate these changes in versioned_docs/version-8.6/.
You may have done this intentionally, but we wanted to point it out in case you didn't. You can read more about the versioning within our docs in our documentation guidelines. |
@christinaausley In the documentation we should describe how to migrate from Job worker-based user tasks to Camunda user tasks. We can cover it on the page https://docs.camunda.io/docs/next/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks/. Job worker-based user tasks are deprecated by Camunda with the 8.6 release, but they will continue to be supported to accommodate custom use cases. Either @aleksander-dytko or I can help document this.
Regarding the renaming of "Zeebe user tasks" to "Camunda user tasks," we should document the renaming in the 8.7 docs. In the 8.5 and 8.6 docs they can still be called "Zeebe user tasks" (as this is the term that was initially communicated to customers). |
…Job worker-based user tasks
@volodymyr-melnykc I will have a thorough look through this and make any of the additional adjustments in the PR description by the end of this week 👍 |
@volodymyr-melnykc I have added a handful of changes if you would like to review. A few questions:
Can you please add this to this PR, or let me know how you would like to phrase it and I can add it for you?
@volodymyr-melnykc Would you like me to move the Tasklist REST API into the |
@camunda/tech-writers I'd like to loop you into this sooner rather than later given the quantity of terminology changes across versions here -- without much context, and without looking too closely at the PR description 😉, do you understand what we are trying to do here in the files changed, or does it confuse your use/knowledge of the product? I think my only concern is if users really understand the difference between the old job-based user tasks and job-based user tasks supported by Camunda/Camunda user tasks (formerly Zeebe user tasks). |
Hi,
These names are not equivalent. The options for user task implementation are:
So there are two different solutions managed by Camunda, one of which is being deprecated (option 2). Please let me know if it's clear. Also let's include @Skaiir in this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work - I reviewed the code without looking at the description, and it is pretty clear what you are trying to achieve here - I think this will be really helpful for users! It would help if we make sure the guide and change is highly visible in the announcements and release notes pages as well.
Just some non-blocking review suggestions as well, but nothing major at all, just some ideas as I went through it 👍
docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md
Outdated
Show resolved
Hide resolved
|
||
#### [`POST /user-tasks/:taskKey/assignment`](/apis-tools/zeebe-api-rest/specifications/assign-a-user-task.api.mdx) | ||
The endpoints above (except `DELETE`) allow you to send a custom `action` attribute via the payload. The `action` attribute carries any arbitrary string and can be used to track any life cycle event, including those mentioned above. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking suggestion: Should we say above twice? If the content is moved, this reference then becomes wrong/orphaned - it is always useful where possible to not directly refer to the physical location of content, e.g. you could say instead:
Task life cycle events can be tracked via the following API endpoints.
You can use these endpoints (except DELETE
) to send a custom action
attribute via the payload. The action
attribute carries any arbitrary string and can be used to track any life cycle event.
docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md
Outdated
Show resolved
Hide resolved
docs/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md
Outdated
Show resolved
Hide resolved
@@ -329,7 +324,7 @@ The following table outlines the respective endpoints. Click the endpoints to fo | |||
</tr> | |||
<tr> | |||
<th style={{ textAlign: "end" }}>Update task</th> | |||
<td style={{color: "gray"}}>-</td> | |||
<td style={{color: "gray"}}>Not supported</td> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking: One for the tech-writing team - do we say "unsupported" or "not supported"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion, but can add to the glossary. WDYT? What is you experience with this terminology?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsupported is marginally smaller, so can be better in a table of supported/unsupported items, but it is quite a niche case - we can discuss in a tech sync 👍
docs/components/modeler/web-modeler/advanced-modeling/form-linking.md
Outdated
Show resolved
Hide resolved
Thank you all for your review -- I will have this cleaned up for a second review either today or tomorrow. |
Description
Resolves remaining changes for https://github.com/camunda/product-hub/issues/2126/.
Note a few open questions below, but the overall goal:
- Should the references in the docs be "Camunda user tasks" or "Job worker-based user tasks managed by Camunda"? The latter is rather wordy, but maybe we can figure out a solution. Regardless, this should only be for the 8.7 docs, yes? Should they still be called "Zeebe user tasks" in 8.6 and 8.5?
Additionally, I am planning to make the following changes:
For 8.6
For 8.7
E.g. this section needs to be updated: https://docs.camunda.io/docs/next/components/modeler/web-modeler/advanced-modeling/form-linking/#camunda-form-embedded
A majority of changes for 8.5 and 8.6 have been launched via PR here, though I plan to launch a separate PR for the changes above.
When should this change go live?
hold
label or convert to draft PR)PR Checklist
/versioned_docs
directory./docs
directory (aka/next/
).