If the date_done field of the model stock.picking is already filled in
it means the user do wanted to have this date of reception date
instead of the moment when the user clicked the receive button.
opw-627219
When converting a datetime field to date, using the widget date,
the date time value was just cropped, removing the hours,
therefore ignoring the user time zone.
For instance, if the user was in UTC + 1, for a date time 02/02/2015 00:30:00,
applying the widget date on this datetime had as result 02/01/2015,
due to the fact the UTC value of the datetime field was 02/01/2015 23:30:00
fixes#4420
opw-621281
This was broken by mistake at rev. d6c6f31231
partially undoing the introduction of this feature at
rev. 49c0ed6467 (probably due to the
confusing name of that manifest option)
In cases where data is directly given to the saveas_ajax controller,
the filename was not correctly set, as no read method was performed.
(The read call is useless as the data is already avaiable in such a case)
In such cases, the filename must be given in advance
opw-626707
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.
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.
When converting a lead to an opportunity, and choosing the option "link to an existing customer", the resulting opp wasn't actually linked to the ccustomer.
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
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
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
Google api geolocation service returns a precise latitude and longitude, greater or equal than 5 digits
The precision is important as storing 2 digits instead of 5 can lead to an inaccuracy of allmost half a mile.
Catch only the error related to the access of the linked record.
Previous was hidding error to access the ir.config_parameter and eventual other
errors from the orm.
Uses SUPERUSER_ID to access instance URL (e.g. portal has no access to it).
Fixes#4234#4234
This is related to rev. db98434e85
rev. abe5c803a0 forgot some partial reconciliations when the date domain was other than BETWEEN (for instance, <= stop date or >= start date, alone, not between)
Besides, the rev. abe5c803a0 did not care about account move being posted or not.
rev. db98434e85 took several times the same partially reconciled moves lines
Another fix should probably be build for purchase price, but it isn't that easy, we need to know the partner to which the product has been purchased, as taxes are partner/country dependent.
Besides, included taxes in purchase prices happen less often.
When composing an email based on an email template, some parts of the template
(the result of name_get on fields) were not translated.
This was due to missing language in context when rendering the template.
Fixes#3708, opw 617309
When sending a message with the "Compose new message" button on the right of the user menu, in the top bar, if you tried to save the message as template, you had a traceback because model field of email.template is mandatory, but was set to True because there is no model in such a case.
As there is no any relevant model in such a place, and that the field is mandatory, mail.message is pretty convenient as the default value.
Potentialy, the timezone too.
On item action click (such as menus in More.. and Print..), the data in form view had the priority on user context (through the sidebar_eval_context)
Therefore, if a field "lang" was present in the form view (like in partner form), the web/action/load xmlrpc call was using the partner language instead of the user language.
Example of wrong use case before the fix:
- Set the user language in French, then go to a partner form of a partner with English set as language
- Click on any button of the partner form, such as the "Invoices" button, notice that the last item of the breadcrumb is in English, instead of Frenh (the user language)
- Click on any menu opening a wizard in the More.. dropdown menu, notice that the wizard title is in English instead of French
- Print any report from the Print dropdown menu, notice that the report file name is in English. If you print the same report for the same partner but from the list view, the report file name is in French.
The destruction of one2many fields is forced with the event change:effective_readonly
This revision add the forced destruction for cancel(discard) button as well
Otherwise, one2many fields are not properly destroyed when hitting the button "discard" (from save or discard).
This can be problematic for one2many editable list views (such as invoice lines) if you discard while having a mandatory field not filled in the invoice line: You can't recreate an invoice, the one2many editable list is messed up
Use case: Create an invoice, create a line, leave the description, required field, empty. Then, discard. Then, click on create.
opw-616946
Add invoicing related fields on anlytic account tree view for the invoicing group only
Otherwise, when a user not having the invoicing access rights displays the analytic account list, he gets an access right error.
opw-619485
When the list view is grouped, the page count should be hidden as irrelevant.
However if it's fully hidden, the limit can no longer be changed.
Instead of hidding the pager, this commit hides the arrows and replaces
the content by the current limit to allow to be changed.
The average price computation is now deduplicated and moved to
a separate function called in stock_move action_done.
This makes sure it is always called when a stock.move is
processed, even without going through the partial picking wizard.
Fixes#2991Closes#3949
OPW-615491
Reminder emails are generated based on the list of attendees.
The email_to field used to be a string with a list of emails separated by spaces
while the comma is the valid separator (RFC2822).
Fixes#3933#3784#2033
See issue #3964 for more detail. Main problem was caused by commit
f0e331e005. It set the key name+'__display' to false when reloading
a record for all field types, but it was only concerned with many2many.
Remove the intermediate rounding inside _compute_qty(), as it
is not necessary after rev. fa2f7b86 and has undesired side-effects.
An extra float_round() operation inside _compute_qty()
had been added at rev. 311c77bb to avoid a float representation
error in UoM factors that could bias the ceiling() operation
done as the last conversion step.
Example 1:
Dozen has a factor of 1/12, which was previously stored in the
database with a decimal accuracy of 12 significant decimal digits.
This meant the factor was exactly stored as 0.08333333333333.
When reading this back into a Python float, the precision was not
sufficient, and the UoM conversion of 1 Dozen to Units gave a
result of 12.00000000000047961...
After the final ceiling() operation to Unit's rounding, the
converted value ended up as 13.
This problem was initially solved using an extra rounding.
However at revision fa2f7b86 the decimal precision used to store
UoM factors was increased to preserve all significant digits.
This added the extra precision necessary to read the Dozen factor
back into an accurate float value of 1/12, and the conversion of
1 Dozen now gives 12.0 Units, even without the intermediate
rounding operation. (Works for other factor values too)
At the same time that extra rounding operation has undesired
side-effects, as it requires a fixed precision derived from
the rounding precisions of the UoMs. But there is no given precision
that would work in all cases for this intermediate value. It is
always possible to find a valid combination of UoM roundings
that breaks that intermediate step, e.g. by forcing integer
roundings.
Example 2:
Let Grams have a rounding precision set to 1 because no smaller
quantities are allowed, and Kilograms a rounding of 0.001 to allow
representing 1 Gram. (gram factor = 1000 and kilogram rounding = .001
by default)
If we try to convert 1234 Grams into Kilograms, the extra rounding
introduced in 311c77bb will cause a rounding of 1234.0/1000.0 at
the precision of Grams (1), which gives 1.0 as a result.
The net result of this conversion gives 1234.0 Gram = 1.0 Kilogram,
while the correct result (1.234 Kilogram) is perfectly compatible
with the UoM settings.
Similar errors could be triggered with various rounding settings, as
long as the intermediate rounding needs a finite precision.
Two extra tests have been added to cover Example 1 and Example 2.
--
Related to #2072, #1125, #1126, #2672Closes#2495, #2498
prodlot_id field may be required due to constraint `_check_tracking`.
When a stock.production.lot is deleted, the constraint on linked stock.move is
not checked. To avoid inconsistency, restrict the suppression.
To allow the modification of existing stock.move, remove the states attribute on
the field definition.
As removal of serial may impact the traceability, it makes sense on buisness
point of view to force the modification of previous stock.move, even if the
constraint would not have been violated.
The list of linked stock.move is present on the serial form view making
the operation easier.
Fixes#3560, lp:1176912
Fixes the issue #1216 (follow the link for more information). The issue
was caused by a hack in list view: the magical suffix __display is used
in render_cell to determine if a many2many field should be updated. This
commit simply makes sure that old many2many fields + __display keys are
cleared.
A better way would be to redesign/refactor the list view to avoid that
hack in the first place. But this would be a much more complex task.
if the bom is phantom and has no line, we attempt to find a new bom with the default product uom
This is possible that we find the same bom that the current one
In such a case, we must not explode, to avoid recursion.
If a company contact (a partner with a company set as parent) had invoices, and the company of this contact was duplicated, all the invoices lines were duplicated, on the original invoice moreover (new lines were added on existing invoices)
When the user was in timezone UTC + 1, and added a project.task.work which created an analytic entry line (timsheet activity), if the datetime was set to 11/25 00:00:00, the date on the analytic line was set to 11/24, because this was the truncated stored value(UTC Time), which was 11/24 23:00:00
Set a default value for factor when creating a new uom.
Could not create a new UoM with type reference (if creates a reference uom, no need to pass a factor).
Change the readonly filter to (type = bigger) to make the field writable for reference uom.
This is needed to force the reset of the factor when switching of type (onchange_type).
As the field was readonly, kept the old value for factor.
This rev. 7307227 ensured to not (re-)set the state 'confirmed' to exploded moves with a more advanced state (for instance, 'assigned')
Nevertheless, the location chaining is performed on the move confirmation, through the action_confirm method of the stock.move model. Besides, the resulting moves of the _action_explode method had the state 'confirmed' on creation, the 'confirmed' state wasn't set by the method 'action_confirm', meaning that the moves were confirmed without having the location chaining done. Allowing moves to go through the action_confirm method even if the state was 'confirmed' or further triggered the location chaining.
Preventing already confirmed moves to go through the action_confirm method prevented the location chaining, thus.
We now create the resulting moves with the 'draft' state, and then confirm them through the procurement workflow signal 'button_confirm'. Thus, the resulting moves are confirmed by going through the action_confirm method, writing the confirmed state and triggering the location chaining at the same time. We then write the 'assigned' state if necessary.
opw-617235
The delivery of a purchase order was not keeping the currency and cost price
from the purchase order for the reception. This was problematic for orders where
the invoice was generated from the picking (Invoicing Control: Based on incoming
shipments). The currency of the purchase order was kept while the cost was the
one in the company's currency.
It's better to keep the currency of the purchase order to make the invoice as
it's usually the one expected (and not convert everything to the currency of the
company). opw 615555
This rev. 06104ba553
Added the dirty flag on the o2m field when the editor of the editable list was enabled (meaning that the editable list has been altered)) because the dirty flag was not set correctly by the one2many during the edition, at the time.
It looks like this is now the case
Besides, as now, we valid all the editable list of the form, wether or not the editable list was altered, we must not set the o2m as dirty anymore.
First, name_search searches on default_code, then, if the limit is not reached, it searches on the product name
The results found from the default code search must be removed from the search domain when doing the search on the product name, to avoid having results already found by the search on the default_code
opw-618015
When a picking is confirmed, the generated account.move(.line) should take the
company, accounts, journals and period with the same company as the picking,
not the one of the current user.
This was problematic if a user in a company confirm a picking linked to
a purchase order done in another company.
For real time valuations, the generated accounting entries were mixing both
companies.
Fixes#3466
search bar does not suggest date field format based on user's locale and always shows based on mmddyy using Date.parse, opw:615276
Note: starting in 9.0, datejs has been replaced by momentjs, so this
problem should be solved in a better way.
date field on a project.task.work is not required while it is on the hr.analytic.timesheet (with default value).
Avoid error if fill a task work without date, fallback on context_today.
The field bom_id is required on a manufacturing order and deleting a mrp.bom would block the current mo.
Restrict the suppression for manufacturing order in progress.
Fixes#3417
Timesheet activities (hr.analytic.timesheet) are generated when a work activity (project.task.work) is logged on a task.
These are updated if the project of the task is modified.
This patch applies the same behaviour for tasks without project, the timesheet activities are generated once a project is set on the task.
To avoid redundency in the code, extract the computation in a distinct method.
Fixes#701, opw 609481
once widget extended with ReinitializeFieldMixin, the event binding with the binary file input and the on_file_change method can be done in initialize_content instead of start
This fix is related to d36c8b5c9b
The add attachment button should be displayed while being in edit mode, but not in view mode
As the widget depends on the form actual mode, the widget should be re-rendered each time the actual mode changes
This is the point of the ReinitializeFieldMixin class
The report includes all due payments, not only the one after the maturity date.
The maturity date is displayed in the report so no confusion is possible for payments below the maturity date.
Fixes#3064
To valid all editable list line, we iterate on the lines and set the editor form with the line value, using set_value.
The _inhibit_on_change_flag should be set to True to avoid triggering on changes events
opw-617395
When validating a SO containing a `make to stock` + `manufacture` product
(with bom + orderpoint), we have the following stock moves:
* Product move
* Manufacturing order
Selling 1 such product would yield 2 as incoming quantity, an
inconsistency that this commit solves by setting the location_id of the
product move to the MO's location_dest_id (in the same fashion that
the create_pickings method does in an mts/buy case)
opw-616229
This is related to rev. a218a9ed3f
The condition is good, but not in the right place: It should be done once all read_slice (all columns records) are fetched, not at each read_slice end
Some prices, as standard_price, being a property, are company dependent. Therefore, when browsing as superuser, force_company is mandatory to get the property of the user company
[FIX] account: Preserve analytic account on tax lines which are on same general account as invoice line
After careful analysis, I'm now convinced it is a good thing to preserve
the analytic account on taxes line which have the same general account
as the invoice line.
This is the best default case and will save time for users,
while leaving the flexibility to adapt the analytic account on
taxes manually.
[FIX] account: Error when manually adding analytic account in the generated tax lines on an invoice
fixes#374
fixes https://bugs.launchpad.net/ocb-addons/+bug/1084822
The fix considers invoice tax lines with different analytic account
are equivalent for the purpose of checking if the list of tax line
is complete.
Caveat, this changes the structure of keys in the dictionary
returned by account.invoice.tax's compute method, I suppose this
is ok for the master branch.
opw-617036:
In my current timesheet, if you add a a required field on the timesheet ids lines, and add data in the summary tab, it was possible to validate the timesheet lines while requried fields were missing.
When a line is not present in the partial delivery wizard, computation variables are initialized with generic values (zero quantity, zero price,...). Instead of setting the uom to False, keep the quantity of the move.
This makes a difference only when the quantity of the move is 0. That means that the move will be marked as complete and can be processed.
This avoids trying to update the stock.move with a uom at False. opw 616844
This is a workaround for an ORM limitation. A stored function field is
not updated when it should if the "source" field is also a stored function
field
In certain cases, before running an update unregistered models will try to
register hooks. Trying to wrap create and write on these will cause
AttributeError on model_obj which would be None
Signed-off-by: Sandy Carter <sandy.carter@savoirfairelinux.com>
Implements the UoS TODO items on stock.picking.do_partial() to fix#1432.
Add a new method _compute_uos_qty() on product.product to computes
product's invoicing quantity in UoS from quantity in UoM.
The created invoice will use the product_uos of the stock.move, meaning keeping
the quantity specified on the partial picking and the unit of measure of the
original stock.move (e.g. recieving 1 dozen from a 12 unit picking should either
get uos=dozen, uos_qty=1 or uos=unit, uos_qty=12, not a mix of both)
Fixes#1432, opw 611479
General totals were not computed at all, due to the condition "if not self.ids" which was always true as self.ids wasn't set.
Besides, a parameter allows to display only partner with balance greater than 0, which was completely ignored by the totals computation methods: The totals always included all partners, even those having balance equals to 0
When generating the report 'Timesheet Profit', got a warning "The domain term '('user_id', '=', [...])' should use the 'in' or 'not in' operator."
This warning is due to the use of the '=' operator to compare the field 'user_id' while the reports sends a list of ids.
Fallback to still accept a single id in case of customised reports.
Source and destination locations are required and not displayed in the form view.
Adding new items when recieving a picking can not be easily guessed as we can put different locations for each line, using default locations may not be the expected result.
Instead should modify the original picking or create new one.
Fixes#2074, opw 612768
At the end of the onchange call product_id_change, the uom may have changed (e.g. if product in different category).
To compute the quantity, we need to use the new uom and not the first one (that may be Unit, default value)
The computation of the price without pricelist should take care of the unit of measure.
e.g. if computing discount for objects in dozen (on a product with price in unit), returned unit price should be (price*12) where 12 is the factor to go from dozen to unit.
Otherwise the compared prices (with and without pricelist) would not use the same unit of measure and the comparaison would be inconsistent. (opw 599727)
The price_surcharge attribute must be computed based on the reference unit of measure (divided by the factor).
This is to make sure than 12 units and 1 dozen have the same price after pricelist computation (opw 599727).
Added test checking the correctness of pricelist computation based on unit of measures.
Add readonly attribute to avoid sending both factor and factor_inv value to the backend when saving.
This was possible if the user switched between uom_type to fill the two fields.
Remove the hardcoded precision of 12 on factor and factor_inv,
to use the complete natural precision of NUMERIC types,
preserving all significant digits.
e.g. a UoM with a factor_inv of 6.0 used to be computed as:
factor_inv: 6.0 -> factor: 0.166666666667 (1.0/6.0, rounded to 12 digits) -> factor_inv: 5.999999999988 (1.0/factor)
which could lead to errors such 12*0.166666666667 = 2.000000000004 instead of 2.0
Slightly changed the way the ORM handles float fields to allow setting `digits=0`
as a way to explicitly require a NUMERIC value but without enforcing/rounding
the values at the ORM level, i.e. a truly full-precision field.
NUMERIC type has unlimited precision but is less efficient so should not be
used as the default behaviour, which is why we keep float8 as an alternative.
Modified the view to display the product UOM factor with a 5 digits value by default.
This value is for usability purpose only, the field still accepts bigger precision, by
setting the `digits` option on the field in the form view.
This change is safe in a stable series, the `digits=0` alternative is
treated the same as the default `digits=None` everywhere in the framework,
except when creating the database field.
Add rounding_method parameter on float_round method to offer
HALF-UP (default, usual round) or UP (ceiling) rounding method.
Use the second method instead of math.ceil() for product
reservations.
For UP, the python math.ceil() method uses "torwards infinity"
rounding method while we want "away from zero".
Therefore we use the absolute value of normalized_value to make
sure than -1.8 is rounded to -2.0 and not -1.
Fixes#1125#2793
This is a cherry-pick of d4972ff which was reverted at 333852e due
to remaining issue with negative values.
Backport of 79bed94 (project user access to resource.calendar) and adding the access to resource.calendar.attendance.
It is needed to compute function fields such as day_open (present in form view of project.issue)
Fixes#3201
In the report pos order, average_price was set as a numeric(16,2), therefore, if the amount was too big, it led to a psql crash:
A field with precision 16, scale 2 must round to an absolute value less than 10^14.
And fallback of any type if there is none of type email
This fix allow the communication between two mail thread from two different Odoo servers having message creation subtypes, like project issue or crm lead
In edit mode, in a *2many with many2many_tags, when adding a new tag when none was set, discarding the form let the new tags displayed while it shouldn't (only a display issue, the tag wasn't added in database)
Fixes#2926
If an email contains several text/html parts inside a multipart email, the previous code was only keeping the last content part.
The Content-Type: multipart/mixed allows several independent part (RFC1341 7.2.2), so two html is technically valid.
With this patch, the two parts are concatenated. (opw 614755)
Modify append_content_to_html regex to make sure the regex keeps the content of the html instead of removing it.
e.g.: "123 <html> 456 </html> 789" used to be stripped to "123 789" while we expect "123 456 789"
Use group_production_lot for serial options, group_stock_packaging for packaging, use group_tracking_lot for pallet/parcel
Groups are removed completly from the view for stock.tracking as they render the view useless.
Always display weights on the product form
They really have nothing to do with the logistic units and we don't have another group to restrict them to.
Fixes#1443
When computing the price difference amount do not integrate the eventual discount and taxes included in the price.
Otherwise the total of the generated accounting enty would be higher than the total of the invoice. opw 611350
When no result is found on the function field 'invoice' (account.move.line), instead of returning {move_id: (False, '')}, return {move_id: False} (expected for m2o fields)
Fixes#2138, opw 613096
- The res_config.xml file was missing in the manifest (so couldn't check the use of FB and Google OAuth from the general settings)
- The default value for these oauth configuration were not set
The name_get of a product will use some information (e.g. default_code) based on the supplier.
The matching of the supplier should use the commercial_partner_id in case the supplier info are on the company and the partner_id in the context belongs to the company (e.g. creates quotation with a contact of the company).
Fixes#1219
If the salary compuation gives a salary of zero, skip the creation of the account.move.line (not good to have lines at 0).
Fixes lp:1298116, opw 605816
Denis Ledoux
David Monjoie
Christophe Simonis
Sylvain LE GAL
Olivier Dony
Goffin Simon
Sandy Carter
Ravi Gohil
Martin Trigaux
Akash Balar
Wolfgang Taferner
fka-odoo
Yannick Vaucher
Jérome Maes
Antony Lesuisse
Lionel Sausin (Numérigraphe)
jbeficent
Gaurav Panchal
Somesh Khare
Christophe Combelles
Martin Trigaux
Ravi Gohil
Cedric Snauwaert
Benoit Guillot
Julien Legros
vrenaville
Eddy Ernesto del Valle Pino
Géry Debongnie
Loïc Bellier
Mohammad Alhashash
Pierre Verkest
Danimar Ribeiro
Frederic van der Essen
Samus CTO
Rifakat Haradwala
Frédéric Van der Essen
Dhs-odoo
Manuel Vázquez Acosta
Stéphane Bidoul
Sheth Sunny
Thibault Delavallée
Paramjit Singh Sahota
Jeremy Kersten
Antonio Esposito
Martin Trigaux
rmu-odoo
dhr-odoo
Simon Lejeune
Ferdinand Gassauer
Laetitia Gangloff
Young Joy
dhr-odoo
Humberto Arocha