createAttachmentOrder with meta

[gcandal]

Rationale

The creation of order attachments expects a file and a meta dictionary (see https://github.com/ripe-tech/ripe-core/blob/ba23882efa65acb165e924c6f836c6933646604f/src/ripe_core/controllers/api/order.py#L97).

However, the current SDK implementation of the endpoint doesn't support meta (see

ripe-sdk/src/js/api/order.js

Line 201 in c9e7b8a

dataM: {

).

Description

The implementation of the rationale above could probably be similar to:

    options = Object.assign(options, {
        url: url,
        method: "POST",
        dataM: {
            file: file,
            meta: JSON.stringify(meta)
        },
        auth: true
    });

But unless I'm missing something obvious, ripe-sdk doesn't support strings as values when using a multipart payload dataM (see

ripe-sdk/src/js/base/api.js

Line 1238 in c9e7b8a

ripe.Ripe.prototype._encodeMultipart = function(fields, mime = null, doseq = false) {

).

Trying to use them results in RangeError: offset is out of bounds because the string is not being encoded, resulting in this:

Related: https://github.com/ripe-tech/ripe-core/pull/4564

[joamag]

The suggested implementation does not work... if working with multipart you cannot pass dictionaries

[gcandal]

You mean dictionaries as values? I didn't, I used a string.

[joamag]

yes, but on the server-side you'll not be able to de-serialize them automatically, so no good to pass JSON.dumps

[joamag]

You need to use something like meta in the order POST... and still the multi-part issue with strings (in the SDK) would have to be fixed

[joamag]

ok maybe I'm wrong and now we support automatic JSON casting in Appier... Go ahead and try to see what's wrong with the multi-part encoding... But check the appier and yonius implementations as the multipart encoder should be aligned with both

[joamag]

@gcandal let's also create some unit tests to avoid regression for this mixed types multipart situation

[gcandal]

Requires hivesolutions/appier#47