Archives
Contributors
-
Bug Report
Hi Team,I hope you are well.I would like to share another vulnerability of your websiteVulnerability 1: Non - secure requests are not automatically upgraded to HTTPS | HSTS missingDescriptionThe application fails to prevent users from connecting to it over unencrypted connections. An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection. The sslstrip tool automates this process.To exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.Steps to Reproduce:1) Go to https://hstspreload.org/ or https://securityheaders.com/2) enter your domainReferencesHTTP Strict Transport SecuritysslstripHSTS Preload FormImpact:The application should instruct web browsers to only access the application using HTTPS. To do this, enable HTTP Strict Transport Security (HSTS) by adding a response header with the name 'Strict-Transport-Security' and the value 'max-age=expireTime', where expireTime is the time in seconds that browsers should remember that the site should only be accessed using HTTPS. Consider adding the 'includeSubDomains' flag if appropriate.Note that because HSTS is a "trust on first use" (TOFU) protocol, a user who has never accessed the application will never have seen the HSTS header, and will therefore still be vulnerable to SSL stripping attacks. To mitigate this risk, you can optionally add the 'preload' flag to the HSTS header, and submit the domain for review by browser vendors.Vulnerability 2 : Strict transport security not enforcedPath: odoo-community.orgIssue Description:The application fails to prevent users from connecting to it over unencrypted connections. An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP, so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection. The sslstrip tool automates this process.To exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victim's network traffic.This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.Issue remediation:The application should instruct web browsers to only access the application using HTTPS. To do this, enable HTTP Strict Transport Security (HSTS) by adding a response header with the name 'Strict-Transport-Security' and the value 'max-age=expireTime', where expireTime is the time in seconds that browsers should remember that the site should only be accessed using HTTPS. Consider adding the 'includeSubDomains' flag if appropriate.Note that because HSTS is a "trust on first use" (TOFU) protocol, a user who has never accessed the application will never have seen the HSTS header, and will therefore still be vulnerable to SSL stripping attacks. To mitigate this risk, you can optionally add the 'preload' flag to the HSTS header, and submit the domain for review by browser vendors.Looking forward to hearing from you soon.Kind Regards.
by "Jenny Rose" <infosec.jenny@gmail.com> - 07:11 - 1 Aug 2024 -
🎫 Jueves Adhoc Live: Quickstart: el Sistema de Gestión para escalar tu Pyme sin gastar fortuna
🤯 Vos que sos emprendedor y te cuesta vender porque estás con 500 planillas de excel, que no sabes cuánto ganas o perdes, que no sabes cuánto stock tenes. Este streaming en vivo es para vos.
Bruno Davico y Victoria Garcia te muestran cómo pasar al frente en tu negocio y dejar la locura de las planillas, de la facturación recurrente manual y otros tantos problemas de una pequeña empresa en su día a día
⏰ Te esperamos el jueves 01/08 a las:🇦🇷🇨🇱🇺🇾 14 hs
🇪🇸 19 hs
Te podés inscribir e ingresar cuando estemos en vivo directamente desde este link.
Espero verte por ahí 🫡
Damián Vilagrasa
Marketing, Tech & Business Development
Adhoc SA
Recibiste este correo porque te suscribiste a Adhoc SA ¿Deseas desuscribirte? 
by "Dami de Adhoc" <dav@adhoc.com.ar> - 06:00 - 1 Aug 2024 -
Re: Activating tab on form from code?
I have know JS would be required but this is pure gold! Thanks a lot Enric!
Best regards
Radovan
On štvrtok 1. augusta 2024 0:02:56 CEST Enric Tobella Alomar wrote:
> You need to do it using Javascript. On Account Reconcile OCA you can find an
> example how it is done
> https://github.com/OCA/account-reconcile/blob/16.0/account_reconcile_oca/st
> atic/src/js/reconcile_form/reconcile_form_notebook.esm.js [1] Kind regards,
> El mié, 31 jul 2024 a las 22:27, Ronald Portier (<
> notifications@odoo-community.org [2] >) escribió: Hi,
>
>
> I think this would
> probably most easily done through JavaScript. Basically emulate
> a click on the desired tab when the user opens the form, or
> moves to the next record. Unfortunately I have no example, as I
> am not deep into Odoo JS myself.
>
>
> Kind regards, Ronald
>
>
> On 31-07-2024 19:57, Radovan Skolnik
> wrote:
>
>
> Hello,
>
> I
> would need to make certain tab active based on field contents
> of the record in basically 2 scenarios:
> 1)
> As a result of the action
> 2)
> When opening the record in form view
>
> The
> idea is to lead the user to a tab where they need to fill in
> some stuff.
>
> 2)
> would override default system behavior that tries to keep last
> open tab open when switching to next record - i.e. I open one
> record from tree view and the press Next. It should also work
> when I open the first one.
> 1)
> would seem to be easier but I do not have any idea how to
> tacke this. Manipulating view architecture does not seem to
> work because there is no information on the record being
> displayed
>
> Am
> I missing something? Any pointers on how to do this?
>
> Thank
> you very much. Best regards
>
>
> Radovan
>
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [3]
> Post to: mailto:contributors@odoo-community.org [4]
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [5]
>
>
>
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [6]
> Post to: mailto: contributors@odoo-community.org [7]
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [8]
>
> --
> *Enric Tobella Alomar* CEO & Founder
> www.dixmit.com [9]
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [10]
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [11]
>
>
>
> [1]
> https://github.com/OCA/account-reconcile/blob/16.0/account_reconcile_oca/st
> atic/src/js/reconcile_form/reconcile_form_notebook.esm.js [2]
> mailto:notifications@odoo-community.org
> [3] https://odoo-community.org/groups/contributors-15
> [4] mailto:contributors@odoo-community.org
> [5] https://odoo-community.org/groups?unsubscribe
> [6] https://odoo-community.org/groups/contributors-15
> [7] mailto:contributors@odoo-community.org
> [8] https://odoo-community.org/groups?unsubscribe
> [9] http://www.dixmit.com
> [10] https://odoo-community.org/groups/contributors-15
> [11] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 10:00 - 1 Aug 2024 -
Re: Activating tab on form from code?
You need to do it using Javascript. On Account Reconcile OCA you can find an example how it is doneKind regards,El mié, 31 jul 2024 a las 22:27, Ronald Portier (<notifications@odoo-community.org>) escribió:Hi,
I think this would probably most easily done through JavaScript. Basically emulate a click on the desired tab when the user opens the form, or moves to the next record. Unfortunately I have no example, as I am not deep into Odoo JS myself.
Kind regards, Ronald
On 31-07-2024 19:57, Radovan Skolnik wrote:
Hello,
I would need to make certain tab active based on field contents of the record in basically 2 scenarios:
1) As a result of the action
2) When opening the record in form view
The idea is to lead the user to a tab where they need to fill in some stuff.
2) would override default system behavior that tries to keep last open tab open when switching to next record - i.e. I open one record from tree view and the press Next. It should also work when I open the first one.
1) would seem to be easier but I do not have any idea how to tacke this. Manipulating view architecture does not seem to work because there is no information on the record being displayed
Am I missing something? Any pointers on how to do this?
Thank you very much. Best regards
Radovan
_______________________________________________
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
--Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 11:57 - 31 Jul 2024 -
Activating tab on form from code?
Hello,
I would need to make certain tab active based on field contents of the record in basically 2 scenarios:
1) As a result of the action
2) When opening the record in form view
The idea is to lead the user to a tab where they need to fill in some stuff.
2) would override default system behavior that tries to keep last open tab open when switching to next record - i.e. I open one record from tree view and the press Next. It should also work when I open the first one.
1) would seem to be easier but I do not have any idea how to tacke this. Manipulating view architecture does not seem to work because there is no information on the record being displayed
Am I missing something? Any pointers on how to do this?
Thank you very much. Best regards
Radovan
by Radovan Skolnik - 07:56 - 31 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
In my experience, and from what I can read, unreachable commits get garbage collected at some point and effectively disappear from GitHub.This makes sense, for instance when you need to remove security sensitive stuff that would have been committed by accident.This is the main drawback of any force push operation:Integrators who would have pinned commits posterior to the commit that added the .deb files will likely encounter errors at some point,and will have difficulties to recover code that is identical to what they have pinned.The other attention point I see is that weblate will enter in conflict for all these branches.This will require a manual operation to rebase or reset all affected branches in GitLab.So if we do this, we must make sure people stop translating a few hours before the force push.Regarding the repo size, I'm also not convinced we will gain that much in practice.In OCA CI, action/checkout fetches the last commit only by default, and the OCA bot has a git cache, so the effect is probably negligible compared to everything else that is going on.And since the Odoo ecosystem is used to wrestle a huge repo, a lot of folks have developed strategies to save bandwidth (shallow clones, git worktrees, etc).Also, do we know what will happen to PR that have been created after the .deb commit?So yeah, sorry for the mistake, happy to change my mind if anything I said above is wrong, but at this stage I'm not convinced this is worth the manual effort and downstream disturbances.Best,-StéphaneOn Mon, Jul 29, 2024 at 8:58 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:> I'm more concerned about commit history after the file merge. Nothing more.Try this if you want:- Do a pull request with a migration.- Copy a permalink of something of the migration commit.- git commit --amend and git push -f- Open the previous permalink and it will work.Anyway, the path of these branches is still very young, and it is better to do it as soon as possible (also for avoiding more and more clones).Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 12:51 - 31 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
> I'm more concerned about commit history after the file merge. Nothing more.Try this if you want:- Do a pull request with a migration.- Copy a permalink of something of the migration commit.- git commit --amend and git push -f- Open the previous permalink and it will work.Anyway, the path of these branches is still very young, and it is better to do it as soon as possible (also for avoiding more and more clones).Regards.
by Pedro M. Baeza - 08:57 - 29 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
> Apart of that, an ecological reason cannot be put on the table here if we continue to recreate main branches from scratch as that leads to more repository space than the problem here araised.Are you seriously comparing at least 30 MB - on OCA/social it's 60 MB - each time a clone / pull is done (and all the automated tools that require cloning from scratch without depth control) vs 2-3 MB of the existing clones to reset the branch?
by Pedro M. Baeza - 08:57 - 29 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
As said, I understand the technical reasons.I'm more concerned about commit history after the file merge. Nothing more.Le lun. 29 juil. 2024, 20:42, Enric Tobella Alomar <notifications@odoo-community.org> a écrit :If we remove the file in a commit, it will not be removed from history, so, it will take a lot of Mb when we download the repository. The only way is to remove the file from history.El lun, 29 jul 2024 a las 20:38, Roussel, Denis (<notifications@odoo-community.org>) escribió:Even if I understand the issue here, I'm more doubtful about the force push mandatory operation (even if I understand the technical reason behind not to have the file appearance at all).I'm more concerned by the sha hashes problems we can have towards authorship.That said, I'm more to a commit removing the conflicting file.Apart of that, @Pedro Manuel Baeza , an ecological reason cannot be put on the table here if we continue to recreate main branches from scratch as that leads to more repository space than the problem here araised.Le lun. 29 juil. 2024, 18:12, Pedro M. Baeza <notifications@odoo-community.org> a écrit :Due to a mistake on the tool to generate the READMES (fixed in [1]), some very big files ~30 MB each~ (with extension .deb or .dmg for Mac users) have been added both by the merge bot or by users doing a module migration.This makes that on branch/repository clonation, or any free pull operation on any local git repository copy (of any branch) wastes a lot of bandwidth and resources, and is not ecological friendly.Due to this, and although not ideal, we plan to force push the affected repositories (note that this has been only in 17.0 branches), following [3] technique recommended by Nils.The drawback of doing this is that your next `git pull` operations on that branches will fail, saying about unrelated commit histories or creating a merge commit with possible conflicts.The solution for avoiding it is to do the commands:g it fetch origin 17.0 git reset --hard origin/17.0(beingoriginthe OCA remote). In fact, this is the recommended way to do it in automated pulling systems.If you don't have any strong counter-arguments, I will perform it at the end of the week. I will announce here the affected repositories after the operation.Regards._______________________________________________
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
--Enric Tobella AlomarCEO & Founder_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Denis Roussel - 08:51 - 29 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
If we remove the file in a commit, it will not be removed from history, so, it will take a lot of Mb when we download the repository. The only way is to remove the file from history.El lun, 29 jul 2024 a las 20:38, Roussel, Denis (<notifications@odoo-community.org>) escribió:Even if I understand the issue here, I'm more doubtful about the force push mandatory operation (even if I understand the technical reason behind not to have the file appearance at all).I'm more concerned by the sha hashes problems we can have towards authorship.That said, I'm more to a commit removing the conflicting file.Apart of that, @Pedro Manuel Baeza , an ecological reason cannot be put on the table here if we continue to recreate main branches from scratch as that leads to more repository space than the problem here araised.Le lun. 29 juil. 2024, 18:12, Pedro M. Baeza <notifications@odoo-community.org> a écrit :Due to a mistake on the tool to generate the READMES (fixed in [1]), some very big files ~30 MB each~ (with extension .deb or .dmg for Mac users) have been added both by the merge bot or by users doing a module migration.This makes that on branch/repository clonation, or any free pull operation on any local git repository copy (of any branch) wastes a lot of bandwidth and resources, and is not ecological friendly.Due to this, and although not ideal, we plan to force push the affected repositories (note that this has been only in 17.0 branches), following [3] technique recommended by Nils.The drawback of doing this is that your next `git pull` operations on that branches will fail, saying about unrelated commit histories or creating a merge commit with possible conflicts.The solution for avoiding it is to do the commands:
g it fetch origin 17.0 git reset --hard origin/17.0(beingoriginthe OCA remote). In fact, this is the recommended way to do it in automated pulling systems.If you don't have any strong counter-arguments, I will perform it at the end of the week. I will announce here the affected repositories after the operation.Regards._______________________________________________
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
--Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 08:41 - 29 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
Even if I understand the issue here, I'm more doubtful about the force push mandatory operation (even if I understand the technical reason behind not to have the file appearance at all).I'm more concerned by the sha hashes problems we can have towards authorship.That said, I'm more to a commit removing the conflicting file.Apart of that, @Pedro Manuel Baeza , an ecological reason cannot be put on the table here if we continue to recreate main branches from scratch as that leads to more repository space than the problem here araised.Le lun. 29 juil. 2024, 18:12, Pedro M. Baeza <notifications@odoo-community.org> a écrit :Due to a mistake on the tool to generate the READMES (fixed in [1]), some very big files ~30 MB each~ (with extension .deb or .dmg for Mac users) have been added both by the merge bot or by users doing a module migration.This makes that on branch/repository clonation, or any free pull operation on any local git repository copy (of any branch) wastes a lot of bandwidth and resources, and is not ecological friendly.Due to this, and although not ideal, we plan to force push the affected repositories (note that this has been only in 17.0 branches), following [3] technique recommended by Nils.The drawback of doing this is that your next `git pull` operations on that branches will fail, saying about unrelated commit histories or creating a merge commit with possible conflicts.The solution for avoiding it is to do the commands:
g it fetch origin 17.0 git reset --hard origin/17.0(beingoriginthe OCA remote). In fact, this is the recommended way to do it in automated pulling systems.If you don't have any strong counter-arguments, I will perform it at the end of the week. I will announce here the affected repositories after the operation.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Denis Roussel - 08:37 - 29 Jul 2024 -
pandoc-*.deb cleaning in OCA repositories
Due to a mistake on the tool to generate the READMES (fixed in [1]), some very big files ~30 MB each~ (with extension .deb or .dmg for Mac users) have been added both by the merge bot or by users doing a module migration.This makes that on branch/repository clonation, or any free pull operation on any local git repository copy (of any branch) wastes a lot of bandwidth and resources, and is not ecological friendly.Due to this, and although not ideal, we plan to force push the affected repositories (note that this has been only in 17.0 branches), following [3] technique recommended by Nils.The drawback of doing this is that your next `git pull` operations on that branches will fail, saying about unrelated commit histories or creating a merge commit with possible conflicts.The solution for avoiding it is to do the commands:
git fetch origin 17.0 git reset --hard origin/17.0(beingoriginthe OCA remote). In fact, this is the recommended way to do it in automated pulling systems.If you don't have any strong counter-arguments, I will perform it at the end of the week. I will announce here the affected repositories after the operation.Regards.
by Pedro M. Baeza - 06:11 - 29 Jul 2024 -
Re: ledger
Hello,The module account_asset_management is available in version 17 here:Regarding translations issues, first you need to find the module where the term to translate comes from (make sure it's an OCA module) and if something prevents you from translating them in Weblate, you can contact the email address showed on this page:I'm note sure if you are trying to change terms on a local database or in the OCA translation files related to OCA accounting modules, when reading your question. If it's the second option, what I just told you is relevant.Have a nice day,Le mer. 3 juil. 2024 à 11:55, Angel García-Junco Lora <notifications@odoo-community.org> a écrit :Dear colleages,we installed the accounting modules for the Ledgers,but when we try to lranaslate the ledger terms, General Ledger and Partner Ledger, these items arent don't translateSome one know what do we can to trabslate these terms of the Contabilidad Menu?Thanks in advanceEl 24/06/2024 20:14 CEST Angel García-Junco Lora <software@jlbberp.com> escribió:Dear Colleagues,
We try to install ledger in odoo comunity version 17, but the modules involved in it aren't compatible someone would know how, or if you could give us some indications, about compatibilize the module account_asset_management module, from v16 to v17?Thanks in advance
Best Regards,Angel Luis García-Junco Lora (Departamento de Software)SOFTWARE Y SERVICIOS TECNOLÓGICOS desde 1984Calle Democracia nº5 | San José de la Rinconada41300 LA RINCONADA ( ANDALUCÍA) - ESPAÑA Teléfono Centralita :(+34)955 085 361 Móvil Telegram y WhatsApp : (+34)601325581 Email:software@jlbberp.com NORMATIVA LEGAL DEL TRATAMIENTO DE LOS DATOS APLICABLE: EN RELACIÓN A LA APLICACIÓN DEL NUEVO REGLAMENTO (UE) 2016/679 DEL PARLAMENTO EUROPEO Y DEL CONSEJO, DE 27 DE ABRIL DE 2016, RELATIVO A LA PROTECCIÓN DE LAS PERSONAS FÍSICAS EN LO QUE RESPECTA AL TRATAMIENTO DE DATOS PERSONALES Y A LA LIBRE CIRCULACIÓN DE ESTOS DATOS, SE LE INFORMA Y CONSIENTE EXPRESAMENTE DE LOS SIGUIENTES EXTREMOS: "QUE, JOSE LUIS BAÑOS CONSULTING Y LA PLATAFORMA DE SERVICIOS TECNOLÓGICOS PMTK BUSINESS IN THE CLOUD, SON LOS RESPONSABLES DEL TRATAMIENTO DE SUS DATOS CON SEDE SOCIAL EN C/. DEMOCRACIA NÚM. 5 - SAN JOSE DE LA RINCONADA | 41300 LA RINCONADA ANDALUCIA ; CUYA FINALIDAD SE BASA EN UNA RELACIÓN CONTRACTUAL Y LEGAL Y, QUE LOS MISMOS, PUEDEN SER CEDIDOS A LOS SOLOS EFECTOS CONTRACTUALES; QUE LA EMPRESA LE BRINDA PODER EJERCR LOS DERECHOS A.R.C.O. Y OTROS (EL ACCESO A LOS DATOS PERSONALES RELATIVOS AL INTERESADO, Y SU RECTIFICACIÓN O SUPRESIÓN, O LA LIMITACIÓN DE SU TRATAMIENTO, O A OPONERSE AL TRATAMIENTO, ASÍ COMO EL DERECHO A LA PORTABILIDAD DE LOS DATOS); ANTE NUESTRO DELEGADO DE PROTECCIÓN DE DATOS, CUYO RESPONSABLE ES D. JOSÉ LUIS BAÑOS BELLIDO NIF 30412908P, TENIENDO COMO CANAL DE COMUNICACIÓN EL CORREO: CONSULTORIA@JLBBERP.COMAtentamente,Angel Luis García-Junco Lora (Departamento de Software)SOFTWARE Y SERVICIOS TECNOLÓGICOS desde 1984Calle Democracia nº5 | San José de la Rinconada41300 LA RINCONADA ( ANDALUCÍA) - ESPAÑA Teléfono Centralita :(+34)955 085 361 Móvil Telegram y WhatsApp : (+34)601325581 Email:software@jlbberp.com NORMATIVA LEGAL DEL TRATAMIENTO DE LOS DATOS APLICABLE: EN RELACIÓN A LA APLICACIÓN DEL NUEVO REGLAMENTO (UE) 2016/679 DEL PARLAMENTO EUROPEO Y DEL CONSEJO, DE 27 DE ABRIL DE 2016, RELATIVO A LA PROTECCIÓN DE LAS PERSONAS FÍSICAS EN LO QUE RESPECTA AL TRATAMIENTO DE DATOS PERSONALES Y A LA LIBRE CIRCULACIÓN DE ESTOS DATOS, SE LE INFORMA Y CONSIENTE EXPRESAMENTE DE LOS SIGUIENTES EXTREMOS: "QUE, JOSE LUIS BAÑOS CONSULTING Y LA PLATAFORMA DE SERVICIOS TECNOLÓGICOS PMTK BUSINESS IN THE CLOUD, SON LOS RESPONSABLES DEL TRATAMIENTO DE SUS DATOS CON SEDE SOCIAL EN C/. DEMOCRACIA NÚM. 5 - SAN JOSE DE LA RINCONADA | 41300 LA RINCONADA ANDALUCIA ; CUYA FINALIDAD SE BASA EN UNA RELACIÓN CONTRACTUAL Y LEGAL Y, QUE LOS MISMOS, PUEDEN SER CEDIDOS A LOS SOLOS EFECTOS CONTRACTUALES; QUE LA EMPRESA LE BRINDA PODER EJERCR LOS DERECHOS A.R.C.O. Y OTROS (EL ACCESO A LOS DATOS PERSONALES RELATIVOS AL INTERESADO, Y SU RECTIFICACIÓN O SUPRESIÓN, O LA LIMITACIÓN DE SU TRATAMIENTO, O A OPONERSE AL TRATAMIENTO, ASÍ COMO EL DERECHO A LA PORTABILIDAD DE LOS DATOS); ANTE NUESTRO DELEGADO DE PROTECCIÓN DE DATOS, CUYO RESPONSABLE ES D. JOSÉ LUIS BAÑOS BELLIDO NIF 30412908P, TENIENDO COMO CANAL DE COMUNICACIÓN EL CORREO: CONSULTORIA@JLBBERP.COM_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Virginie Dewulf - 12:15 - 26 Jul 2024 -
Re: Reflections on Odoo
Hi Jon,Thanks a lot for sharing this: wonderful to see the value the OCA brings to the Odoo world in your perspective.Hope to see you again in September/October for our OCA Days!Le jeu. 18 juil. 2024 à 12:19, Jon Baxter <notifications@odoo-community.org> a écrit :Hi there.I've put together some thoughts on software implementation and cost, using the experience of a council in the UK as an example. I make the point the exorbitant cost of the usual ERP solution providers has contributed to the failure and suggest (in a nutshell) to try Odoo.If you think it's worth commenting on or sharing, please do so.I hope it helps.ThanksJon
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Virginie Dewulf - 11:41 - 26 Jul 2024 -
Re: Mod 193 Odoo 14
There's no work planned for that model for now, so you can do it. Go to OCA/l10n-spain for more discussion about it.Regards.
by Pedro M. Baeza - 04:26 - 20 Jul 2024 -
Re: v18 early migration work based on master
Hi,Allowing a PR on a future version is a good way to go further.We are in august, and the new version is in October, then we don't have so much time to move,then the roadmap must be short I suppose.Le jeu. 18 juil. 2024 à 11:47, Stéphane Bidoul <notifications@odoo-community.org> a écrit :Hm, I don't have a good feeling with merging stuff that is not proven compatible with the real 18.0, that's going to be confusing.Also, all the dependency management relies on merged stuff being available on PyPI.But that can still be considered in a second step when we have learned to fly with unmerged PRs first.-sbiOn Thu, Jul 18, 2024 at 11:23 AM Simone Orsi <simahawk@gmail.com> wrote:Thanks everybody for the feedback :)@Stéphane Bidoul regardingI'd also suggest not merging nor pushing to PyPI until the Odoo 18.0 branch has been created, so work only with git PR references in test-requirements.txt for dependencies.
So we'd probably need to add protections in the bot to avoid premature merges or pushes to PyPI
I agree on not pushing to PyPI but we should merge, to not enter a valley of pain later.IMO the version of the module should serve as the way to check if it is fully migrated or not and we could update the repo readme generation to make it more visible, same for the module's readme. Maybe a ribbon?We could also add a non blocking warning test in the CI.WDYT?On Tue, Jul 16, 2024 at 3:27 PM Mignon, Laurent <notifications@odoo-community.org> wrote:> I'd go for branch opt 3 + mod version opt 2.+1On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:I think this could be nice. I would favor Option 2 for branch naming. This could be an indicator for the OCAbot to behave differently about the version numbers when a PR s merged (and we can have option 1 for module version). Alexandre On 01/07/2024 12:42, Simone Orsi wrote: > Hi everybody, > > We would like to start working on migrating some base modules to v18 > before it gets released. > > AFAIR there's no "official" policy for it, if not "do it on your own > fork and then open PRs when the release is out". > > From my POV it would be nice to define one. > > For the branch, I see these options: > > 1. add a `master` branch that can be used w/ any version > 2. add a `$nextVersion-[master|dev]` branch that can be used w/ odoo > master for a specific version > 3. simply have $nextVersion branch and stick to version policy nr 2 (see > below) > > For the module version: > > 1. append `dev`to the version (eg: 18.0.1.0.0dev) > 2. start w/ a number lesser than 1.0.0 and switch to 1.0.0 only when the > release is out (eg: 18.0.0.0.1) > > I'd go for branch opt 3 + mod version opt 2. > > For the test suite: I'm not sure we have a way to run tests against > master ATM. > > Am I missing something? > > In general, what do you think? > > -- > Simone Orsi > > Full stack Python web developer, Odoo specialist, Odoo Community Board > Member, in love with open source. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > <https://odoo-community.org/groups/contributors-15> > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe > <https://odoo-community.org/groups?unsubscribe> > -- Alexandre Fayolle Senior Software Engineer Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
_______________________________________________
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
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source._______________________________________________
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 BEAL - 03:01 - 18 Jul 2024
