Message Threads | The Odoo Community Association

Status of different branches and reasoning to choose

Hi,

oca hosts a lot of repositories whith branches for the different 
versions of odoo (..14,16,17). What's missing for me is a big picture of 
the overall state of the different versions... Is community still most 
complete/stable on 14, 16 oder 17 (or maybe even 12)?

What version would you suggest to start with?

What's also missing for me is a good big picture on the difference in 
code/features beetween odoo enterprise, odoo open-source and oca on the 
different versions.

thx for any feedback,
Peter

by Peter Niederlag - 01:16 - 18 Feb 2024

Re: Mounting location of part upon production

Hi Tom,

You should be able to have each of the items (specified legs) be on one BOM and when the Manufacturing order is created, you select the serial numbers being used on those individual line items.

I might need to build up a test case to be able to show you, and I should check to see what modules I have running that are beyond standard to enable that.

I would be happy to connect directly. If I build a test case I could likely share a video or some images.

I should add, perhaps I am wrong, but this seems pretty doable. If not doable, it should be.

Landis

Landis Arnold

Nomadic Inc.

Niwot, CO USA

larnold@nomadic.net

From: "Tom Blauwendraat" <notifications@odoo-community.org>
To: "Odoo Community Association, (OCA) Contributors" <contributors@odoo-community.org>
Sent: Friday, February 16, 2024 7:31:46 AM
Subject: Re: Mounting location of part upon production

On 2/16/24 15:17, Landis Arnold wrote:

>

> One way to accomplish some of this is to simply use "structured 

> serialization".

> If you were to apply  to your Chair use case, you might do the following:

>

> 200 Legs become 200 serialized items.

> In your BOM you would apply a Top Down with Chair, Leg position 1, 2, 

> 3 and 4, Other components

> Focusing on the Leg Positions:  Basically a BOM for each would allow 

> the Serialized Legs to be used for their source.

> You would Select a Serial Number for each in the BOM positions for 

> each (leg1, leg2, leg3, leg4)

Hi Landis,

this sounds exactly like what I need, but I'm not sure that I follow - 
if you say you need a "bom for each", then you basically mean defining 
each leg as a separate product, which you include in the main BoM; so 
there's a production step in between where a leg becomes a leg1, and 
then becomes part of the table. Am I right? Or are you talking about 
some other kind of serialization, that I don't yet know about?

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Landis Arnold - 06:51 - 16 Feb 2024

Re: Concurrency write check

> I guess it's easy to (re)build this as an OCA module, although instances that install it will probably also run into the problems that made Odoo ditch it.

I agree, a less impacting solution should be better.

Il giorno ven 16 feb 2024 alle ore 15:12 David Vidal <notifications@odoo-community.org> ha scritto:

> From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.

In the web_editor there's a kind of concurrence protection: https://github.com/OCA/OCB/blob/15.0/addons/web_editor/controllers/main.py#L32-L39

Interesting, but it's only implemented for collaborative pages on web (events? I couldn't find where).

Sergio Corato

El vie, 16 feb 2024 a las 14:32, Sergio Corato (<notifications@odoo-community.org>) escribió:
From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.
Sergio Corato
Il giorno ven 16 feb 2024 alle ore 10:32 Ronald Portier <notifications@odoo-community.org> ha scritto:
So basically Odoo has no longer any mechanism to prevent the changes of one user undoing the changes of another user.

In applications traditionally two mechanisms existed that intended to prevent this problem, respectively pessimistic and optimistic locking.

In pessimistic locking anybody touching a record with the potential to update it, would establish a lock on the record, other users would be prevented from reading the same record for update. This has the potential for lots of access problems, especially as databases and transactions became more complicated and would no longer involve single records but whole networks of records.

Optimistic locking would, as Odoo does, timestamp all records. The idea that most reads that have a potential to update a record, mostly would not be updating anything. But when updating, the timestamp of the record read would be compared with the current timestamp and any previous change would result in an Exception.

