Skip to content

Conversation

@eantones
Copy link
Member

…ion in _generate_translated_field odoo#18679

It solves issue odoo#18679 (odoo#18679) on Odoo v10

Only works on PostgreSQL 9.5 or above

…ion in _generate_translated_field odoo#18679

It solves issue odoo#18679 (odoo#18679) on Odoo v10

Only works on PostgreSQL 9.5 or above
@FFernandez-PlanetaTIC
Copy link

Gràcies! :)

@FFernandez-PlanetaTIC
Copy link

Hi @eantones ,

There is an issue in your backport of odoo#21472, the index should be unique:

https://github.com/odoo/odoo/pull/21472/files#diff-a41938cd3ff4c7e353103fcd581f839aL264

We have fixed it in #5.

Do you plan to create this PR to OCA?

Regards

@eantones
Copy link
Member Author

Hi @FFernandez-PlanetaTIC ,

Thanks for you contribution :-)

You're right, the index should be unique.

Regarding the previous deletion query, I think deleting actual user data from the database occurs a very very very few times in the Odoo base code. As I said it supposes deleting user data randomly just to allow the index creation. It could imply deleting tens of thousands of registers without any control. I think this fixes Odoo issue for a clean installation, in case of an existing system it should be treated outside the code in a more controlled way deleting selectively the duplicated registers before installing the fix.

Let me know what you think.

Gràcies
Eric

@FFernandez-PlanetaTIC
Copy link

Hi @eantones ,

Duplicated translations are not deleted randomly, the newest translations are keeped:

https://github.com/nuobit/odoo/pull/5/files#diff-c627bfcd372ec3e0ea066ce174ecdb6cR294

To preserve the previous behavior:

https://github.com/nuobit/odoo/pull/2/files#diff-9af8b31d921dcccb7bcf230271fd3ef4L4119

It is true that some duplicated translations can be lost but they were not used. I think the fix is much easier to apply this way in existing installations.

Happy new year!

@eantones
Copy link
Member Author

Hi @FFernandez-PlanetaTIC ,

happy new year ;-)

You're right, I did this a long time ago and I barely remembered, your solution is correct.

Thanks!

@eantones eantones merged this pull request into 10.0 Jan 10, 2020
@eantones
Copy link
Member Author

Replaced by #6

eantones pushed a commit that referenced this pull request Mar 30, 2023
Issue #1: reading textContent

When reading the textContent property of an element, its does not take into
account line breaks introduced by <br> and block elements, whilst innerHtml
does.

This commit solves the issue of updating a link's href to a non-sense url
upon label change. Before this commit, "www.abc.com <br> www.xyz.com" was
being incorrectely parsed as "www.abc.comwww.xyz.com".

Issue #2: setting textContent

When setting the textContent property of an element, all of its child nodes are
removed and replaced by a single text node. While this is fine when the
element contains a single text node, it might not be the desired result when
the element contains other children.

This commit solves the issue obtained when pasting html such as
"link.com<br>link.be" inside an empty inline element such as STRONG or A,
in which cleanForSave was changing its content (removing the line-break) due
to misuse of textContent, when the intended effected was simply removing
ZeroWidthSpace characters. A safer alternative for removing ZeroWidthSpace is
thus provided.

task-3081254

closes odoo#112448

X-original-commit: 0d1150f
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
FrankC013 pushed a commit that referenced this pull request Jul 24, 2023
Commit #2:
Splite the method `_compute_from_product_id_company_id` so each stored field has its own compute method to avoid invalidation issues.

opw-3336796

closes odoo#126529

Signed-off-by: William André (wan) <wan@odoo.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants