[Typo][6.1/Trunk] binary field in tree view messes with new objects

This bug is difficult to reproduce in the runbot as I'm not aware of binary fields appearing in tree view.

But we use binary fields in tree view. And we found that the code was probably never run even once as there are obvious typo in the code giving an direct wrong feedback.

The typo
------------

This typo was found in openerp 6.1 but is also in last 7.0.

Here is a proposed patch for the typo found in 6.1 in ``addons/web/static/src/js/formats.js``:

@@ -331,10 +349,10 @@ openerp.web.format_cell = function (row_data, column, options) {
                         row_data[column.filename].value, {type: 'char'}));
             }
         }
- return _.template('<a href="<%-href%>"><%-text%></a> (%<-size%>)', {
+ return _.template('<a href="<%-href%>"><%-text%></a> (<%-size%>)', {
             text: text,
             href: download_url,
            size: row_data[column.id].value

Notice the '<%-size%>'.

In 7.0, the same typo is found:

$ rgrep '%<-size%>' .
./addons/web/static/src/js/view_list.js: return _.template('<a href="<%-href%>"><%-text%></a> (%<-size%>)', {

The wrong size
--------------------

If you correct the obvious typo, the size displayed is the base64 content of the file !. (despite the field was called "size" in the javascript dictionnary, it is filled with the wrong value.)

This seem very related to this bug: https://bugs.launchpad.net/openerp-web/+bug/914267

The prevention of the creation of a new element
--------------------------------------------------------------------

Even when using '<%-size%>', correcting the size displays. The creation of a new element will fail. This probably only occur in form nested tree views displaying binary field.

The javascript code do not receive a real object id, and thus cannot create the url:

download_url = _.str.sprintf('/web/binary/saveas?session_id=%s&model=%s&field=%s&id=%d', openerp.connection.session_id, options.model, column.id, options.id);

as ``options.id`` is not a real integer id, but a string. Which will cast an exception as it can't be matched with "%d".

This leads to a javascript uncaught exception preventing the object from being created.

I didn't try to reproduce these bad behaviour on 7.0, but it seems that the code was only quickly moved around without ever being tested (the ugly template typo is a good marker to see that this code was never run in 6.1 when it was written, and in 7.0 when it was moved around.)

If more info is needed, or the report is unclear, please comment.