An alternative method for optimistic locking, not depending on timestamps, would be to save the original record image and compare with the actual record image just before the actual update.

Missing either pessimistic locking or optimistic locking, for some applications it might be needed to implement a mechanism where a user must specifically claim a main application object for change, before being allowed to update it. A claim made preventing other users from making the same claim, before the application object being released. A main application object could be a Customer, an Order or a Helpdesk Ticket. Such a claim would work like a "check out" in document management systems, or a kind of Semaphore on OS level.

On 15-02-2024 23:11, Tom Blauwendraat wrote:
Closest I could come in finding some info about it is this:

https://github.com/odoo/odoo/pull/87756

Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.

On 2/15/24 19:07, Sergio Corato wrote:
The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).

Debugging didn't help, the context is never passed with the field '__last_update'.

However it's not a requested function, I'll give up for now ;)

Thanks

Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function 
was deleted in 16.0 (but maybe renamed).

I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Sergio Corato - 04:11 - 16 Feb 2024

Re: Mounting location of part upon production

On 2/16/24 15:17, Landis Arnold wrote:

>

> One way to accomplish some of this is to simply use "structured 

> serialization".

> If you were to apply  to your Chair use case, you might do the following:

>

> 200 Legs become 200 serialized items.

> In your BOM you would apply a Top Down with Chair, Leg position 1, 2, 

> 3 and 4, Other components

> Focusing on the Leg Positions:  Basically a BOM for each would allow 

> the Serialized Legs to be used for their source.

> You would Select a Serial Number for each in the BOM positions for 

> each (leg1, leg2, leg3, leg4)

Hi Landis,

this sounds exactly like what I need, but I'm not sure that I follow - 
if you say you need a "bom for each", then you basically mean defining 
each leg as a separate product, which you include in the main BoM; so 
there's a production step in between where a leg becomes a leg1, and 
then becomes part of the table. Am I right? Or are you talking about 
some other kind of serialization, that I don't yet know about?

by Tom Blauwendraat - 03:30 - 16 Feb 2024

Re: Mounting location of part upon production

Perhaps related to your request Tom,

I have worked through something "similar" to this recently. My use case involved "halves" of a paddle tracked by incoming lots, right and left side, weights and lengths, and quality.

The objective of the process was to primarily match pairs, such that left and right side would be balanced, we would know the combined maximum length of the two sides, and we would flush out any blemishes, and in fact also try to pair blemishes.

I used Serialization of Incoming as well as BOM processes for this.

In parallel I built a system in Filemaker which would allow quick sorting of weights/lengths etc. That sorting allowed relatively simple processing of components into pairs. Then at time of final build the pairs are combined to built paddle in specific length, twists and control hand specifications.

Back in Odoo, the traceability report shows the full flow of components used in each paddle. In the Inventory/Warehouse App, if you look at Serial Numbers. then unselect "product" in the filter/search box, you can then see all of the serial numbers and if used, where they have been used. This would go "up or down" in terms of a flow from initial part, paired part, built part.

-------

But about your Chair and Chair Leg approach.

One way to accomplish some of this is to simply use "structured serialization".

If you were to apply to your Chair use case, you might do the following:

200 Legs become 200 serialized items.

In your BOM you would apply a Top Down with Chair, Leg position 1, 2, 3 and 4, Other components

Focusing on the Leg Positions: Basically a BOM for each would allow the Serialized Legs to be used for their source.

You would Select a Serial Number for each in the BOM positions for each (leg1, leg2, leg3, leg4)

----

I have been doing this with Odoo 14 Community. There could definitely be different/better reports for some of this, but if you look well enough, and jump to the correct app, most things are findable.

I hope that some of this above may be helpful.

Landis Arnold

Nomadic Inc.

Niwot, CO USA

From: "Tom Blauwendraat" <notifications@odoo-community.org>
To: "Odoo Community Association, (OCA) Contributors" <contributors@odoo-community.org>
Sent: Tuesday, February 6, 2024 1:17:27 PM
Subject: Re: Mounting location of part upon production

