ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Cannot bulk edit custom field of type "user" (Bug #1062)
| Status: | Open | Start date: | 2012-07-04 |
|---|---|---|---|
| Priority: | Normal | Due date: | |
| Assignee: |  Felix Schäfer |
% Done: | 0% |
| Category: | Custom Fields | ||
| Target version: | - | ||
| Remote issue URL: | Affected version: | 3.2.2 |
Description
Subject says it all ;)
when trying to bulk edit several issues, the custom fields of type "user" only have "no change" as the possible choice.
Associated revisions
Redirected user to where he is coming from after logging hours (#1062).
git-svn-id: http://redmine.rubyforge.org/svn/trunk@1354 e93f8b46-1217-0410-a6f0-8f06a7374b81
History
Updated by Felix Schäfer at 2012-07-09 06:43 pm
Does this happen only when there are already different values in the fields? Could you try to see what happens if the value for this field in the issues is already the same to begin with? Also: Are the issues from multiple projects or only in one?
Updated by Christophe Deliens at 2012-07-10 12:35 pm
Felix Schäfer wrote:
All test cases resulted to the same outcome: "no change" is the only possible dropdown option when bulk editing.Does this happen only when there are already different values in the fields? Could you try to see what happens if the value for this field in the issues is already the same to begin with?
Tested:
- selecting multiple issues having that field unset
- selecting multiple issues having that field set to A
- selecting multiple issues having that field set to A or B
- selecting multiple issues having that field unset or set to A
Also: Are the issues from multiple projects or only in one?
Only in one.
Updated by Felix Schäfer at 2012-07-10 12:44 pm
OK, thanks for the tests, I'll see if I can reproduce this and what it could be due to.
Updated by Felix Schäfer at 2012-07-10 12:45 pm
- Assignee set to Felix Schäfer
Updated by Felix Schäfer at 2012-07-10 06:40 pm
OK, I can reproduce this and I've corrected the positioning of the custom fields (at least locally), regarding the content of the drop-down: the only users available for this field are the members of the project, and there's currently no (easy) way to populate the drop-down based on whether you're bulk editing issues of the same project or not. Note that this applies to all custom fields of the type "list", i.e. users, versions and normal lists.
Updated by Christophe Deliens at 2012-07-13 03:00 pm
I'm glad you could reproduce the bug!
Felix Schäfer wrote:
(...) the only users available for this field are the members of the project, (...)
In my case, the list is always empty. I don't even have the members of the project listed, which is all I want. We don't need to bulk-edit issues from multiple projects... for now ;)
I hope you can come up with a solution.
Updated by Felix Schäfer at 2012-07-13 09:36 pm
Christophe Deliens wrote:
Felix Schäfer wrote:
(...) the only users available for this field are the members of the project, (...)
In my case, the list is always empty. I don't even have the members of the project listed, which is all I want. We don't need to bulk-edit issues from multiple projects... for now ;)
I meant the general case, when I bulk-edit issues even from the same project I don't see anything in there either.
I hope you can come up with a solution.
As I said, I fear it would need some rework of the bulk-edit parts, but I'll try to keep it in mind :-)