John,
Thanks for the tips.
With process versioning the problem is that new process versions tend
to need new task forms and new participants while the old process
versions are still running and need the old ones. So using :revision
as you say is only a beginning. The question is how to version tasks
and participants. From development point of view suffixing classes has
such an advantage that you just copy your class on the beginning of
the work leaving old version intact. Adding version as an argument
would give us nicer code but bring high possibility of braking old
processes.
For rendering "yes" "no", I did not make clear what I mean. I would
like the task definition in the process to contain sth. like this:
junior, :task => "fix pipe", :answers => "fixed, not fixed"
senior, :task => "fix pipe again", :if => "${f:answer} == fixed"And render "fixed", "not fixed" buttons in place of "proceed" button. I now how to do it technically. But my questions are: Was it done before? If yes, are there some custom names and format for that? If not do you like the names provided here? Hope this time it is clearer. I managed to implement claim, no errors found this time sorry ;) All the best, Jan On 24 Mar, 20:03, John Mettraux <[email protected]> wrote: > On Thu, Mar 24, 2011 at 10:31:17AM -0700, simcha wrote: > > > Thanks for very quick fix :) It works fine, at least for me ;) > > I made version with pagination and separate lists of tasks per user > > and his/hers groups. > > I found next issue on my wayhttps://github.com/jmettraux/ruote/issues/23 > > but made and workaround so it is working for now. > > Hello, > > many thanks for the issue, I will take care of it tomorrow hopefully. > > > Next things I am willing to implement are: > > 1. Issue claiming from group and realising back to original group. > > 2. Process versioning => here I am not sure how to do it. I am > > considering use of suffix V1 , V2 in class names or asset names of > > processes, participants and tasks. And to call them based on process > > version number. On one hand it is not looking very nice on the other I > > have no second idea. What you think? > > you can do > > Ruote.process_definition :name => 'x', :revision => '1.0b' do > end > > and then > > RuoteKit.engine.processes.each do |pr| > puts "#{pr.definition_name} #{pr.definition_revision}" > end > > > 3. Access control based on process. > > 4. Process history and auditing. > > https://github.com/jmettraux/ruote/blob/440dc90d4b88ee8ba4de5340b5c7d... > https://github.com/jmettraux/ruote/blob/440dc90d4b88ee8ba4de5340b5c7d... > > > 5. Some way to render buttons with answers like "yes" "no" instead of > > "proceed" only. > > Based on task definition in the process preferably. > > Many many possibilities here. One small example: > > https://github.com/jmettraux/quaderno > > > 6. Search in task list. > > Ruote::StorageParticipant#query > > > 7. Way to schedule absences and to redirect tasks assigned to absent > > user both based on schedule and manually by administrator. > > > Long list but some day... > > Good luck ! > > Kind regards, > > -- > John Mettraux -http://jmettraux.wordpress.com -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
