OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bpel4people message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [bpel4people] BP-44: Discovering the operations available for the task


Thanks.

Can you give me Use Cases of what operations may belong to one Role and others to another of those Operations (start, create, suspend, skip, etc)?

The description is more suitable to Task Application related operations, which are not on of these.

Thanks,
Yoichi
On 10/12/2008, at 8:38 AM, Michael Rowley wrote:


Yoichi,

The role is the role that the current logged in user has with respect to this task.  For example, a user is a business administrator for a task if that user is listed in the organizationalEntity assigned to the business administrator role for that task, or if the user is a member of a group that is listed in that organizationalEntity.

Naturally, a user may have several roles with respect to an activity, so the returned set of allowed operations will be the union of the operations allowed for all of the roles that apply to that user.

For a list of which operation apply to each role, you can see the matrix that was accepted in the resolution of issue 43.

Michael

Yoichi Takayama wrote:
Hi

Probably I have not been following this stream of discussion, but can you clarify what Roles you are concerned?

As far as I can see there is nothing in BPEL4People 1.0 to define any Roles regarding to Tasks and Task Life-Cycle related operations.

The only thing I can see is that it is possible to pre-assign Tasks to people that is defined by the People Assignment (logical persons or groups) and to deny them whether they can claim or not, or to allow those potential users to "claim" Tasks. This will change what operations they may perform on Task life-cycle control.

However, this must be rather self-evident as to what "operations" they are allowed. Is the proposal still addressing this to use getTaskOperations(taskID), to simply return what operations are possible depending on the State the Task is in? Eg. The Task which has not "Started" obviously cannot be "Exited". Although this should be also self-evident.

Maybe the specification can present the State Machine state transition table for this as a guide? I am not aware of any other "roles" that may change possible  "buttons" to depict on the client UI of the Task Inbox application (or Task List application as in BPEL4People, that will communicate with a Task Manager - although Task Manager or its address is not defined in BPEL4People).

Also, If it is rather to do with freely defined Roles with different abilities given, one must be able to define those Roles somewhere first. Is that in the BPEL4People 1.1 or the recent Sub-task proposal?

I wonder whether there may be a confusion about Roles used in Task application implementations? As far as I know, their names can be used in Task definitions to assign Logical People but they are not related to Task life-cycle Operations, because only one person is allowed to do those Tasks (even in the parallel Task situations and they are all the same "Role" in the Task).

Although I know in human activities in other applications, the ability to use Task defined Roles is really important and I was going to bring it up later, but the email talking about the Operations below (Task life-cycle Operations) does not sound like anything to do with it.

Yoichi

--------------------------------------------------------------------------
Yoichi Takayama, PhD
Senior Research Fellow
RAMP Project
MELCOE (Macquarie E-Learning Centre of Excellence)
MACQUARIE UNIVERSITY

Phone: +61 (0)2 9850 9073
Fax: +61 (0)2 9850 6527
--------------------------------------------------------------------------
MACQUARIE UNIVERSITY: CRICOS Provider No 00002J

This message is intended for the addressee named and may contain confidential information.  If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of Macquarie E-Learning Centre Of Excellence (MELCOE) or Macquarie University.

On 09/12/2008, at 2:19 PM, Michael Rowley wrote:


[For the original issue, see the bottom of this email]

PROPOSAL:
1) Introduce a new operation called: getTaskOperations(taskID).
 
This operation returns list of operations that are available to the authorized user given the user's role and the state of the task.
 
The response element getTaskOperationsResponse contains the set of elements whose name is the same as the operation. For example, for a task in Ready state:
 
<getTaskOperationsResponse>
  <taskOperations>
    <claim/>
    <start/>
    <addComment/>
    <addAttachment/>
    <setPriority/>
  </taskOperations>
</getTaskOperationsResponse>
 
A task inbox/listing application can use the existence of these task operation elements to determine whether to render the operation UI buttons such as claim and start. Without this information, the inbox application may have to implement its own logic on the client side to determine the available operations.
 
2) Include <taskOperations/> element in tasks that are returned in getMyTask operation (Sec 6.1.2).
 
The proposed changes to the task api wsdl and schemas are:
 
<!-- taskOperations port type in ws-humantask-api.wsdl  -->
<wsdl:operation name="getTaskOperations">
   <wsdl:input message="getTaskOperations" />
   <wsdl:output message="getTaskOperationsResponse" />
   <wsdl:fault name="illegalArgumentFault"
     message="illegalArgumentFault" />
   <wsdl:fault name="illegalAccessFault"
     message="illegalAccessFault" />
</wsdl:operation>
 
<!-- messages in ws-humantask-api.wsdl  -->
<wsdl:message name="getTaskOperations">
  <wsdl:part name="getTaskOperations" element="htdt:getTaskOperations" />
</wsdl:message>
<wsdl:message name="getTaskOperationsResponse">
  <wsdl:part name="getTaskOperationsResponse" element="htdt:getTaskOperationsResponse" />
</wsdl:message>
 
