This reverts commit d970cc40f8.
point_of_sale does not depends on share. This domain can therefore not be applied.
It works for new databases as the module share is auto installed.
But as soon as the module share is uninstalled, this domain will lead to a crash
There is no way to "solve" this issue, other than by a view customization
if the issue is critical for the customer.
I did not pay enough attention when I reviewed the PR.
From reportlab 3.0, empty plaintext paragraphs do not lead to a break line anymore.
Before release 3.0, paragraphs having tags but no plaintext leaded to a break line.
This patch aims to recover the behavior of reportlab releases < 3.0, as
<para><font color="white"> </font></para> is used in allmost all rml reports
The current patch is not considered as clean, but we did not find any better solution.
If someone find a parameter to pass to reportlab in order to bring back the old behavior of reportlab
he is welcome to provide the better patch.
Besides, in reportlab 3.0, splitlongwords has been introduced as parameter,
to allow to break long words. The default value is True.
This parameter seems to break the columns headers
(it splits the text within the column header)
We therefore take the choice to not activate it, as it was not present anyway in reportlab < 3.0
To test the good behavior of this patch:
While having reportlab < 3.0 (2.5 for instance), print a draft invoice
Then, upgrade to reportlab > 3.0 (3.1.8 for instance), print the same draft invoice.
The generated pdf must be (allmost) identical, in particular concerning spaces.
Specifically, the space between the partner address and his phone.
[IMP] base: safer locking at user login
When a users connects, a lock is taken on the res_user table to modify the last login date. If another running transaction uses a foreign key to res.users (e.g. write_uid column), postgres may detect the update as a concurrent update and rollback the transaction.
In pg 9.3, the lock_strength parameter 'NO KEY' allows a weaker lock which is less likely to break another transaction.
Fixes#552
RPM packages did not pass the tests because the centos prompt changed
and thus did not match the regexp anymore. We now explicitely specify
the prompt in our Dockerfiles to prevent such issues.
In order to hide fields method_number and method_period to hide them according to the asset, fields_view_get method was overriden.
An issue was present: if a search view on model account.asset.asset was added, and did not contain these method_* fields, this overriden fields_view_get was applied, and tried to hide method_* fields, while they were not present in the search view, which leaded to a crash.
I could have solved this the easy way, to not apply the invisbility if the fields were not present in the view, or if the view was something else than form, but I prefered to solve this the cleanest way.
As entering a wrong value in the grouping field of res.lang,
for instance '[,]', leads to an unavailability of the web interface,
We add a constraint to prevent entering wrong values.
The first term of a po file is a comment for translator e.g.:
msgid ""
msgstr ""
"Project-Id-Version: openobject-addons\n"
...
This comment is ignored if there is no source and it is the first term of the po
file. The first flage was disabled too late and if the following terms also
started with an empty source (for too long terms), they were skipped as well.
Disable the flag as soon as the condition is evaluated to make sure no
additional terms are ignored. opw 619786
Remove installation of v8 requirements in package.dfdebian as this
is unnecessary for v7. This fixes a bug occuring during the installation
of openerp (precisely when installing reportlab dependencies), because
reportlab now requires a more recent version of pillow than 2.5.1.
Also use pip instead of /usr/local/bin/pip in test_tgz (package.py)
as pip script isn't installed there anymore.
Upstream traceability on produced goods (serial number on finished product) was
broken due to wrong values in cache for production.move_lines2 after production.
Refresh the value of production after each action_consume to make such the state
of the cache is correct. opw 609450
Similar fix for manufactruing order not going in done state in some specific
configrations (e.g. some components being phantom BOM).
Again due to wrong cache state after consumption. opw 610515
Fixes#1296
The tracking reference and other delivery references are not relevant to
duplicated pickings. Overwrite copy to remove carrier_tracking_ref, volume and
number_of_packages.
Add fallback on stock.picking.in and out to use copy method of stock.picking.
For partial delivery, the duplicated picking is the delivered order and
the existing picking is the backorder of the delivery (why so much hate?).
This means we have to switch the delivery info between the backorder and
the delivered picking.
Combo opw 615593 and 618802
The method test_if_product, used in the workflow to test that the mrp production is for a product (!= service), used to call the method _action_compute_lines in order to compute the production lines and determine from them the production type.
The thing is, the method _action_compute_lines, despite the fact it returns the lines of the production, actually creates the lines. So, just to test if the production was of product type, the productin lines were created, in database.
This rev. introduces a _prepare_lines method, which returns the computed production lines, without actually creating them in database, so the test_if_product method can test if the production is of product type without creating the production lines.
Therefore, production lines are now computed and created during the action_compute method, instead of computing them when the production was tested to get the production type.
Computing the lines before the action_compute has as side effect to not set the scheduled date of the work orders in module mrp_operations, at MO confirmation (as, on confirmation, the action_compute method is called only for productions for which the lines are not yet computed, and mrp_operations overide action_compute to set the scheduled date)
opw-620189
POS users should not be able to create nor modify payment methods (account.journal)
POS users should not be able to create nor modify point of sales (pos.config)
At first opened session, if no payment methods was set, this is possible that the pos user should temporary have accesses granted to mark a payment method as pos payment method. This is done by the openerp.SUPERUSER_ID added by this rev.
opw-625489
Use `tools.ustr` for error conversion to prevent `UnicodeDecodeError` when
converting errors which can be unicode in depending on data.
Example:
```python
from openerp.osv.orm import convert_pgerror_23505
from psycopg2 import IntegrityError
e = IntegrityError(
'duplicate key value violates unique constraint '
'"hr_job_name_company_uniq"\nDETAIL: '
'Key (name, company_id)=(Directrice comptabilit\xc3\xa9, 1) '
'already exists.\n'
)
convert_pgerror_23505(None, [], None, e)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 129: ordinal not in range(128)
```
This rev. reverts 91911159f5
The above rev. was a good idea, except that internal_set_value expects the raw value, while the records attributes can be tuples(for instance, many2one are tuple(id, name) or list of command(one2many, many2many).
set_value must be use here, as all fields (js) override set_value in order to handle their value repr (for instance, many2one fields handle the tuple (id,name).
Besides, avoiding the re-render provides a huge performance improvment, as rerendering fields can lead to xmlrpc calls (for instance, re-rendering a many2one field implies calling the name_get method)
opw-620111
opw-622108
The previous matching rules were too fuzzy and allowed random
prefix-match or tail-match of other user's emails.
For example when looking up a partner matching 'foo@bar.com'
the system would sometimes find 'dom.foo@bar.com' instead,
or 'foo@bar.com.tw'.
Fixed by only allowing direct case-insensitive email match
of an addr-spec, or substring match of the addr-spec enclosed
in angle brackets, within a name-addr pair.
See also RFC5322, section 3.4
Also adapted related message_find_partner_from_emails() method
to factor out the partner email resolution mechanism to avoid
the same problem.
Adds corresponding regression test.
If an employee in UTC + 1 (Europe/Brussels) entered an attendance from January 2 00:00 to Januay 2 23:59, the summary by day table displayed two different lines, for two different days:
- 1 hour on January 1 from 23:00 to 23:59
- 22:59 hours on January 2 from 00:00 to 22:59
Which is obviously wrong, the employee, in its own time zone, worked on January 2 only.
When adding several lines in an editable list (adding 7 lines to an invoice for instance), then clicking on the first row direcly after having filled the last line, the value of the cell sometimes had the value of the last line. Just a display bug, but still.
Using internal_set_value avoid the re-rendering of the cell, and solve the above issue
opw-620111
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
For models using a datetime field as name (hr.attendance for instance), the user timezone wasn't applied in the display name.
Therefore, in the breadcrumb, the datetime was different than in the form if the user had another timezone than UTC.
If the date format language was changed to invert month & day values (so, changed to the classic european format instead of the american format)
Then, when entering manually a datetime without the time (so just '01/02/2014' instead of '01/02/2014 00:00:00', the day and month were inverted (the datetime was set to 02/01/2014 instead of 01/02/2014) because the datetime entered did not exactly match the date + time pattern.
We therefore added a fallback case, to test to parse the value with the date pattern alone (without the time)
The gantt view does not have enough data to properly display a project's length
based on only the planned hours.
It also makes it impossible to change the project's length using drag & drop.
It's safer to simply display the start and end dates recorded in the project
Fixes#2632
Partners totals were not correct if the partner paid partially an invoice in advance
For an invoice of 20.000 in the future, with a payment made in advance of 5000
The column not due must contains 20.000, as the amount is not yet due
One of the column 1-30, 30-60, ... (accordingly on when the payment was made). must contains -5000
The total should be 15.000
When creating a return picking, the default invoice state is 'To Be Invoiced' if
returned picking was invoiced. However if the invoice of the picking has not
been generated yet (state '2binvoiced'), the return should also be invoiced.
Fixes#4002
Denis Ledoux
Martin Trigaux
Goffin Simon
Aaron Bohy
Sandy Carter
Martin Trigaux
Ravi Gohil
Akash Balar
Xavier Morel
xmo-odoo
Sandy
Wolfgang Taferner
Olivier Dony
fka-odoo
Yannick Vaucher
Jérome Maes
Maxime Chambreuil
David Monjoie
Fabien Pinckaers
Antony Lesuisse
Cedric Le Brouster
Simon Lejeune
Lionel Sausin (Numérigraphe)
jbeficent
Gaurav Panchal