That could indeed be a nice idea - based on where the leg is placed at the moment, we modify a field on the serial number indicating the position.

That said, maybe it could then also be an extra field that we store the information on in stock.move or stock.quant table, to avoid write traffic on the lot table. Let me think about that some more.

Thanks, Graeme!

Therp - Open Source ERP solutions built on Odoo

On 6 Feb 2024, at 12:22, Graeme Gellatly <notifications@odoo-community.org> wrote:

Yes, but there is a second field on serials, I don't recall its name, but I use it a lot to store information and lot names are surprisingly accessible during manufacturing processes. I wouldn't discount the idea, it is a pretty simple workaround.
On Tue, Feb 6, 2024 at 5:42 AM Tom Blauwendraat <notifications@odoo-community.org> wrote:
On 2/5/24 16:02, Daniel Reis wrote:



> Option 3 looks similar to Lot/Serial usage. What if you (ab)used Lot 



> numbers for this?

Good idea in theory, but in my case we're already using serial numbers 
to track the parts
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Landis Arnold - 03:16 - 16 Feb 2024

Re: Concurrency write check

> From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.

In the web_editor there's a kind of concurrence protection: https://github.com/OCA/OCB/blob/15.0/addons/web_editor/controllers/main.py#L32-L39

El vie, 16 feb 2024 a las 14:32, Sergio Corato (<notifications@odoo-community.org>) escribió:

From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.
Sergio Corato
Il giorno ven 16 feb 2024 alle ore 10:32 Ronald Portier <notifications@odoo-community.org> ha scritto:
So basically Odoo has no longer any mechanism to prevent the changes of one user undoing the changes of another user.

In applications traditionally two mechanisms existed that intended to prevent this problem, respectively pessimistic and optimistic locking.

In pessimistic locking anybody touching a record with the potential to update it, would establish a lock on the record, other users would be prevented from reading the same record for update. This has the potential for lots of access problems, especially as databases and transactions became more complicated and would no longer involve single records but whole networks of records.

Optimistic locking would, as Odoo does, timestamp all records. The idea that most reads that have a potential to update a record, mostly would not be updating anything. But when updating, the timestamp of the record read would be compared with the current timestamp and any previous change would result in an Exception.

An alternative method for optimistic locking, not depending on timestamps, would be to save the original record image and compare with the actual record image just before the actual update.

Missing either pessimistic locking or optimistic locking, for some applications it might be needed to implement a mechanism where a user must specifically claim a main application object for change, before being allowed to update it. A claim made preventing other users from making the same claim, before the application object being released. A main application object could be a Customer, an Order or a Helpdesk Ticket. Such a claim would work like a "check out" in document management systems, or a kind of Semaphore on OS level.

On 15-02-2024 23:11, Tom Blauwendraat wrote:
Closest I could come in finding some info about it is this:

https://github.com/odoo/odoo/pull/87756

Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.

On 2/15/24 19:07, Sergio Corato wrote:
The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).

Debugging didn't help, the context is never passed with the field '__last_update'.

However it's not a requested function, I'll give up for now ;)

Thanks

Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function 
was deleted in 16.0 (but maybe renamed).

I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by David Vidal - 03:11 - 16 Feb 2024

Re: Concurrency write check

I guess it's easy to (re)build this as an OCA module, although instances that install it will probably also run into the problems that made Odoo ditch it.

On 2/16/24 14:32, Sergio Corato wrote:

From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.

Sergio Corato
Il giorno ven 16 feb 2024 alle ore 10:32 Ronald Portier <notifications@odoo-community.org> ha scritto:
So basically Odoo has no longer any mechanism to prevent the changes of one user undoing the changes of another user.

In applications traditionally two mechanisms existed that intended to prevent this problem, respectively pessimistic and optimistic locking.

In pessimistic locking anybody touching a record with the potential to update it, would establish a lock on the record, other users would be prevented from reading the same record for update. This has the potential for lots of access problems, especially as databases and transactions became more complicated and would no longer involve single records but whole networks of records.