<!-- htdt schema ws-humantask-api-wsdl.xsd (http://www.example.org/WS-HT/api/xsd) -->
<xsd:element name="getTaskOperations">
 <xsd:complexType>
   <xsd:sequence>
     <xsd:element name="identifier" type="xsd:anyURI" />
   </xsd:sequence>
 </xsd:complexType>
</xsd:element>
 
<xsd:element name="getTaskOperationsResponse">
   <xsd:complexType>
     <xsd:sequence>
         <xsd:element ref="api:taskOperations" />
     </xsd:sequence>
   </xsd:complexType>
</xsd:element>
 
<!-- definiton of taskOperations element in ws-humantask-api.xsd  (http://www.example.org/WS-HT/api) -->
<xsd:complexType name="tTaskOperation"/>
<xsd:element name="taskOperations">
   <xsd:complexType>
      <xsd:all>
         <xsd:element name="claim" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="start" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="stop" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="release" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="suspend" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="suspendUntil" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="resume" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="complete" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="remove" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="fail" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="setPriority" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="addAttachment" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getAttachmentInfos" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getAttachments" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="deleteAttachments" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="addComment" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getComments" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="skip" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="forward" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="delegate" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getRendering" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getRenderingTypes" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getTaskInfo" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getTaskDescription" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="setOutput" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="deleteOutput" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="setFault" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="deleteFault" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getInput" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getOutput" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="getFault" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="activate" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="nominate" type="tns:tTaskOperation" minOccurs="0"/>
         <xsd:element name="setGenericHumanRole" type="tns:tTaskOperation" minOccurs="0"/>
      </xsd:all>
   </xsd:complexType>
</xsd:element>
 
<!--
   Changes to tTask complex type defined in ws-humantask-api.xsd (http://www.example.org/WS-HT/api)
   The addition here is the reference to the taskOperations element defined towards the end of the sequence.
 -->
 
<xsd:complexType name="tTask">
 <xsd:sequence>
   <xsd:element name="id" type="xsd:string" />
   <xsd:element name="taskType" type="xsd:string" />
   <xsd:element name="name" type="xsd:QName" />
   <xsd:element name="status" type="tStatus" />
   <xsd:element name="priority" type="xsd:nonNegativeInteger"
     minOccurs="0" />
   <xsd:element name="taskInitiator" type="htd:tUser"
     minOccurs="0" />
   <xsd:element name="taskStakeholders"
     type="htd:tOrganizationalEntity" minOccurs="0" />
   <xsd:element name="potentialOwners"
     type="htd:tOrganizationalEntity" minOccurs="0" />
   <xsd:element name="businessAdministrators"
     type="htd:tOrganizationalEntity" minOccurs="0" />
   <xsd:element name="actualOwner" type="htd:tUser" minOccurs="0" />
   <xsd:element name="notificationRecipients"
     type="htd:tOrganizationalEntity" minOccurs="0" />
   <xsd:element name="createdOn" type="xsd:dateTime" />
   <xsd:element name="createdBy" type="xsd:string" minOccurs="0" />
   <xsd:element name="activationTime" type="xsd:dateTime"
     minOccurs="0" />
   <xsd:element name="expirationTime" type="xsd:dateTime"
     minOccurs="0" />
   <xsd:element name="isSkipable" type="xsd:boolean" minOccurs="0" />
   <xsd:element name="hasPotentialOwners" type="xsd:boolean"
     minOccurs="0" />
   <xsd:element name="startByExists" type="xsd:boolean"
     minOccurs="0" />
   <xsd:element name="completeByExists" type="xsd:boolean"
     minOccurs="0" />
   <xsd:element name="presentationName" type="tPresentationName"
     minOccurs="0" />
   <xsd:element name="presentationSubject"
     type="tPresentationSubject" minOccurs="0" />
   <xsd:element name="renderingMethodExists" type="xsd:boolean" />
   <xsd:element name="hasOutput" type="xsd:boolean" minOccurs="0" />
   <xsd:element name="hasFault" type="xsd:boolean" minOccurs="0" />
   <xsd:element name="hasAttachments" type="xsd:boolean"
     minOccurs="0" />
   <xsd:element name="hasComments" type="xsd:boolean"
     minOccurs="0" />
   <xsd:element name="escalated" type="xsd:boolean" minOccurs="0" />
   <xsd:element name="primarySearchBy" type="xsd:string"
     minOccurs="0" />
  
   <!-- New element -->
   <xsd:element ref="tns:taskOperations" minOccurs="0" />  
    
   <xsd:any namespace="##other" processContents="lax" minOccurs="0"
     maxOccurs="unbounded" />
 </xsd:sequence>
</xsd:complexType>


Luc Clement wrote:
>
> Assigned: http://www.osoa.org/jira/browse/BP-44
>
>  
>
> From: Michael Rowley [mailto:michael.rowley@activevos.com]
> Sent: Wednesday, October 01, 2008 10:56
> To: bpel4people@lists.oasis-open.org
> Subject: [bpel4people] NEW ISSUE: Discovering the operations available for the task
>
>  
>
>  
>
> TARGET: WS-HT
>
>  
>
> DESCRIPTION:
>
>  
>
> The operations that are available for a task varies depending on the state that the task is in and the role of the person who might do the operation.  The task API should make it possible to ask which operations are currently available for a task for a specific user.
>
>  
>
> PROPOSAL:
>
>  
>
> None yet.

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]