Project

General

Profile

Actions

Feature #6645

open

atomic 'grab' button

Added by Albert Rosenfield over 13 years ago. Updated over 13 years ago.

Status:
Reopened
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2010-10-12
Due date:
% Done:

0%

Estimated time:
Resolution:
Wont fix

Description

I'd like to see a button in Redmine to atomically make a person the "active handler" for an issue.

Background:
-----------
When Redmine is used more as a support ticket system than a software development system, there is often a necessity for answering issues quickly after their creation. (In industry parlance, I think it is called a "guaranteed response time"?)

A couple of handlers may be on duty to respond to issues. Whenever a new issue pops up, they receive it on their dashboard (whatever screen they use for that), and start replying to it.

The problem is that two or more handlers often start replying with more or less the same response to the same issue, wasting their time.

Proposed solution:
------------------
A plugin or option that, when enabled, adds a "Grab" button to the issue list, for any issues that do not currently have a handler.

When clicked, the button just makes sure that noone else has already clicked the button, and when not, it atomically assigns the case to the user that clicked it.

(If another user pressed Grab first, a message is displayed to that effect, optimally with the user name of the person who got there first.)

How this solves the problem:
----------------------------
Now, handlers can first click the "Grab" button, and only when they receive a confirmation from the system that the case is now their responsibility, will they start to update the issue.

--

I have too little experience with Redmine to know if this is possible to implement as a plugin. If anyone could mentor a bit and tell me what the main things necessary for constructing a plugin (or patch) to do the above would be, maybe I could work on it myself.

Help much appreciated :-)

Actions #1

Updated by Albert Rosenfield over 13 years ago

(Side note:

This feature would be useful in a development scenario as well, now that I think about it.  After implementing issue #6643 as well as this issue, an easy-to-use workflow for developers would be:
When idle, to go to the issue list, sorted in prioritized order, and grab the top item with a 'grab' button.
This workflow simultaneously ensures that important stuff gets worked on first (for whatever random/custom measure of important used), and that two developers are not inadvertently working on the same issue.)
Actions #2

Updated by Felix Schäfer over 13 years ago

  • Status changed from New to Closed
  • Resolution set to Wont fix

That's possible as a plugin, and probably not something that will make it into core as it is "too" specific.

What you are asking for is in essence a button that would set the status to a predefined status (say "grabbed") and the assignee to the current logged in user, which imho isn't too hard to do through the current UI.

Anyway, this plugin: Plugin_List might at least be a step in the direction of what you are looking for.

Actions #3

Updated by Albert Rosenfield over 13 years ago

  • Status changed from Closed to Reopened

What you are asking for is in essence a button that
would set the status to a predefined status (say "grabbed")

(It does not have to set a status, but it would not be a problem if it did.)

and the assignee to the current logged in user

Yes - plus, open the issue in update view if the grab succeed, so that issue is ready for user to update.
And show a popup, staying on the main issue list, if the grab did not succeed, so that another grab can be performed.

To sum these two points up; for the feature to be useful, it must integrate nicely into the user's workflow.

which imho isn't too hard to do through the current UI.

How do you mean?

probably not something that will make it into core as it is "too" specific.

It depends on how fast you need to react to issues. If you use Redmine to react to issues only very slowly, then this is not critical. For open source projects the current situation is perfectly fine.

If Redmine does not aim to be useful for business situations (or other timing critical functions) in general, then I would tend to agree that this should definitely be a plugin thing rather than in the core.

Is it OK to have requests for plugins in this tracker, or should this issue be closed?

Anyway, this plugin: #PluginSidebarIssueControl might at
least be a step in the direction of what you are looking for.

Hmm, not sure how.. how is your idea?

Actions #4

Updated by Felix Schäfer over 13 years ago

Albert Rosenfield wrote:

What you are asking for is in essence a button that
would set the status to a predefined status (say "grabbed")

(It does not have to set a status, but it would not be a problem if it did.)

and the assignee to the current logged in user

Yes - plus, open the issue in update view if the grab succeed, so that issue is ready for user to update.
And show a popup, staying on the main issue list, if the grab did not succeed, so that another grab can be performed.

To sum these two points up; for the feature to be useful, it must integrate nicely into the user's workflow.

which imho isn't too hard to do through the current UI.

How do you mean?

probably not something that will make it into core as it is "too" specific.

It depends on how fast you need to react to issues. If you use Redmine to react to issues only very slowly, then this is not critical. For open source projects the current situation is perfectly fine.

Anyway, this plugin: #PluginSidebarIssueControl might at
least be a step in the direction of what you are looking for.

Hmm, not sure how.. how is your idea?

I'm sorry I think I misunderstood you at some point. From what I gather from your answers you're looking for something on the issue list, not the issue page itself, correct? Anyway, the idea with the plugin was to have a workflow like New > Grabbed > And so on, and that someone who would grab the issue could just click on the "Grabbed" status in the sidebar. Probably not quite what you had in mind, but a step in the right direction. Tweaking the link to also assign the issue to the current user when "Grabbed" is clicked shouldn't be too hard either.

