On Jun 18, 10:38 am, Lukasz Szybalski <[email protected]> wrote:
> On Jun 18, 7:26 am, "Dan Winslow" <[email protected]> wrote:
>
>
>
> > "... that should be enough."
>
> > Should be enough for whom? Depending on people to behave correctly when
> > using information systems often causes problems.
>
> > I don't know of any simple database-based way given the
> > architecture...db level locking is problematic in a web environment, and
> > SQLITE anyways uses file-level update locking.
>
> > My approach is to block anyone who is not the owner (or TRAC_ADMIN) from
> > doing most operations on a ticket. You can use the
> > VirtualTicketsPermissions plugin to restrict your choice of workflow
> > operations to owner only. That does not block folks from changing ticket
> > properties, however, and so I looking at some other plugins for that. I
> > am hoping that blackmagictweaks can do that, although I know I will have
> > to modify it as it does not pay attention to owner and current user
> > relationship.
>
> > The concept of permissions, workflow, and command dependence on Owner ==
> > Current User is a basic ticket system concept and is missing from TRAC
> > core, as far as I can tell. I'm hoping it gets included in the next
> > versions.
>
> So my options right now are
> 1. Provide user with batch change options so they can assign 20
> tickets to them selfs then get "my tickets" and work on these.
> 2. Tell the user to communicate with each other on who will do what?
> 3. Or tell them to assigned tickets to them self and force edit only
> if you are an owner? Is there a permission for that? What happens when
> somebody else has a solution for the ticket, how would they reassigned
> to themself if they are not the owner?
>
> Seems like option #1 is least restrictive and might give me the
> results I'm looking for. Any other options?
>
> Thanks,
> Lucas
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
>
> > On Behalf Of Tomek Grzechowski [k3o]
> > Sent: Wednesday, June 17, 2009 4:34 PM
> > To: [email protected]
> > Subject: [Trac] Re: [task] Locking Ticket # while working on it?
>
> > yeah,
>
> > a person can accept a ticket and the ticket will have its status
> > changed to assigned.
>
> > another person should not work on a ticket that has status eq assigned.
>
> > that should be enough.
>
> > 2009/6/17 Lukasz Szybalski <[email protected]>:
>
> > > Hello,
> > > We have setup our trac to monitor our high volume of tasks(500 a day).
> > > We've put in out task in milestone categories. Now we have 2 or 3
> > > people that are working on particular milestone and tasks in it. While
> > > one opened the ticket, and is working on it (average 3 minutes)
> > > another person pulls the same report and starts working on the same
> > > ticket.
>
> > > Is there a solutions that would lock the ticket or notify another user
> > > that somebody is working on this ticket(preferred)?
>
> > > Thanks,
> > > Lucas
>
> > --
> > Tomek Grzechowski
> > -----------------
> > mini...@k3o; developer/programmer;http://k3o.eu
> > [email protected]; +48 662 279 869 (cell)
> > skype: miniman.k3o
this is a tough one.
for probably 99.9% of the trac users, a simple workflow step of
"accept" which moves the ticket to "inProgress" or similar suffices
for this need.
then in your "open tickets" query, you just exclude that state.
So a user A goes to the list:
opens a ticket that is "new", clicks accept, it moves to "inProgress"
User B goes to the list:
They never see the ticket that user A just accepted. (it's not "new"
so it's not in the new tickets query)
However, it sounds like, in your case, the high volume and speed at
which tickets are triaged, it is entirely possible for user B to open
a ticket between the time user A opens the ticket and clicks Accept.
Is this a correct assessment?
If that is the case, how about a plugin, that responds to ticket
create, and automatically assigns it to a user in a round robin format
or something(mod N, whatever).
Then implement the "only the owner or TICKET_ADMIN privileges" can
modify a ticket in the Assigned-> * action permission(s).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
