I sometimes find myself in a situation that I want to customize the
actual form, instead of the workflow frontend. but that requries work
on Designer side as well.
(What I really like, is my page just sit there, accept an XML input,
and generates an XML output, just like AJAX forms, but without the
heavy weight JSX mapping and stuff)
for the axis response some of them are sent via ws-addressing (async
operations especially), and in old TMS some just doesn't follow the
WSDL.
and for the reassign in ui-fw, it works like this, you choose EITHER a
role, OR a user, and assign the task to it/him.the available user/role
list is compiled from current user's role (e.g. if you have role
intalio\A and intalio\B, you can reassign to role intalio\A or intalio
\B, or any user of role A and B)
> I sometimes find myself in a situation that I want to customize the
> actual form, instead of the workflow frontend. but that requries work
> on Designer side as well.
I am planning to work in xform design too in the near future (well 5-6
month ahead). xform is nice, Orbeon forms allow us some things that
jsp alone don't. Like pdf forms, etc. Just it need to be customized.
> for the axis response some of them are sent via ws-addressing (async
> operations especially), and in old TMS some just doesn't follow the
> WSDL.
What I was meaning is the kind of OMElement Response of the
SendReceive service wrapper used in RemoteAbsenceRequestTest class.
> and for the reassign in ui-fw, it works like this, you choose EITHER a
> role, OR a user, and assign the task to it/him.the available user/role
> list is compiled from current user's role (e.g. if you have role
> intalio\A and intalio\B, you can reassign to role intalio\A or intalio
> \B, or any user of role A and B)
That's the point, in real life you are not always granted to reassign
your task to another mate just because he is in the same role. There
must be rules, like manager-employee relation or start a delegation
request for acceptance and worst supervised delegation. It is a
process by itself with his own rules.
Another point is that I am guessing when we need to skip a task, or
better if I have rights at all to do that, and too: what happends if
anybody skip the same task. And with delete a task is more or less the
same.
The idea behind that interface is to discover or rethink some
scenarios for which task operations apply.
For example: saved tasks view is intended for tasks claimed that are
waiting for completion
assigned tasks is intended for tasks directly
assigned for a manager
delegated tasks is for tasks related to
delegation request of another task in order to abort the delegation
process if necessary. Delegation process may abort also on time basis.
At present designed tempo task's states fall short, and I need to
learn how to extend it. So with delegation using task meta data.
For each view and according to task state there is a list of allowed
actions to the user. There maybe more needed actions I like to
encounter them too.
I'll be happy if anyone help me with the answers or give me some
ideas.
Best Regards,
Gil.
>> and for the reassign in ui-fw, it works like this, you choose EITHER a
>> role, OR a user, and assign the task to it/him.the available user/role
>> list is compiled from current user's role (e.g. if you have role
>> intalio\A and intalio\B, you can reassign to role intalio\A or intalio
>> \B, or any user of role A and B)
> That's the point, in real life you are not always granted to reassign
> your task to another mate just because he is in the same role. There
> must be rules, like manager-employee relation or start a delegation
> request for acceptance and worst supervised delegation. It is a
> process by itself with his own rules.
And you are totally right. You should always have a custom service to
send you a list of people the task is available to, each task having
different reassign policies, each company also having different
reassign rules.
The fact is, in production most users DO change this.
I developed this as an example of the reassign method and have been
kind of waiting for an open source contribution to a simple reassign
service. ;)
> Another point is that I am guessing when we need to skip a task, or
> better if I have rights at all to do that, and too: what happends if
> anybody skip the same task. And with delete a task is more or less the
> same.
The RBAC code is there to do that. You can customize the button to be
available to certain users/roles and not others.
> At present designed tempo task's states fall short, and I need to
> learn how to extend it. So with delegation using task meta data.
>
> For each view and according to task state there is a list of allowed
> actions to the user. There maybe more needed actions I like to
> encounter them too.
Comments and proposition are very welcome. Up to now we have followed
closely the specs of Bpel4People but they may very well be limited and
I would love to hear about the metadata you need, or the other task
states you are thinking about.
Again, congrats to Gil for the great look of the UI.
Nico
> --
> You received this message because you are subscribed to the Google Groups "tempo-dev" group.
> To post to this group, send email to temp...@googlegroups.com.
> To unsubscribe from this group, send email to tempo-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tempo-dev?hl=en.
>
>
>, each task having
> different reassign policies, each company also having different
> reassign rules.
> The fact is, in production most users DO change this.
> I developed this as an example of the reassign method and have been
> kind of waiting for an open source contribution to a simple reassign
> service. ;)
> The RBAC code is there to do that. You can customize the button to be
> available to certain users/roles and not others.
I am thinking a lot about this matter and trying to outline a
delegation process which use some polices service. I have none
reference and this makes me dificult the way, so I am trying to fish
some ideas or scenarios. If somebody give me a scenario (and its
rules) I will be pleased trying to model it.
> Comments and proposition are very welcome. Up to now we have followed
> closely the specs of Bpel4People but they may very well be limited and
> I would love to hear about the metadata you need, or the other task
> states you are thinking about.
Maybe there is all what I need, My need is:
-know how to separate task in progress (saved), from task assigned to
me directly (assigned), from tasks I am trying to delegate to someone
else (delegated). Because they must be treated diferently.
I will be glad if some experienced tempo user could make some comments
on this.
If anybody can redirect me to articles or discussions in internet
about task states needs or delegation processes will help me a lot.
Whatever I find and make will be contributed.
Best Regards,
Gil.
>> What kind of OMElement are you thinking about ?
> First I would like to get the value returned by the SendReceive
> operation to send it back to the client.
> I used the code from RemoteAbseceRequestTest. Is there any sugestion
> about the code usage?
The test is currently its own suggestion.
Which method in particular are you trying to get a value back from ?
Message are according to the WSDL so you can parse the XML/json coming
back.
>
>>, each task having
>> different reassign policies, each company also having different
>> reassign rules.
>> The fact is, in production most users DO change this.
>> I developed this as an example of the reassign method and have been
>> kind of waiting for an open source contribution to a simple reassign
>> service. ;)
>> The RBAC code is there to do that. You can customize the button to be
>> available to certain users/roles and not others.
>
> I am thinking a lot about this matter and trying to outline a
> delegation process which use some polices service. I have none
> reference and this makes me dificult the way, so I am trying to fish
> some ideas or scenarios. If somebody give me a scenario (and its
> rules) I will be pleased trying to model it.
Well, the idea is to send to a separate delegate service something like:
- current user
- current task id
- current process id
and get in return
- userid or roleid
Then the service could be using some simple rules and check the RBAC
service to find roles, or something similar.
This is actually what is in production with enterprise users.
>
>> Comments and proposition are very welcome. Up to now we have followed
>> closely the specs of Bpel4People but they may very well be limited and
>> I would love to hear about the metadata you need, or the other task
>> states you are thinking about.
>
> Maybe there is all what I need, My need is:
> -know how to separate task in progress (saved), from task assigned to
> me directly (assigned), from tasks I am trying to delegate to someone
> else (delegated). Because they must be treated diferently.
> I will be glad if some experienced tempo user could make some comments
> on this.
> If anybody can redirect me to articles or discussions in internet
> about task states needs or delegation processes will help me a lot.
saved-> has content in the output field
assigned -> are claimed task
delegated -> .. not sure. trying to delegate, already delegated ?
Anyway, it seems we can compute the value on the server side and
return it to the client, if you give us some more details on the
delegate one.
There is possibly way more metadata you want to be able to filter on.
Nico