- Jan 19, 2015
-
-
youring authored
closes #4762
-
Fabrice Henrion authored
closes #4768
-
Antony Lesuisse authored
- delete a forgotten print - allow pg_dump custom dumps to be larger than the available disk size, the previous commit allowed dumps to be larger than memory, this one remove this limitation. zip dumps are still limited to by the disk size.
-
Antony Lesuisse authored
- let the user choose between the pg_dump custom format or the zip format including the filestore - use file objects to allow dumps larger than memory - postgres subprocess invocation is now clean and thread-safe, we dont touch the local process environ anymore - add a manifest to the zip dump format with version information about odoo, postgres (pg_dump doesnt output it) and modules
-
- Jan 16, 2015
-
-
Richard Mathot authored
If a survey has "allow users to go back" option enabled, users can go back to previous pages and change their answers before submitting the whole survey. This commit fixes the very special case, when the user reaches the last page of the survey, then click on "Previous" button, then reopen the survey from the invitation URL (/survey/fill/<survey_id>/<token> without the /prev flag in the URL). This won't crash anymore. This commit fixes #2658 and #2680.
-
Richard Mathot authored
When user answers to multiple suggestion questions with a comment box, the comment box was prefilled with the ID's of the suggestion instead of user-entered data. This commit fixes #3149 and closes #3171.
-
Richard Mathot authored
-
Richard Mathot authored
Avoid creation of doublon survey_user_input entries when a user loads the landing page of a survey (/survey/start/... route). Due to some strange spec, jQuery.ajax() function called with "undefined" URL will do an extra call to the URL of the webpage where the script lies (http://api.jquery.com/jQuery.ajax/). Now, we check that URL is not "undefined" to avoid those calls. By the way, this problem probably happened in every page that had survey.js in its assets... (correct loading of survey.js is fixed in saas-6 at 4dd5dbb2, this fix is complementary.) This commit fixes #3032 and closes #3337 #3338 #3092.
-
Martin Trigaux authored
-
Denis Ledoux authored
-
Jeremy Kersten authored
[FIX] Purchase: replace SQL by ORM because ORM replace date=False by date is null automatically. Fix #4691
-
Xavier Morel authored
-
Xavier Morel authored
-
Ronak Baxi authored
-
Martin Trigaux authored
Payment info such as "You will be redirected to..." should be translatable. opw 619786
-
- Jan 15, 2015
-
-
Jeremy Kersten authored
When url_for was looking for a route which match, it was only looking for GET route. So routes which were restricted to be used only with a POST method, were never found. The result was that urls in website for route post (form in most cases) was never prefixed with the lang. So the request.lang was always the default lang from website... If you was creating a sale order (in ecommerce), the lang used in sale order was wrong and the description not in the current lang.
-
Antoine Huvelle authored
Adding a new context as, when creating a new journal from the pos.config, that journal should automatically be defined as a POS payment journal.
-
Josse Colpaert authored
[FIX] Correct resupply pull rules to have the correct warehouses to propagate / serve so it works with MTO rules also
-
Denis Ledoux authored
Before 8.0, the field journal_entry_id did not exist. For database coming from older release, like 7.0, this field is not filled in during the migration, because this is not possible. Set the needaction to depend only on the journal_entry_id will have as effect to have every bank statement line entered when the database was under 7.0 to match the domain, while the needaction is made to display the number of records that need an action. Besides, even in 8.0, this is possible that a line has not the journal_entry_id set, while not needing any actions (see 2bb38ca8)
-
Denis Ledoux authored
For bank statement line having an account_id, but no journal_entry_id, it is not possible to reconcile the line in the bank statement reconciliation tool, as a filter is applied to only reconcile lines having journal_entry_id AND account_id not set. As written in the help message of the account_id field: This technical field can be used at the statement line creation/import time in order to avoid the reconciliation process on it later on. The statement line will simply create a counterpart on this account Not allowing the reconciling should not prevent to close the statement in such a case. The button "close" was displayed only when all lines had journal_entry_id set.
-
Raphael Collet authored
This fixes an issue where the same function is used in several model classes: once the function is wrapped for the first class, it is erroneously considered as a wrapper for the second class, and is therefore not wrapped in other classes.
-
Martin Trigaux authored
Damn you commit -a
-
Martin Trigaux authored
Make the field description on a forum translatable and add it in the forum view. opw 619786
-
Moises Lopez authored
closes #3336 Implicit relative imports have been removed in Python 3, and developers should be encouraged to use explicitly relative imports to avoid confusion between local and global modules See https://www.python.org/dev/peps/pep-0328 for PEP on the subject with reasonings and justifications
-
Henri-Maxime Ducoulombier authored
fixes #4711
-
Xavier Morel authored
closes #3152
-
Denis Ledoux authored
-
Xavier Morel authored
-
Raphael Collet authored
This fixes #4681: prevent method copy() to write on the field.
-
Denis Ledoux authored
-
Xavier Morel authored
* document and warn that checks and fast_suite in tests sub-packages are deprecated and have no effect * avoid iterating all currently loaded modules when looking for test modules in a tests sub-package * replace use of __import__ by importlib Fixes #3152
-
Ravi Gohil authored
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
-
Sandy Carter authored
This means group category names can be translated in the default/installation database language. Closes #3921
-
Denis Ledoux authored
-
Antony Lesuisse authored
-
Xavier Morel authored
mostly to match apparent searches for it
-
- Jan 14, 2015
-
-
Martin Trigaux authored
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
-
Christophe Simonis authored
-
Simon Lejeune authored
-
Denis Ledoux authored
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
-