Defect #13172

Changing assignee then tracker or status reverts unsaved assignee change (during issue edit/update)

Added by Dietmar H over 4 years ago. Updated 7 months ago.

Status:ConfirmedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution: Affected version:2.2.2

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

Related to Redmine - Defect #13250: Status change refresh problem - cannot write fileds write... New

History

#1 Updated by Jean-Philippe Lang over 4 years ago

  • Subject changed from Update issue: Changinge status reverts assignee field to Update issue: Changinge assignee then status reverts assignee

#2 Updated by Mischa The Evil over 4 years ago

  • Subject changed from Update issue: Changinge assignee then status reverts assignee to Update issue: Changing assignee then status reverts assignee

#3 Updated by Dietmar H over 4 years ago

Changing Tracker has the same effect. Looks like all operations triggering Ajax requests reset the assignee field.

#4 Updated by Dietmar H over 4 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

#5 Updated by Mischa The Evil over 4 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:
    1. Load Redmine default config
    2. Create new issue
    3. Assign the new issue an assignee (e.g. admin)
    4. Update/edit the issue (but don't submit the form)
      1. Change the value of the assignee field (<< me >> is sufficient for this use-case)
      2. Change the tracker or status field value (which - as expected - triggers an Ajax request)
  • 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)
  • Expected behavior:
    • After 4.2: the assignee field value is kept (still << me >>, see 4.1)

#6 Updated by @ go2null over 1 year 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

#7 Updated by Toshi MARUYAMA over 1 year ago

  • Related to Defect #13250: Status change refresh problem - cannot write fileds writeable in a given statatus added

#8 Updated by Dietmar H 7 months ago

Seems to be solved in 3.3.1 (don't know about older version).

Also available in: Atom PDF