Project

General

Profile

Actions

Defect #6403

closed

Updating an issue with custom fields fails

Added by Stéphane Dubois over 13 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Normal
Category:
REST API
Target version:
Start date:
2010-09-15
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed
Affected version:

Description

If I run the following code

require 'rubygems'
require 'active_resource'

# Issue model on the client side
class Issue < ActiveResource::Base
  self.site = 'http://redmine.server/'
  self.user = 'foo'
  self.password = 'bar'
end

# Updating an issue
issue = Issue.find(1)
issue.subject = 'REST API'
issue.save

it fails on issue.save with the following error

C:/Ruby187/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/array/conversions.rb:163:in `to_xml': Not all elements respond to to_xml (RuntimeError)

I suspect it has something to do with custom fields because if I do

# Updating an issue
issue = Issue.find(1)
issue.subject = 'REST API'
issue.custom_fields = nil
issue.save

it works !


Related issues

Related to Redmine - Defect #7377: Updating an Issue with custom fields set fails in V.1.1.0Closed2011-01-19

Actions
Actions #1

Updated by Ward V over 13 years ago

I can confirm this - I'm seeing the same thing. It's the custom_fields that cause this.

Actions #2

Updated by Stéphane Dubois over 13 years ago

Something strange:
to create an issue with a custom field we do

issue = Issue.new(
  :subject => 'REST API',
  :assigned_to_id => 1,
  :project_id => 1,
  :custom_field_values => {'2' => 'Fixed'}
)
issue.save

but when I retrieve an issue with REST API, :custom_field_values is not an entry of the attributes hash. Instead, I have a :custom_fields entry containing a custom_field entry which is an array containing all custom fields values.
If a try to update one of those values like that

issue = Issue.find(1)
issue.custom_fields.custom_field[0] = dummy_value
issue.save

I get the same error
C:/Ruby187/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/array/conversions.rb:163:in `to_xml': Not all elements respond to to_xml (RuntimeError)

So, I can't find a way to update a custom field.

Actions #3

Updated by Stéphane Dubois over 13 years ago

In fact, it's possible to update a custom fields with the same hash than for creation, but you must also nilify custom_fields

issue = Issue.find(1)
issue.custom_field_values = {'1' => 'dummy'}
issue.custom_fields = nil
issue.save

Actions #4

Updated by Eric Davis over 13 years ago

  • Assignee set to Eric Davis
Actions #5

Updated by Eric Davis over 13 years ago

  • Assignee deleted (Eric Davis)

I am stepping down from working on Redmine. If someone else is interesting in working on this issue, feel free to reassign it to them.

Eric Davis

Actions #6

Updated by Jean-Philippe Lang over 13 years ago

Stéphane Dubois wrote:

In fact, it's possible to update a custom fields with the same hash than for creation, but you must also nilify custom_fields
[...]

I don't know which version you're using but I can't reproduce this problem with current trunk. The following works:

issue = Issue.find(1)
issue.custom_field_values = {'1' => 'dummy'}
issue.save
Actions #7

Updated by Jean-Philippe Lang over 13 years ago

  • Assignee set to Jean-Philippe Lang
  • Target version set to 1.0.5
  • Affected version (unused) set to 1.0.4
  • Affected version set to 1.0.4

Problem found. The fix requires a slight change in the custom fields part of the API.

Actions #8

Updated by Jean-Philippe Lang over 13 years ago

  • Status changed from New to Resolved
  • Resolution set to Fixed

Problem is fixed in r4480, r4481. You can now the custom_fields array received in the API response to update custom_fields.

issue = Issue.find(6467)
issue.custom_fields.first.name  # => "Affected version" 
issue.custom_fields.first.value = '1.0.3'
issue.save

Actions #9

Updated by Jean-Philippe Lang over 13 years ago

  • Status changed from Resolved to Closed
  • Target version changed from 1.0.5 to 1.1.0

It will have to wait 1.1.0 because it relies on changes done in trunk only.

Actions

Also available in: Atom PDF