Hi,
Here is the UI page flow upto displaying task inbox
There are three types of tasks which need to display to a specific user:
1. ASSIGNED_TO_ME - Tasks assigned to the user
2. CLAIMABLE - Claimable Tasks where the current logged-in user can
claim (tasks that are in READY state)
2. ASSIGNABLE - Assignable tasks that tasks, where the current
logged-in user act as a Business Administrator. (tasks that are in READY
state)
3. ALL_TASKS - All tasks where the current logged-in user can see.
Here we have to decide most effective and user friendly way to display
those tasks in a way user shouldn't miss tasks specially any assigned and
claimable new tasks.
My suggestion is to view each type of tasks separately:
Inbox --> Display all ASSIGNED_TO_ME tasks
Task Pool --> Display all CLAIMABLE tasks (so user can see claimable
which is not assigned and assign to himself)
Admin Task Pool --> Display all ASSIGNABLE tasks
Any Idea where we can put all tasks (separately or within those windows) ??
suggestions are highly appreciated....
Thanks,
Milinda
On Wed, Jul 30, 2014 at 11:43 AM, Hasitha Aravinda <[email protected]> wrote:
>
> WS-HumanTask provides "rendering elements" which can be used to provide
> rendering instructions to Task Clients. Using this information, Task
> clients can construct the user interface for a given task.
>
>
> We already used rendering elements for SMS/EMAIL notification feature. IMO
> we can use HT-Rendering elements for this as well.
>
>
> The structure of the rendering element as follows.
>
> <htd:renderings>
>
> <htd:rendering type="QName">+
>
> <xsd:any minOccurs="1" maxOccurs="1" />
>
> </htd:rendering>
>
> </htd:renderings>
>
> So we can introduce 2 new types of rendering elements to render TaskInput
> and TaskOutput.
>
> Rendering Task Input
>
> Within rendering element, we define our input html. One advantage of this
> method is we can easily use ht presentation parameters (eg: $amount$) and
> humantask xpath functions ( eg: getInput()) within rendering elements
> scope.
>
> For example:
>
> <htd:renderings>
>
> <htd:rendering type="input">
>
> <wso2:html><![CDATA[
>
> <table>
>
> <tr>
>
> <td>Customer Name<td>
>
> <td>htd:getInput("ClaimApprovalRequest")/customer/name<td>
>
> </tr>
>
> <tr>
>
> <td>Amount<td>
>
> <td>$amount$<td>
>
> </tr>
>
> </table>
>
> ]]></wso2:html>
>
> </htd:rendering>
>
> </htd:renderings>
>
>
>
> Rendering Task Output and Response.
>
> Similar to task input we define html form here. But generating the taskout
> from html form is the tricky part. This the one of the method, which came
> into my mind. See following example.
>
>
> For example:
>
> <htd:renderings>
>
> <htd:rendering type="output">
>
> <wso2:html>
>
> <![CDATA[
>
> <strong>New Amount</strong>
>
> <form>
>
> Amount :<input type="text" name="amountElement" init="$amount$"
> save="htd:getOutput()/tns:amount"
> />
>
> Approve : <select name="approvedElement" init="" save="
> htd:getOutput()/tns:approve">
>
> <option value="true">YES</option>
>
> <option value="false">FALSE</option>
>
> </select>
>
> </form>
>
> ]]>
>
> </wso2:html>
>
> <wso2:taskOutput>
>
> <tns:result xmlns:tns="http://wso2.org/sampleHT";>
>
> <tns:newamount>
>
> wso2:getHTMLValue("amountElement")
>
> </tns:newamount>
>
> <tns:approve>
>
> wso2:getHTMLValue("approvedElement")
>
> </tns:approve>
>
> </tns:result>
>
> </wso2:taskOutput>
>
> </htd:rendering>
>
> </htd:renderings>
>
>
> Here we use wso2:html to specify the html code and wso2:taskOutput is
> used to specify raw task output. Using above configuration, HT engine will
> generate following html code.
>
> <strong>New Amount</strong>
>
> <form>
>
> Amount :<input type="text" name="amountElement" value=
> "initialValueOrSavedValue"/>
>
> Approve :<select name="approvedElement" >
>
> <option value="true" selected>YES</option>
>
> <option value="false">FALSE</option>
>
> <select>
>
> </form>
>
> <script type="text/javascript">
>
> createTaskOutput = function()
>
> {
>
> return '<tns:result xmlns:tns="http://wso2.org/sampleHT";>'
>
> + '<tns:newamount>'
>
> + document.getElementsByName("amountElement")[0].value +
>
> + '</tns:newamount>'
>
> + '<tns:approve>'
>
> + document.getElementsByName("approvedElement")[0].value
>
> + '</tns:approve>'
>
> + '</tns:result>' ;
>
> }
>
> </script>
>
> Above generated code will compatible with our existing HumanTask UI. So we
> can use same to render tasks in management console as well.
>
> Here we will have to use additional attributes (init and save) to support
> save function. "init" attribute will be used to render initial value while
> "save" attribute will be used to retrieve intermediates value.
>
>
> How does Clients get Rendering elements ?
>
> WS-HumanTask spec provides getRendering() and getRenderingTypes() api
> functions to retrieve task renderings.
>
> What happens, If there are no presentation elements for Input/Output ?
>
> We can simply show raw input xml for the input. Or we can use simple js
> util to convert raw xml into html form.
>
> For the output, we can give a text field, to specify raw xml output. Or we
> can further improve this to generate html form by referring wsdl message.
> IMO this will take lot of time, since it is like writing a new tryIt tool.
>
>
>
>
> Your suggestions on above approach are appreciated.
>
> Thanks,
>
> Hasitha.
>
>
>
> On Mon, Jul 28, 2014 at 11:08 PM, Nandika Jayawardana <[email protected]>
> wrote:
>
>> Hi Milinda,
>>
>> we need to come up with a method for form generation to cater for input
>> and outout, response of human tasks. One option is to use the renderings
>> element to specify form information and use that to generate the ui.
>> Additionally, we could provide a way to specify input output and reponse as
>> Jaggery files like we do with the current jsp model in case renderings
>> are not defined.
>>
>> Regards
>> Nandika
>>
>>
>> On Mon, Jul 28, 2014 at 10:00 AM, Milinda Perera <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>>
>>> We are planning to implement Jaggery based UI for WS-Human Tasks [1] in
>>> BPS.
>>>
>>> Currently BPS doesn’t have user interface for WS-HumanTasks separated
>>> from admin console. So I’m working on developping jaggery based webapp
>>> which can deploy seperately from the BPS.
>>>
>>> Following diagram depicts the basic architecture.
>>>
>>>
>>>
>>> The webapp use Admin services (HumanTaskClientAPIAdmin,
>>> AuthenticationAdmin) provided by BPS to retrieve and update human tasks.
>>>
>>> Functionalities:
>>>
>>> -
>>>
>>> List tasks assigned to user in the inbox including graphical
>>> representation for task completion progress.
>>> -
>>>
>>> List all the task information.
>>> -
>>>
>>> Provide all the operations to manipulate tasks.
>>> -
>>>
>>> Isolate user interface from BPS.
>>>
>>>
>>> Highly appreciate for any suggestions to improve this.
>>>
>>>
>>> I will update (including UI design) with the progress.
>>>
>>> [1] https://wso2.org/jira/browse/BPS-527
>>>
>>> Thanks,
>>> milinda
>>>
>>>
>>> --
>>> Milinda Perera
>>> Software Engineer;
>>> WSO2 Inc. http://wso2.com ,
>>> Mobile: (+94) 714 115 032
>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Nandika Jayawardana
>> Senior Technical Lead
>> WSO2 Inc ; http://wso2.com
>> lean.enterprise.middleware
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Hasitha Aravinda,
> Software Engineer,
> WSO2 Inc.
> Email: [email protected]
> Mobile: +94 71 8 210 200
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Milinda Perera
Software Engineer;
WSO2 Inc. http://wso2.com ,
Mobile: (+94) 714 115 032
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
