Redmine

Could you provide a small code snippet that illustrates the problem?

Unfortunately the following code don't produce the error above. I run this code in the first view of my application ("index").

a_issue = Issue.new
a_issue.subject ="MyTestIssue"
a_issue.description="MyDescription"
a_issue.author = User.current
a_issue.project = Project.find_by_id(1)
a_issue.tracker = Tracker.find_by_id(1)
debugger # a_issue.assigned_to nil
puts "now save the issue"
a_issue.save
puts "the issue was saved" # a_issue.assigned_to nil like before
debugger

Now I have all my code portions with an "any_issue.save" replaced with the call of following function:

  #TODO: new_issue.save force "assigned_to" to a user (only while first save), how and why?
  #wg. redmine Defect #11348
  def issue_save_with_assignee_restore(a_issue)
    # wegen bug, dass assigned_to zwangsweise bei issue.save angelegt wird
    tmp_a_to = a_issue.assigned_to
    tmp_a_to_id = a_issue.assigned_to_id

    result = a_issue.save

    if a_issue.assigned_to != tmp_a_to
      debugger
      if tmp_a_to != nil
        puts "assignee canged, old: " + tmp_a_to + ", new: " + a_issue.assigned_to
      else
        puts "assignee canged, old: nil, new: " + a_issue.assigned_to.login
      end
      debugger
    end

    a_issue.assigned_to = tmp_a_to
    return result
  end

And now sometimes the debugger stops the application because "a_issue.assigned_to != tmp_a_to". But it is always the same user (not the current) see below - password and salt deleted and e-mail changed for this report. I have changed the user status to 3 (user locked) but the problem even exists.

<User id: 3, login: "tko", hashed_password: "...", firstname: "Thomas", lastname: "Kohler", mail: "t@de", admin: true, status: 3, last_login_on: "2012-07-02 21:07:04", language: "de", auth_source_id: nil, created_on: "2011-04-07 22:14:29", updated_on: "2012-07-11 21:26:30", type: "User", identity_url: nil, mail_notification: "only_my_events", salt: "...">

Now I have deleted this "bad user" with id=3 ... and the problem is gone. I have added a new user with exactly the same attributes like the old "bad user" and the problem is not come back.