Optimistic locking would, as Odoo does, timestamp all records. The idea that most reads that have a potential to update a record, mostly would not be updating anything. But when updating, the timestamp of the record read would be compared with the current timestamp and any previous change would result in an Exception.

An alternative method for optimistic locking, not depending on timestamps, would be to save the original record image and compare with the actual record image just before the actual update.

Missing either pessimistic locking or optimistic locking, for some applications it might be needed to implement a mechanism where a user must specifically claim a main application object for change, before being allowed to update it. A claim made preventing other users from making the same claim, before the application object being released. A main application object could be a Customer, an Order or a Helpdesk Ticket. Such a claim would work like a "check out" in document management systems, or a kind of Semaphore on OS level.

On 15-02-2024 23:11, Tom Blauwendraat wrote:
Closest I could come in finding some info about it is this:

https://github.com/odoo/odoo/pull/87756

Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.

On 2/15/24 19:07, Sergio Corato wrote:
The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).

Debugging didn't help, the context is never passed with the field '__last_update'.

However it's not a requested function, I'll give up for now ;)

Thanks

Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function 
was deleted in 16.0 (but maybe renamed).

I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Tom Blauwendraat - 03:11 - 16 Feb 2024

Re: Concurrency write check

From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.

Sergio Corato

Il giorno ven 16 feb 2024 alle ore 10:32 Ronald Portier <notifications@odoo-community.org> ha scritto:

So basically Odoo has no longer any mechanism to prevent the changes of one user undoing the changes of another user.

In applications traditionally two mechanisms existed that intended to prevent this problem, respectively pessimistic and optimistic locking.

In pessimistic locking anybody touching a record with the potential to update it, would establish a lock on the record, other users would be prevented from reading the same record for update. This has the potential for lots of access problems, especially as databases and transactions became more complicated and would no longer involve single records but whole networks of records.

Optimistic locking would, as Odoo does, timestamp all records. The idea that most reads that have a potential to update a record, mostly would not be updating anything. But when updating, the timestamp of the record read would be compared with the current timestamp and any previous change would result in an Exception.

An alternative method for optimistic locking, not depending on timestamps, would be to save the original record image and compare with the actual record image just before the actual update.

Missing either pessimistic locking or optimistic locking, for some applications it might be needed to implement a mechanism where a user must specifically claim a main application object for change, before being allowed to update it. A claim made preventing other users from making the same claim, before the application object being released. A main application object could be a Customer, an Order or a Helpdesk Ticket. Such a claim would work like a "check out" in document management systems, or a kind of Semaphore on OS level.

On 15-02-2024 23:11, Tom Blauwendraat wrote:
Closest I could come in finding some info about it is this:

https://github.com/odoo/odoo/pull/87756

Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.

On 2/15/24 19:07, Sergio Corato wrote:
The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).

Debugging didn't help, the context is never passed with the field '__last_update'.

However it's not a requested function, I'll give up for now ;)

Thanks

Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function 
was deleted in 16.0 (but maybe renamed).

I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Sergio Corato - 02:27 - 16 Feb 2024

Re: Concurrency write check

So basically Odoo has no longer any mechanism to prevent the changes of one user undoing the changes of another user.

In applications traditionally two mechanisms existed that intended to prevent this problem, respectively pessimistic and optimistic locking.

In pessimistic locking anybody touching a record with the potential to update it, would establish a lock on the record, other users would be prevented from reading the same record for update. This has the potential for lots of access problems, especially as databases and transactions became more complicated and would no longer involve single records but whole networks of records.

Optimistic locking would, as Odoo does, timestamp all records. The idea that most reads that have a potential to update a record, mostly would not be updating anything. But when updating, the timestamp of the record read would be compared with the current timestamp and any previous change would result in an Exception.

An alternative method for optimistic locking, not depending on timestamps, would be to save the original record image and compare with the actual record image just before the actual update.

