The _auto_init method was overriden without keeping the return value of
the super on some models.
This break the new stored computed fields computation at field creation.
Closes#11985
opw-677232
In commit 44f2c8d54 we unified the return value of the function to int,
but it seems the returned size could be None which is not a valid input
of the int() built-in function.
To distinguish two ir.attachment 'File Content', we base it on the file
size (this I imagine is for efficiency).
This is done by setting bin_size in the context. Doing this, the
returned db_datas field will be the file size of the converted to base64
content (if no filestore).
But this size is returned in string format, so "get_nice_size" (in
openerp/osv/fields.py) which gets this size calculates the length of the
string. e.g: if the size is '2142' get_nice_size will return 4.
This fix solves this by converting the string to an integer, thus
unifying it with the filestore case (where we use os.path.getsize which
return an integer).
Also, the field presenting the issue (FieldBinaryFile) has been changed
so it is always updated even if the size is the same (as it was already
done by 3632949 for FieldBinaryImage widget).
closes#7223
opw-643071
When importing a CSV file with an "id" column containing
external IDs (XML IDs), the system automatically creates
or updates the corresponding ir.model.data entries.
This would fail for regular users who do not have
create/write access on this internal model.
The ir.ui.view.graph_get() method depended on the natural
semi-random order of Python dict keys in the _columns dict.
When the number and/or names of the _columns happened to
yield the o2m field of the "incoming transitions" *before*
the "outgoing transitions" of the "Node model"
(e.g. workflow activity), it would swap the incoming and
outgoing transitions fields around, causing a crash later
in the `tools.graph.process` method (currently an infinite
loop in the `tree_order()` method of tools.graph.py).
Closes#3614
Fixes https://bugs.launchpad.net/openobject-server/+bug/1316948
opw-633765
When updating translations, the source (`src`) is irrelevant for
`field` and `help` translations. Theses translation types are only
matched through their `name`.
fails due to ir.config_parameter permission
At rev. 80017b04c2
ir.config_parameter model has been restricted to employees
Getting parameter from this model should therefore
be done as SUPERUSER_ID where the uid could
be a user which is not an employee.
Closes#5280
This rev. is related to eb9113c04d
if a model or a resource id is not defined on an attachment
restrict access to employees only if the creator
of this attachment is not the current user.
So non-employees can access their attachments without
models/resource id, which includes attachment of
discussions threads.
Fixes#4309Closes#4310
It's always dangerous because (cascade-)deleting workitems
has a great chance of killing the workflow instances they
belong to, putting the records in the workflow limbo
permanently. (They will appear stuck as they don't have
enough workitems anymore)
In addition, in some rare cases a subflow activity is
converted into a regular activity during an update, and
nullifying the `subflow_id` column is all there is to
fixing the corresponding workitems. It will simply take
them out of their subflow, and back into the main flow.
This is the case for the modification of the purchase.order
workflow in Odoo 8 (saas-5), for the picking subflow.
When the ORM is cleaning up related attachments upon record deletion, the
search() method hides the attachment of the record that is being deleted.
If the same file is used exactly once in another attachment, the reference
count will be 1 and the file will be deleted.
Acting as a mailing-list-like distribution system, the system used
to set the enveloper sender (aka bounce address) to the From header
of the message, effectively pretending to be the original sender.
In some cases the domain of the From header explicitly forbids
sending emails from external systems (e.g. with a hardfail SPF
record), so this could cause the email to be rejected by some
spam filters, depending on their policies.
The system will now use a local bounce address in the form:
mail-catchall-alias@mail-catchall-domain
or, if no catchall is configured:
postmaster-odoo@mail-catchall-domain
(as soon there is a mail.catchall.domain configured)
It will only fallback to using the From header when no
catchall domain is configured.
Fixes issue #3347.
Closes#3393.
Revert "[FIX] ir_translation: remove control characters from translations"
This reverts commit 6d4e1cc73e.
This was intended to clean malformed translations but it introduced the side
effect of removing all '\n' in translations.
Fixes#4092, opw 619175
Rev f2cf6ced1 modified RFC2822 parsing in order to better support
unicode characters inside the Name part of an address header.
However the patch broke handling of multiple addresses (comma
separated) - silently discarding all recipients except the
first one, as soon as any non-ASCII character was present.
This patch restores the functionality while preserving the
fix from f2cf6ced1, and simplifies the code using email.utils
utility functions.
Fixes (again) lp:1272610, OPW 607683
When sending an email, both formats 'Name <email>' or '"Name" <email>' can be used for fields 'From', 'To' and others. If the name contains unicode characters, a regex only matching '"Name" <email>' was used to encode the name with RFC2047. That meant that the name was not encoded and eventually dropped, using only the email part.
Instead of using a limited regex, use the parseaddr method from email library.
Fixes lp:1272610, opw 607683
When a new ir.model.field is created, add the new field in the fields_by_model (cache of custom fields). This is required as the __init__ method would not retrieve the new field if fields_by_model is already set.
Otherwise, the _columns would not contain the new fields and we could not access it without restarting the server (e.g. the installation of a module adds ir.model.fields and use it in the a view.
Comparing an id and a browse record will always fail so the exception would have always been raised when changing a model (e.g. updating a module with custom fields).
When you set the date of a cron the July 1st at midnight, if the user
time zone has a positive offset, then the converted UTC date is the
June 30th and adding 1 month will end up on July 30th translating to
July 31th instead of September 1st.
To solve this issue we use the super user time zone for the date
calculation.
An ir.value without condition should not match when searching with a condition.
When a field with change_default on it is modified, the method get_defaults is called with the new value. This means that manually modifying a field with this trigger would put back the default value (opw 611193).
When searching for default values, if we set a condition (e.g. 'type=out_invoice'), fetch also the default values without any condition set. Thanks to the order by clause, the one with a condition have an higher priority than the one without and will not affect existing result.
This fixes default journal/currency on an invoice where the journal is retrieved in the onchange_company_id method (domain is forced). Without this patch only ir.values with a domain set will match, opw 610645
orm: do not try to create ir.model.relation for custom m2m as self._module is either empty (for custom models), either the one of the last inheriting module (which is wrong). The field should be removed manually and should not be impacted by the uninstallation of modules. The removal of the relation table can be done when removing manually the custom field (see rev 6af3193).
ir.model: when removing a model, drop the table with the CASCADE instruction. This will remove left constraints from remaining m2m tables.
This means that dropping a table (either manually removing a custom model or uninstalling a module) will not drop the relation table for a custom m2m field. This is not ideal but better than the previous behaviour (which was to fail the DROP TABLE instruction and keep the table with a few columns and unconsistent data).
When droping a column, remove also the relation table in case of custom m2m field.
The relation table needs to be dropped otherwise an unremovable constraint to the targetted table is kept (and anyway is not needed anymore).
When uninstalling a module, remove the ir.model.constraint after removing the non-model records and before fields and model definition.
Without this fix, some constraint would be removed too early allowing to have broken relations and data left from removed module.
The value_unpickled given by xml data is usualy already evaluated but when it is given by the web client, a str is recieved by the method (as the field is a text field). In the later case, we need to evaluate the field before storing to be correctly evaluated as a default value.
bzr revid: mat@openerp.com-20140509130412-ki211x7qdccdnv5w
Sylvain GARANCHER
Olivier Dony
Nicolas Lempereur
Thomas Rehn
Christophe Simonis
Christophe Combelles
Denis Ledoux
Goffin Simon
Nicolas Martinelli
Stefan Rijnhart
Holger Brunn
Manuel Vázquez Acosta
Martin Trigaux
Martin Trigaux
Samus CTO
Laurent Mignon
Ravi Gohil (OpenERP)
Denis Ledoux
Mohammed Shekha (OpenERP)
Christophe Simonis