Now take all that together, put the link on the issue list rather than on the individual issues and show it only for new issues, and I think that would cover most things you mentioned. The part with "making sure no one else has grabbed it before you do" wouldn't be included, but a tad bit of educating the users could go a long way too: Make sure to refresh prior to grabbing, after grabbing make sure nobody was faster than you.

If Redmine does not aim to be useful for business situations (or other timing critical functions) in general, then I would tend to agree that this should definitely be a plugin thing rather than in the core.

Is it OK to have requests for plugins in this tracker, or should this issue be closed?

I'll go with the meta and will probably sound a little condescending, but you're just throwing with words around you. You have one very specific use case, that might also be shared by some other businesses or institutions, but there are so many use-cases out there that it's "just a drop in the water" (depends at how much you focus your view, obviously). There are a lot of businesses who use redmine as a bug tracker (and are happy with it), and redmine aims at being "flexible", i.e. useable in 80% of those use-cases. It seems your use-case falls a little farther from the pond than those 80% :-) Plugins are the way to go for those remaining 20%.

[Digression]

On a more general note, you seem to have a very clear-cut view of what you would want redmine (or let's say your issue tracker) to be, and you also seem to be able to throw some resources at it. Have you already had a look at the CommercialOfferings page? In addition to those, I'd recommend Finnlabs who from what I hear are quite successful at adapting redmine to their customer's specific needs (not affiliated, though that might change in the near future).

Actions #5

Updated by Albert Rosenfield over 13 years ago

you're looking for something on the issue list,
not the issue page itself, correct?

Exactly.

Anyway, the idea with the plugin was to have a workflow like New > Grabbed >
And so on, and that someone who would grab the issue could just click on the
"Grabbed" status in the sidebar. Probably not quite what you had in mind,
but a step in the right direction. Tweaking the link to also assign the issue
to the current user when "Grabbed" is clicked shouldn't be too hard either.

Now take all that together, put the link on the issue list rather than on the
individual issues and show it only for new issues, and I think that would cover
most things you mentioned. The part with "making sure no one else has grabbed
it before you do" wouldn't be included,

Okay, so the SideBar Plugin would need massive modification, and still it would not perform the most critical feat. Does not sound like a good solution to me. But thanks a lot for suggesting it!

but a tad bit of educating the users could go a long way too: Make sure to
refresh prior to grabbing, after grabbing make sure nobody was faster than you.

I have actually tried this using a different issue tracker, and relying on users for this did not work well. There were always a race condition, and every few days someone would hit it. Once we added atomic grab, the problem disappeared and the workflow was massively improved.

In your example, the race condition would appear when user 1 refreshes before the POST from user 2 to grab the case completes. Both users then think they are the assignee, even after refreshing.

I'll go with the meta and will probably sound a little condescending,

Okay :-).

but you're just throwing with words around you.

Not sure what you mean, feel free to elaborate.

You have one very specific use case, that might also be shared
by some other businesses or institutions, but there are so many
use-cases out there that it's "just a drop in the water"

Actually, I have done my best to pursue bending and twisting basic Redmine functionality to fit my needs. I try my best to only report when I think there is obviously some core functionality that is missing in order to accomplish things.

(See for example issue #6641. Problem solved via a plugin, but two minimal patches to core is necessary to make the plugin work.)

Concretely, for this issue, at a very basic level Redmine lacks in offering a standard method to atomically select the assignee of a case.

Once this exists, everything else can be done via a plugin, yes, agreed. (Or a refit of Redmine, since it is probably not (yet?) possible for a plugin to hook into the creation of the main issue list and add a column.)

There are a lot of businesses who use redmine as a bug tracker (and are happy with it),

Fair enough, that was my point exactly. In my point of view, a few more features are necessary to use Redmine as anything beyond a simple bug tracker, and I'm in no position to say whether Redmine as a project should aim to include these few extra core features or not.

It seems your use-case falls a little farther from the pond than those 80% :-)

It could be said that everything outside Redmine's current feature set is outside those 80%. Since by the forces of nature no-one uses Redmine for things that it is not able to do, people who request actual new core functionality are automatically in a minority.

Features and adaptation go hand in hand, in other words.

Plugins are the way to go for those remaining 20%.

As mentioned above, a minimal set of standardization and core functionality is necessary before you can do plugins.

On a more general note, you seem to have a very clear-cut view of what
you would want redmine (or let's say your issue tracker) to be, and you
also seem to be able to throw some resources at it. Have you already had
a look at the CommercialOfferings page? In addition to those, I'd recommend
Finnlabs

Very nice link, thanks. I will definitely look into this. Albeit the discussion in this issue still seems to be relevant and valid.

Actions

Also available in: Atom PDF