Missing either pessimistic locking or optimistic locking, for some applications it might be needed to implement a mechanism where a user must specifically claim a main application object for change, before being allowed to update it. A claim made preventing other users from making the same claim, before the application object being released. A main application object could be a Customer, an Order or a Helpdesk Ticket. Such a claim would work like a "check out" in document management systems, or a kind of Semaphore on OS level.

On 15-02-2024 23:11, Tom Blauwendraat wrote:

Closest I could come in finding some info about it is this:

https://github.com/odoo/odoo/pull/87756

Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.

On 2/15/24 19:07, Sergio Corato wrote:
The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).

Debugging didn't help, the context is never passed with the field '__last_update'.

However it's not a requested function, I'll give up for now ;)

Thanks

Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function 
was deleted in 16.0 (but maybe renamed).

I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by "Ronald Portier" <rportier@therp.nl> - 10:31 - 16 Feb 2024

Re: Concurrency write check

Very useful info, clarifies everything.

Probably a better solution would have been to just show an info to the user and remove the raise, but they did the simpler thing :)

Many thanks!

Sergio Corato

Il giorno gio 15 feb 2024 alle ore 23:11 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:

Closest I could come in finding some info about it is this:

https://github.com/odoo/odoo/pull/87756

Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.

On 2/15/24 19:07, Sergio Corato wrote:
The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).

Debugging didn't help, the context is never passed with the field '__last_update'.

However it's not a requested function, I'll give up for now ;)

Thanks

Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function 
was deleted in 16.0 (but maybe renamed).

I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Sergio Corato - 09:25 - 16 Feb 2024

Re: Concurrency write check

Closest I could come in finding some info about it is this:

https://github.com/odoo/odoo/pull/87756

Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.

On 2/15/24 19:07, Sergio Corato wrote:

The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).

Debugging didn't help, the context is never passed with the field '__last_update'.

However it's not a requested function, I'll give up for now ;)

Thanks

Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function 
was deleted in 16.0 (but maybe renamed).

I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Tom Blauwendraat - 11:10 - 15 Feb 2024

Re: Concurrency write check

The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).

Debugging didn't help, the context is never passed with the field '__last_update'.

However it's not a requested function, I'll give up for now ;)

Thanks

Sergio Corato

Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:

I also looked for unit tests and didn't find, and also saw this function 
was deleted in 16.0 (but maybe renamed).

I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Sergio Corato - 07:06 - 15 Feb 2024

Re: Concurrency write check

I also looked for unit tests and didn't find, and also saw this function 
was deleted in 16.0 (but maybe renamed).

I think debugging is the only way to find out! pdb to the rescue

by Tom Blauwendraat - 05:06 - 15 Feb 2024

Re: Concurrency write check

Hi Tom,

I think this check should always be called, because it's a security check.

It should work the way you described.

I looked for some tests with no luck, maybe I didn't check in the right place?

Many thanks

Sergio Corato

Il giorno gio 15 feb 2024 alle ore 12:02 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:

It looks like it only actions when CONCURRENCY_FIELD ("__last_update") 
is defined in the context, maybe that's why it's not triggering for you?

The functionality seems indeed to be that whenever someone tries to save 
a change on a form view of something that someone else saved meanwhile, 
it drops out with a validation error.

Perhaps they added the context key just to be able to test with this 
functionality before rolling it out?

On 2/14/24 18:27, Sergio Corato wrote:

> Hi,

> I haven't found a way to check if the concurrency check here works: 

> https://github.com/odoo/odoo/blob/14.0/odoo/models.py#L3251

> Shouldn't it warn/block if someone tries to write on a field that has 

> been modified in the meanwhile?

> Sergio Corato

>

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe

>

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Sergio Corato - 03:06 - 15 Feb 2024

Re: Concurrency write check

It looks like it only actions when CONCURRENCY_FIELD ("__last_update") 
is defined in the context, maybe that's why it's not triggering for you?

