Skip to content
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

Adding JobResult to CompleteJobRequest for gRPC #4808

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions docs/apis-tools/zeebe-api/gateway-service.md
Original file line number Diff line number Diff line change
Expand Up @@ -191,6 +191,48 @@ message CompleteJobRequest {
int64 jobKey = 1;
// a JSON document representing the variables in the current task scope
string variables = 2;
// The result of the completed job as determined by the worker.
// This functionality is currently supported only by user task listeners
optional JobResult result = 3;
}

message JobResult{
// Indicates whether the worker denies the work, or explicitly doesn't approve it.
// For example, a user task listener can deny the completion of a user task by setting this flag to true.
// In this example, the completion of a task is represented by a job that the worker can complete as denied.
// As a result, the completion request is rejected and the task remains active.
// Defaults to false.
optional bool denied = 1;
// Attributes that were corrected by the worker.
// The following attributes can be corrected, additional attributes will be ignored:
// * `assignee` - reset by providing an empty string
// * `dueDate` - reset by providing an empty string
// * `followUpDate` - reset by providing an empty string
// * `candidateGroups` - reset by providing an empty list
// * `candidateUsers` - reset by providing an empty list
Comment on lines +208 to +212
Copy link
Member

@korthout korthout Jan 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As multiple listeners may trigger in sequence, corrections may overwrite one-another. the wording reset may imply that a previously made correction can be "reset" (i.e. undone).

🔧 I suggest changing the word reset to unset or clear

@ana-vinogradova-camunda @ce-dmelnych What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point @korthout ! Thank you. I will open a PR for it today 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will use unset for now, but if you prefer the clear option, just let me know.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's go for clear, while reviewing other documentation I saw it getting some usage

// * `priority` - minimum 0, maximum 100, default 50
// Omitting any of the attributes will preserve the persisted attribute's value.
optional JobResultCorrections corrections = 2;
}

message JobResultCorrections {
// The assignee of the task.
optional string assignee = 1;
// The due date of the task.
optional string dueDate = 2;
// The follow-up date of the task.
optional string followUpDate = 3;
// The list of candidate users of the task.
optional StringList candidateUsers = 4;
// The list of candidate groups of the task.
optional StringList candidateGroups = 5;
// The priority of the task.
optional int32 priority = 6;
}

message StringList {
// Wrapper around a list of string values.
repeated string values = 1;
}
```

Expand Down
Loading