Alloww several users to work on the same ticket. & 1 user on more than one ticket

[apatruduque@…]

Hi coling:

First of all, congratulations for this nice plugin. I'm using it to manage the projects of my team and we found it very useful.

We are making some modifications (actually I'm are testing them already) in order to allow more than one user to work on the same ticket. We do a lot of pair programming so it's quite common to have two members of our team spending time on the same tasks.

What we are doing is using a ticket custom field (worklogusers) which contains a comma separated list of users which are allowed to work on a ticket. Users listed here can start and stop work on the ticket. This option can be activated/deactivated using a new worklog option called multipleusers.

I don't have all the time I would like to code this, but I hope next week I can submit a patch with the new functionality. We have used revision r2571 as starting point.

Regards,

Alfonso

[apatruduque@…]

multiple users patch.

[apatruduque@…]

hack to allow multiple users to work on the same ticket. Removed log functions which write debug messages to /tmp/log.txt.

[apatruduque@…]

Hi:

As we say here in spain: "lo prometido es deduda". I have attached a patch against revision 2571 which allows multiple users to work on the same ticket. Use the second attachment multipleusers.diff.2.gz​, the first one contains calls to a log function which writes debug messages to /tmp/log.txt.

I've changed quite a few things:

1. A new boolean configuration option called 'multipleusers' has been added. This option can be activated/deactivated through the admin page.
2. A new custom field (worklogusers) is used to store a list of users who are allowed to start and stop work on a ticket when multipleusers=True
3. the function who_is_working_on returns now a dictionary called workers (workers[name]->since) which contains all the users which are working on a ticket. In order to use it, lines with code

   who,since = self.woh_is_working_on()
   

   where replaced by

   workers = self.woh_is_working_on()
   who,since = workers.popitem()
   

4. function can_work_on() has been splitted into two functions:
   • can_work_on_single_user() -> which returns true if a user can work on a ticket when multipleusers=False
   • can_work_on_multiple_users() -> idem when multipleusers=True
5. If a ticket is closed, the autostop option is active and more than one user is working on a ticket, all work in progress is stopped through the stop_all_work function.
6. I've done a small refactoring of the stop_work function in order to use common code for both stop_work and stop_all_work.

The patch does the trick for me but it needs more testing and probably quite a bit of refactoring. Please, take into account that this is the first time I use python and get into the details of the Trac program. Be forgiving when you read the code ;-), you will probably find things not properly coded.

Again, be aware that this is work in progress, it has not been fully tested and it will probably have issues and bugs.

Any comments and suggestions are of course wellcome. Hope you find it useful.

TODO

• Refactoring.
• Integration with XMLRPC.
• Give the posibility to only allow the owner of the ticket to close it when more than one user is working on it.

Regards,

Alfonso

[Colin Guthrie]

Hi,

Apologies for not leaving a comment here sooner. This sounds promising. I always intended for worklog to only allow single working at any given time but a few people have mentioned this so I guess people will find it useful.

If you've got further changes since your last comment please attach a new diff, if not I'll maybe take a look at what you've got here sometime soon.

Thanks for your help :)

[apatruduque@…]

Hi,

Good to know other people will use it.

I have not done anything else but testing it in our trac system (production) and it is apparently working. I'm looking forward to hear your comments.

Regards, and thank you for such a helpful plugin.

Alfonso.

Replying to coling:

Hi,

Apologies for not leaving a comment here sooner. This sounds promising. I always intended for worklog to only allow single working at any given time but a few people have mentioned this so I guess people will find it useful.

If you've got further changes since your last comment please attach a new diff, if not I'll maybe take a look at what you've got here sometime soon.

Thanks for your help :)

[Colin Guthrie]

Would you be able to supply a unified diff (diff -u) which is the default when you do "svn diff" and resubmit your patch please?

Currently it does not apply (I did make a small change today so that may have affected it), but the format of the diff is a bit odd and contains bangs at the start of the line etc. I beleive this is a different format of diff, but it makes life a little awkward for me as I'm only really used to dealing with unified diff format. If it's too much hassle don't worry too much, but please let me know... :)

[apatruduque@…]

Dear Coling:

First of all, I would like to apologize for not answering you before. Unfortunately, I was quite busy at work by the time you wrote this comment and then I got quite sick for almost a month.

I would like to catch up with this, if it's not too late. Could you finally use the patch a I sent? This week I will try to merge the newest version of your plugin with my modifications, lets see what comes out.

Good news is that the changes have been working smoothly in our server for more a than a month.

Regards,

Alfonso.

Replying to coling:

Would you be able to supply a unified diff (diff -u) which is the default when you do "svn diff" and resubmit your patch please?

Currently it does not apply (I did make a small change today so that may have affected it), but the format of the diff is a bit odd and contains bangs at the start of the line etc. I beleive this is a different format of diff, but it makes life a little awkward for me as I'm only really used to dealing with unified diff format. If it's too much hassle don't worry too much, but please let me know... :)

[elock.swapnil@…]

Trac detected an internal error:

KeyError: u'complete'

File "build/bdist.win32/egg/trac/web/main.py", line 511, in _dispatch_request 
File "build/bdist.win32/egg/trac/web/main.py", line 237, in dispatch 
File "build/bdist.win32/egg/worklog/webui.py", line 130, in process_request 
File "build/bdist.win32/egg/worklog/manager.py", line 138, in start_work 
File "build/bdist.win32/egg/worklog/manager.py", line 218, in stop_work 
File "build/bdist.win32/egg/worklog/manager.py", line 77, in save_ticket 
File "build/bdist.win32/egg/trac/ticket/model.py", line 360, in save_changes 
File "build/bdist.win32/egg/ganttcalendar/complete_by_close.py", line 30, in ticket_changed 

I am new to trac,im getting this error. why it is? What if somebody wants to work on more than 1 ticket.

[joepubber@…]

Since this patch is a few years old, does it still apply to trunk?