The functionality seems indeed to be that whenever someone tries to save 
a change on a form view of something that someone else saved meanwhile, 
it drops out with a validation error.

Perhaps they added the context key just to be able to test with this 
functionality before rolling it out?

On 2/14/24 18:27, Sergio Corato wrote:

> Hi,

> I haven't found a way to check if the concurrency check here works: 

> https://github.com/odoo/odoo/blob/14.0/odoo/models.py#L3251

> Shouldn't it warn/block if someone tries to write on a field that has 

> been modified in the meanwhile?

> Sergio Corato

>

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe

>

by Tom Blauwendraat - 12:01 - 15 Feb 2024

Concurrency write check

Hi,

I haven't found a way to check if the concurrency check here works: https://github.com/odoo/odoo/blob/14.0/odoo/models.py#L3251

Shouldn't it warn/block if someone tries to write on a field that has been modified in the meanwhile?

Sergio Corato

by Sergio Corato - 06:26 - 14 Feb 2024

Re: Group all related stock picking

Thank you Vincent. Will further test it.

----- Original message -----

From: Vincent Van Rossem <notifications@odoo-community.org>

To: Contributors <contributors@odoo-community.org>

Subject: Re: Group all related stock picking

Date: Monday, February 12, 2024 18:36

Hello Yves,

Could stock_picking_show_linked help you?

This module should allow a user to display, on smart buttons in a picking:

Destination pickings: the pickings associated to destination moves indicated in the moves in this picking
Origin pickings: the pickings associated to origin moves indicated in the moves in this picking

On Mon, Feb 12, 2024 at 4:27 PM Yves Goldberg <notifications@odoo-community.org> wrote:

Hello,
I am looking for a way to search and group all related stock picking.
In the following snapshot I am resupplying in 1 step between 2 warehouses: a delivery from WH2 to transit and then another reception from transit to WH1.

How may search/group these two pickings (or move or move.lines)?
I thought that the module stock_request would help me by setting the procurement group but it is not propagated to further legs (after first picking).
Is there an existing app that can help? How may I do this?
Thank you.

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________

Mailing-List: https://odoo-community.org/groups/contributors-15

Post to: mailto:contributors@odoo-community.org

Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Yves Goldberg - 03:25 - 13 Feb 2024

Re: Group all related stock picking

Hello Yves,

Could stock_picking_show_linked help you?

This module should allow a user to display, on smart buttons in a picking:

Destination pickings: the pickings associated to destination moves indicated in the moves in this picking
Origin pickings: the pickings associated to origin moves indicated in the moves in this picking

On Mon, Feb 12, 2024 at 4:27 PM Yves Goldberg <notifications@odoo-community.org> wrote:

Hello,
I am looking for a way to search and group all related stock picking.
In the following snapshot I am resupplying in 1 step between 2 warehouses: a delivery from WH2 to transit and then another reception from transit to WH1.

How may search/group these two pickings (or move or move.lines)?
I thought that the module stock_request would help me by setting the procurement group but it is not propagated to further legs (after first picking).
Is there an existing app that can help? How may I do this?
Thank you.

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by vincent.vanrossem - 05:36 - 12 Feb 2024

Group all related stock picking

Hello,

I am looking for a way to search and group all related stock picking.

In the following snapshot I am resupplying in 1 step between 2 warehouses: a delivery from WH2 to transit and then another reception from transit to WH1.

How may search/group these two pickings (or move or move.lines)?

I thought that the module stock_request would help me by setting the procurement group but it is not propagated to further legs (after first picking).

Is there an existing app that can help? How may I do this?

Thank you.

by Yves Goldberg - 04:25 - 12 Feb 2024

1 attachments 1 attachments

Re: Consuming stock internally while using the its costs in project

Graeme & others,

thank you for your input. I went for option 2. and it seems to be working. I have wanted to keep this tied to the project as other inputs affect profitability (timesheets for example) and it is created from sale order. The general scenario is:

