Wrong xml when LineItem has Tracking Categories (v 0.4.0) about xeroizer

[ben-biddington]

Hi Oxana,

I am looking at this right now on my fork.

[ben-biddington]

If you update TrackingCategoryChildModel to use TrackingCategories as its xml_root_name, then this error no longer occurs, but the tracking categories are ignored.

This is due to the serialization defect as mentioned above. Xeroizer sends xml that looks like this (note the duplicate TrackingCategories nodes):

<ExampleNodes>
    <ExampleNode>
        <TrackingCategories>
            <TrackingCategories>
                <TrackingCategory>
                    <Name>State</Name>
                    <Option>WA</Option>
                </TrackingCategory>
            </TrackingCategories>
        </TrackingCategories>
    </ExampleNode>
</ExampleNodes>

[ben-biddington]

@waynerobinson, this commit and the one prior describe the defect.

Can you verify?

[waynerobinson]

Hi Ben

Yup, will have a look at this today/tomorrow.

Wayne

On Tuesday, 21 February 2012 at 9:30 AM, Ben Biddington wrote:

@waynerobinson, these two commits show the defect.

Can you verify?

---

Reply to this email directly or view it on GitHub:
#30 (comment)

[ben-biddington]

Actually I am wrong about the name of the node -- Tracking is perfectly acceptable. It is just the duplication that appears to cause the PostDataInvalidException error.

[UPDATED]
Yep: totally wrong. The TrackingCategories node is only used by the TrackingCategories endpoint. The Tracking node is used whenever tracking is embedded within another resource.

[waynerobinson]

That's what I thought to. I'm confused as to why this duplication is occurring so I need to do some testing.

On Tuesday, 21 February 2012 at 9:45 AM, Ben Biddington wrote:

Actually I am wrong about the name of the node -- Tracking is perfectly acceptable. It is just the duplication that appears to cause the PostDataInvalidException error.

---

Reply to this email directly or view it on GitHub:
#30 (comment)

[ben-biddington]

here's a start

[ben-biddington]

Any clues?

[waynerobinson]

Sorry, still haven't had a chance to look at this and will be away
this weekend… on a BOAT.

On 24/02/2012, at 8:55 AM, Ben Biddington
[email protected]
wrote:

Any clues?

---

Reply to this email directly or view it on GitHub:
#30 (comment)

[ben-biddington]

Hey @waynerobinson, any progress?

[waynerobinson]

I've been working on a few Xeroizer-related things in the past few days and
I'll get to this specific issue soon.

Cheers

Wayne

On Thursday, April 12, 2012, Ben Biddington wrote:

Hey @waynerobinson, any progress?

---

Reply to this email directly or view it on GitHub:
#30 (comment)

[waynerobinson]

Sorry it took so long, but this has now been resolved in the lastest API release.

Cheers

Wayne

[ben-biddington]

Nice one, thanks.

Although I am getting two unit test failures from d53af49:

Error: test: JournalLine should journal_line tracking specified correctly. (JournalLineTest)
NoMethodError: undefined method `add_tracking_category' for nil:NilClass

Error: test: LineItem should line_item tracking specified correctly. (LineItemTest)
NoMethodError: undefined method `add_tracking' for nil:NilClass

Any tips?

[waynerobinson]

Not sure, I don't get these errors when I run the tests:

bundle exec rake test:unit

Is your bundle up-to-date?

[ben-biddington]

Yep, also just tried bundle update. Do you have this is in CI anywhere?

[waynerobinson]

CI? Continuous Integration?

I don't have this library in a continuous integration test suite anywhere.

This tests fine on ruby 1.8.7, but I've found an error with these test cases on 1.9.2. Not sure what is causing them but will investigate.

[ben-biddington]

Yep, I get the same behavior.

[waynerobinson]

There was a ruby 1.9 inconsistency issue with code in the following format:

record = nil
records.each { |record| record = blah }
return record

In 1.8, the record value inside the block would be operating on the version of record outside the block, in 1.9, these variables are scoped locally to the block.

I have fixed the code where that was important, and I believe it is the only section that required that 1.8 feature.

[ben-biddington]

Cheers, @waynerobinson