Defect #13172
openChanging assignee then tracker or status reverts unsaved assignee change (during issue edit/update)
0%
Description
In update issue view, when first changing assignee, then status, the assignee field is reverted to the previous state.
Environment: Redmine version 2.2.2.stable Ruby version 1.8.7 (i686-linux) Rails version 3.2.11 Environment production Database adapter SQLite
Related issues
Updated by Jean-Philippe Lang over 11 years ago
- Subject changed from Update issue: Changinge status reverts assignee field to Update issue: Changinge assignee then status reverts assignee
Updated by Mischa The Evil over 11 years ago
- Subject changed from Update issue: Changinge assignee then status reverts assignee to Update issue: Changing assignee then status reverts assignee
Updated by Dietmar H over 11 years ago
Changing Tracker has the same effect. Looks like all operations triggering Ajax requests reset the assignee field.
Updated by Dietmar H about 11 years ago
Does nobody have this issue or does nobody care? We find it quite annoying.
Config now is:
Environment: Redmine version 2.2.3.stable Ruby version 1.9.3 (i686-linux) Rails version 3.2.12 Environment production Database adapter Mysql2
Updated by Mischa The Evil about 11 years ago
- Subject changed from Update issue: Changing assignee then status reverts assignee to Changing assignee then tracker or status reverts unsaved assignee change (during issue edit/update)
- Status changed from New to Confirmed
I have done some testing for this issue. I am able to reproduce the described behavior:
- Environment:
- Redmine 2.3.1.devel.11845 (trunk)
- Ruby 1.9.3 & 2.0.0 [x86_64-linux]
- Rails 3.2.13
- Database adapter: Mysql2
- Redmine plugins: no plugins installed
- Steps to reproduce:
- Load Redmine default config
- Create new issue
- Assign the new issue an assignee (e.g.
admin
) - Update/edit the issue (but don't submit the form)
- Change the value of the assignee field (
<< me >>
is sufficient for this use-case) - Change the tracker or status field value (which - as expected - triggers an Ajax request)
- Change the value of the assignee field (
- Current behavior:
- After 4.2: the assignee field value is reset from the new value (
<< me >>
, see 4.1) to the old value (admin
, see 3)
- After 4.2: the assignee field value is reset from the new value (
- Expected behavior:
- After 4.2: the assignee field value is kept (still
<< me >>
, see 4.1)
- After 4.2: the assignee field value is kept (still
Updated by @ go2null over 8 years ago
The issue is that changing the status applies the new status, which it should not do as the new status is just a change, like any other other change done.
That is the new status permissions should NOT be enforced/triggered when in the input form.
Duplicate issue: Defect #13250
Updated by Toshi MARUYAMA over 8 years ago
- Related to Defect #13250: Status change refresh problem - cannot write fileds writeable in a given statatus added
Updated by Dietmar H over 7 years ago
Seems to be solved in 3.3.1 (don't know about older version).