1. I use OCA stock_analytic and stock_picking_analytic modules to get analytic distribution into stock.picking and stock.move and stock.move.line
2. I have created a scrap location representing the kitchen where I consume/expense/scrap the ingredients
3. I have an automatic inventory valuation setup (AVCO but I guess would work with any other)
4. I have created a module that includes valuation records for scrap operations into project profitability.

So when I want to expens the ingredients I create an stock picking to the scrap (kitchen) location using the project's analytical tag. The ingredients will get scrapped creating a negative valuation record with analytic distribution from the stock picking. The project module adds account.analytic.lines (the valuation) records with (quite naive but works) domain like this into profitability calculation: 

            ("account_id", "=", self.analytic_account_id.id),
            (
                "move_line_id.move_id.stock_move_id.location_dest_id.usage",
                "=",
                "inventory",
            ),
            ("category", "!=", "manufacturing_order"),

Any comments on this are welcome. I have migrated stock_analytic and stock_picking_analytic to 17.0 and will open PRs soon. If there was an interest into my module I will gladly donate to OCA.

Best regards

	Radovan Skolnik

On streda 7. februára 2024 21:12:41 CET Graeme Gellatly wrote:

> There are a couple of things I can think of.

> 1. Manufacturing Orders - ingredients as raw materials, portions as outputs,

> workorders as labour. Delivery Order for what is delivered, Analytic

> Accounts on sale. Can be done with/without projects. Will add up all your

> costs. 2. Stock locations - this is not quite the same fit, but many times

> I have faced scenarios where stocked goods are required for internal

> projects and the easiest way has been a stock transfer to a location with a

> different account set. Analytics could be added to both manufacturing and

> stock easily enough and I believe OCA has modules to do so. Also for

> linking MO's to projects. If you had a separate product / customer and used

> anglosaxon you would end up with effectively actual cost, unfortunately

> actual cost is an Odoo Enterprise only direct from Odoo feature at the

> moment, but for something this basic it could be done quite simply.

> Otherwise you could use average cost and rely on analytics/other reporting

> for actuals. On Thu, Feb 8, 2024 at 8:41 AM Radovan Skolnik <

> notifications@odoo-community.org [1] > wrote: Hello,

> I am dealing with a customer who provides catering services. The price is

> dependent only on how many portions they serve regardless of the costs of

> labour and/or ingredients used.

> I am planning to use projects (analytic accounts) to keep track of

> profitability related to Sale Orders that will be invoiced based od

> delivered quantities (of portions). Now I am scratching my head as on how

> to consume storable stock (ingredients) in a way that its value would be

> added as a cost to the project. Internal transfers? Purchase Order within

> the organization? The cost of staff should be possible to be dealt with

> with timesheets. Is that so?

> Any advice is highly welcome. Thank you

> Best regards

> Radovan Skolnik

> 

> 

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 [2]

> Post to: mailto: contributors@odoo-community.org [3]

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [4]

> 

> 

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 [5]

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [6]

> 

> 

> 

> [1] mailto:notifications@odoo-community.org

> [2] https://odoo-community.org/groups/contributors-15

> [3] mailto:contributors@odoo-community.org

> [4] https://odoo-community.org/groups?unsubscribe

> [5] https://odoo-community.org/groups/contributors-15

> [6] https://odoo-community.org/groups?unsubscribe

by Radovan Skolnik - 10:31 - 12 Feb 2024

Archives

Contributors

Status of different branches and reasoning to choose

Re: Mounting location of part upon production

Re: Concurrency write check

Re: Mounting location of part upon production

Re: Mounting location of part upon production

Re: Concurrency write check

Re: Concurrency write check

Re: Concurrency write check

Re: Concurrency write check

Re: Concurrency write check

Re: Concurrency write check

Re: Concurrency write check

Re: Concurrency write check

Re: Concurrency write check

Re: Concurrency write check

Concurrency write check

Re: Group all related stock picking

Re: Group all related stock picking

Group all related stock picking

Re: Consuming stock internally while using the its costs in project

Follow us