Conversation
Author
|
Pushed Chemical products are managed in different units of measure (in the customer's data: 198 in volume units, 47 in weight units and 204 in "Units"), so the component amount column was summing mL, μL and pieces into a single meaningless total. This commit makes the report unit-aware without introducing any conversion:
Known limitation: Odoo renders group subtotals for numeric fields regardless of the |
Author
|
Pushed Formatting only, no behaviour change: ran pre-commit over the whole module, which reformatted |
On-hand amounts alone cannot answer how much of a substance was handled over a period, which is how the reporting obligations are expressed. Validating a stock move of a chemical product now records the amount of each contained substance, one record per substance, signed positive for a receipt into an internal location and negative for a delivery out of one. A move between two internal locations is recorded as an internal transfer and left out of the totals, and a move that never touches an internal location is not recorded at all, since nothing is handled on site. The amounts are snapshots, precomputed when the record is created, so that revising the composition of a product does not rewrite what was handled in the past. Inventory managers can correct a record from its form view, and rebuild the records of a move to cover the moves validated before the module was installed, or a composition that was registered wrongly. Component amounts are also converted into the chemical aggregation unit of the product's unit of measure category, so that amounts of the same substance held in products measured in different units add up into a single total.
The names described where the data came from rather than what it is, which made the two reports hard to tell apart, and the product lines did not carry the prefix of the model they hang off: product.chemical.location.amount -> product.chemical.stock product.chemical.move.amount -> product.chemical.consumption product.chemical.law.line -> product.template.chemical.law.line product.chemical.substance.line -> product.template.chemical.substance.line product.chemical.major.category -> product.chemical.law.major.category product.chemical.minor.category -> product.chemical.law.minor.category The migration scripts go with them: 18.0.1.0.0 is what is released on 18.0 and it carries the is_chemical flag alone, so none of the renamed models ever reached a database that will run this upgrade. Split the access rights along the way. The masters are reference data every user reads and an inventory manager maintains, and the product lines belong to a product manager, so read and write no longer come together for everyone. Drop the mrp dependency, which nothing used, along with the law product count and the chemical amount list on the location form, which no view showed any more.
…ated One2many defaults to copy=False, while is_chemical and track_chemical_consumption are booleans and are copied regardless. Duplicating a chemical product therefore gave a product that still presented itself as a tracked chemical but held no substance at all: absent from the on hand report, recording no consumption, and with nothing on the form to say why. Cover product.chemical.stock along the way. Its whole query lives in one _table_query string that no reviewer re-reads, so each test pins one clause of it: the conversion into the aggregation unit, the fallback for a category that has none, the internal location filter, and the grouping that sums a product's variants into a single row.
The module carried demo data at one point and does not any more, but ja.po was exported from a database that still held those records. 71 of its 163 entries -- laws, categories, substances and products such as "Fire Service Act" or "2-Propanol (Reagent Grade)" -- referenced xmlids that the module no longer defines. None of the 71 had a second, live occurrence, so the entries go whole rather than losing a reference line. What remains points only at fields, views, models, constraints, menus and actions that views/ still defines, and every one of the 92 messages left is translated.
The description named an "Update Chemical Amounts" action that exists under neither of its two labels: the stock move list and form offer "Update Chemical Consumption", and the Chemical Consumption list offers "Update from Stock Move". Name both where they appear instead. The CAS master became product.chemical.substance and its menu became "Chemical Substances", so the wording around it follows. Drop the "(PDF)" from the risk assessment sheet as well. risk_assessment_file is a plain binary field that accepts any file type, so the parenthesis promised a restriction the module does not enforce. Regenerate README.rst and static/description/index.html.
…e master A content rate belongs to the product that holds the substance, not to the substance itself: the same CAS number sits at a different rate in every product it appears in. The field only ever seeded a newly added product line through an onchange, and a master column that is right for one product and wrong for the next misleads more than it helps. The field goes with everything that hung off it: the CHECK constraint that guarded its range, the two substance views that showed it, the onchange that read it, and the three translation references. The rate is entered on the product line, which is where it is stored anyway.
unique(move_id, substance_id) already builds a btree whose leading column is move_id, so a lookup by move -- which is what reading the chemical consumption of a move does -- uses it. And company_id is neither filtered nor sorted on today; the index can come back with the multi-company record rule that would give it something to do. Removing index=True does not drop an index that already exists: the registry keeps it and logs "Keep unexpected index". Only a database created from here on will be without them. The comment on product.template.write() goes as well. Clearing track_chemical_consumption along with is_chemical reads clearly enough from the two lines that do it.
A consumption record was half snapshot and half live view of its move: the quantity, the units and the content rate were frozen at creation, while the product, the date and the two locations were stored related fields that followed whatever the move was later made to say. A move corrected after the fact therefore moved a reported amount into another period, or left it showing the locations of a return while still counting as a consumption. Precompute the four of them from the move as well, so that the whole record describes the move as it was validated, and freeze what is left: move_id and substance_id become readonly, and the content rate loses the writable flag that let an inventory manager type over it. With nothing left to edit, the form view goes, the list refuses create, edit and delete, and the manager loses write on the model -- create and unlink stay, the rebuild action needs them. A composition that was registered wrongly is fixed on the product and replayed with Update Chemical Consumption, which is the only correction path there was any point in keeping: it rebuilds the whole move, so the figure always traces back to a move and a composition rather than to something someone typed over it. The CHECK on the content rate goes with the writable flag. The value only ever arrives from the product line, which carries the same constraint. Drop the two translations that no longer have a term behind them: the help of the locations, which was inherited from stock.move and described an operation rather than a record, and the company of a field removed earlier. Drop the Smart Search entries as well -- base_name_search_improved injects that field into every model, and this one does not depend on it.
All four masters carry an active flag, but only the laws and the substances offered the Archived filter in their search view. A major or minor category that was archived therefore dropped out of its own menu with no way to bring it back on screen, and so no way to unarchive it.
required=True on a Float promises that a content rate has to be entered, but 0.0 is a value like any other: the client considers the field filled and the line saves at 0%, silently reporting the substance with no amount at all. The flag only ever made the column NOT NULL, which the default already guaranteed. The range is still guarded by the CHECK constraint.
The module is still unreleased on this branch and goes out as a single addition, so it carries the initial version rather than the running count of the commits that built it.
nobuQuartile
marked this pull request as ready for review
September 2, 2026 01:27
Contributor
|
@AungKoKoLin1997 |
Adding a name to the list is not a reason to take the previous one off it.
Both halves of the name are required, so guarding the CAS number on the name as well only spelled out a case a saved record cannot be in, and the fallback had two branches for a field that is never empty either.
…y CAS The search box on the product view carried a filter_domain that went straight at the CAS number of the product lines, which meant the search method behind chemical_substance_ids was never reached: searching a substance by its name returned nothing, only its CAS number matched. Drop the override and let the field search itself. The substance master already declares _rec_names_search on both its name and its CAS number, so the box now matches either -- 'Ethanol' finds what '64-17-5' finds, and more, where several substances share the name. The label says so.
Nine stored fields, six of which did nothing but hold a copy of a value the move already carried, and a compute method each to put it there. The record was frozen whole so that a move corrected after the fact could not rewrite an amount that had already been reported -- but a done move is not rewritten in practice, Odoo refuses to move its locations at all, and the rebuild action re-reads everything from the move anyway, so the guarantee was paid for in code and bought little. Make the six related and drop their computes. They are not stored: ordering by the actual date, grouping by the product, the two locations and the date, and the date range filter all work through the join Odoo generates for a related field, so the columns earn nothing either. The composition stays put, which is the part worth freezing: the content rate is still precomputed at creation and does not follow a revision of the product, and a rate registered wrongly is replayed with Update Chemical Consumption. The amount follows the move again through the rate, which is what correcting the quantity of a move is meant to do. The guard on the two units in _compute_amount goes as well. stock.move requires its unit of measure and product.template requires its own, so neither can be empty by the time the amount is computed.
Contributor
|
Ready to review |
AungKoKoLin1997
approved these changes
Sep 7, 2026
…bout Sitting above move_id, the comment read as a note on the relation, which is the one thing on this model that needs no explaining. Move it onto the content rate, which is what it was always about, and say the one thing that is not visible in the field definition: a product whose content rate is revised must leave the rate the reported amounts were computed with alone. The sentence on the move side goes. Six related fields say for themselves that they follow the move.
stock depends on product, which depends on uom, so naming the three of them only spelled out a chain Odoo already walks.
AungKoKoLin1997
approved these changes
Sep 10, 2026
Contributor
|
Add ja.po Translation notesTranslations are referenced from existing Odoo translations where available (odoo/stock, odoo/product, odoo/uom, odoo/account) — 26 of 90 entries. Two entries intentionally deviate from their
The following terms have no reference and are translated independently:
Note on the exportThe raw export also carried 71 Japanese names for One obsolete entry was dropped ( |
nobuQuartile
force-pushed
the
18.0-add-product_chemical
branch
from
September 14, 2026 02:07
f6799a9 to
c8eb4e0
Compare
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
QT6791