
|
If you were logged in you would be able to see more operations.
|
|
|
|
|
| Component/s: |
None
|
| Affects Version/s: |
None
|
| Fix Version/s: |
None
|
|
|
SUBMITTED BY: Mark Ford
TARGET: B4P, Section 3.3 Ad-hoc Attachments
DESCRIPTION: The existing support for passing attachments from a process to
a people activity is very coarse grained. The attachment propagation element
allows for the passing of all or none of the process attachments. This makes
it impossible to control which attachments are propagated to specific people
activities within a process. Consider the use case where there are two
people activities in the same process that require different attachments.
There is no way to pass only the attachments each one needs. The workaround
is to either pass all and let the client application (or end user) filter
out the unrelated attachments or to refactor the people activities such that
they exist in separate processes. Neither solution seems good.
The existing HT protocol supports passing individual attachments to a remote
task but B4P doesn't take advantage of this.
PROPOSAL:
Update the first para of Section 3.3 changing:
"Processes can have ad-hoc attachments. It is possible to exchange ad-hoc attachments between people activities of a process, and even propagate ad-hoc attachments to and from the process level."
with the following:
"It is possible to exchange ad-hoc attachments between people activities of a process by propagating ad-hoc attachments to and from the process level."
|
|
Description
|
SUBMITTED BY: Mark Ford
TARGET: B4P, Section 3.3 Ad-hoc Attachments
DESCRIPTION: The existing support for passing attachments from a process to
a people activity is very coarse grained. The attachment propagation element
allows for the passing of all or none of the process attachments. This makes
it impossible to control which attachments are propagated to specific people
activities within a process. Consider the use case where there are two
people activities in the same process that require different attachments.
There is no way to pass only the attachments each one needs. The workaround
is to either pass all and let the client application (or end user) filter
out the unrelated attachments or to refactor the people activities such that
they exist in separate processes. Neither solution seems good.
The existing HT protocol supports passing individual attachments to a remote
task but B4P doesn't take advantage of this.
PROPOSAL:
Update the first para of Section 3.3 changing:
"Processes can have ad-hoc attachments. It is possible to exchange ad-hoc attachments between people activities of a process, and even propagate ad-hoc attachments to and from the process level."
with the following:
"It is possible to exchange ad-hoc attachments between people activities of a process by propagating ad-hoc attachments to and from the process level." |
Show » |
|