Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

  • migration from 16.0 to 17.0
    When I tried to pull a request for a module that I have upgraded and my customer uses it I got 3 errors by the bot.

    Here is the pull request:
    https://github.com/OCA/product-attribute/pull/1700

    The module is:
    product_pricelist_fixed_currency_rate

    Please help me to make it successful, thanks.
    by Mohamed Alkobrosly - 01:17 - 6 Aug 2024
  • Bug Report
    Hi Team,
    I hope you are well.

    I would like to share another vulnerability of your website

    Vulnerability 1: Non - secure requests are not automatically upgraded to HTTPS | HSTS missing

    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.


    Steps to Reproduce:
    2) enter your domain

    References
    HTTP Strict Transport Security
    sslstrip
    HSTS Preload Form

    Impact:
    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 enforced


    Issue 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.
    image.png
    by "Jenny Rose" <infosec.jenny@gmail.com> - 07:11 - 1 Aug 2024

    1 attachments 1 attachments

    image.png
  • 🎫 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
  • 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

    3 replies 3 replies

    • 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 done


      Kind 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 Alomar
      CEO & Founder

      by Enric Tobella Alomar - 11:57 - 31 Jul 2024
    • Re: Activating tab on form from code?

      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

      by "Ronald Portier" <rportier@therp.nl> - 10:26 - 31 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

    (being origin the 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

    17 replies 17 replies

    • Re: pandoc-*.deb cleaning in OCA repositories

      pre-commit has a check to avoid merging big files


      IMHO we should enable/configure it in order to avoid a similar discussion about in the future
      by Moisés López Calderón - 04:11 - 7 Aug 2024
    • Re: pandoc-*.deb cleaning in OCA repositories
      OK, I desist. I think we are being a bit selfish, but OK, I have a lot of things to fight for.

      Regards.
      by Pedro M. Baeza - 03:41 - 7 Aug 2024
    • Re: pandoc-*.deb cleaning in OCA repositories
      Exactly. We should be able to come up with an additional git filter to keep the files out of the future series branches.

      Please consider leaving the branches as they are. It will break all setups that have forks of OCA modules included as submodules. On many Odoo.sh projects, this is the preferred way of working and typically these forks contain forward merges of pending PRs. The proposed rebase of the series branches would require a reconstruction from scratch of the corresponding branches on these forks.

      Cheers,
      Stefan

      On 07-08-2024 13:38, Jairo Llopis wrote:
      El lun,  5 de ago de 2024 a las 12:42:29 P. M., Adam Heinz <notifications@odoo-community.org> escribió:
      Add a note to the migration documentation to delete the large files commit?

      Yeah, probably you can just exclude .deb files in the format-patch or am commands.

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



      -- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail: stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web: https://opener.amsterdam
      by "Stefan Rijnhart" <stefan@opener.amsterdam> - 03:15 - 7 Aug 2024
    • Re: pandoc-*.deb cleaning in OCA repositories
      El lun,  5 de ago de 2024 a las 12:42:29 P. M., Adam Heinz <notifications@odoo-community.org> escribió:
      Add a note to the migration documentation to delete the large files commit?

      Yeah, probably you can just exclude .deb files in the format-patch or am commands.
      by Jairo Llopis - 01:36 - 7 Aug 2024
    • Re: pandoc-*.deb cleaning in OCA repositories
      Add a note to the migration documentation to delete the large files commit? There is already a process to merge translation commits together during migration and this seems like a similar amount of difficulty.

      On Mon, Aug 5, 2024 at 8:32 AM Enric Tobella Alomar <notifications@odoo-community.org> wrote:
      The problem is that this files and changes will be imported on future migration PRs on future branches (some files are inside the module folder). This is a decision that will impact the future of all OCA users. So this is something that will not disappear with time. Letting it go because we think it will disappear is a mistake.

      Change nothing is the easiest choice but we all know that this will not disappear and is a bad choice. We also are discussing this, but I think that there is not so many repositories affected.

      On Mon, 5 Aug 2024, 12:17 Jairo Llopis, <notifications@odoo-community.org> wrote:
      El vie,  2 de ago de 2024 a las 12:52:18 P. M., Enric Tobella Alomar <notifications@odoo-community.org> escribió:
      I think the benefits are bigger than the cons

      I think the opposite.

      Benefits:
      1. Save disk space in case you're either not cloning with --depth 1, or you're going to do a git gc after all the manual work that will mean updating all your local clones.
      2. Save bandwith space under similar conditions.
      Potential problems:
      1. Break your lock files.
      2. Need to rebase almost every open PR against those branches.
      3. Inclusion of unwanted commits (that include those wonderful 30MB files) in more PRs.
      4. Disturbing many developers.
      5. Making oca-port unable to detect relationship between commits and PRs.
      6. Manual work involving the repo admins and almost all OCA developers.
      7. Things I don't imagine right now.
      Definitely not worth it. One day we'll stop using those branches (hopefully in about 3-5 years) and we won't care about those few extra MBs.

      _______________________________________________
      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 Adam Heinz - 02:41 - 5 Aug 2024

  • Reflections on Odoo
    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.

    Thanks
    Jon
    by Baxter Thompson Ltd - 12:16 - 18 Jul 2024

    2 replies 2 replies

  • Mod 193 Odoo 14

    Dear Contributors,

    I hope this message finds you well. I am writing to inquire about the availability of an Odoo module that can generate the model 193 for Spanish tax declaration,This model corresponds to the annual declaration of model 123 that is implemented.

    If there is no existing module, perhaps we can implement it based on the other models

    Thank you very much for your assistance.

    Best regards,

     

     

    Atentamente

     

    David Cuellas González

    Coordinador de Software y Desarrollo

    signature_1231745893 

    C/ Rosalía de Castro N17, Puerta1 Entresuelo

    36201 Vigo Pontevedra

    Tel.: 886138703

    Fax: 886137958

    Móvil 678206430

    david.cuellas@aureatic.com

    aureatic.com

     

    Antes de imprimir este correo electrónico piense bien si es necesario hacerlo: El medioambiente es cosa de todos.

    signature_463663753

    Los datos incluidos en esta comunicación forman parte de los ficheros de AUREATIC, S.L.L con domicilio en C/ Rosalía de Castro N17 Puerta 1, 36201 de Vigo (Pontevedra) y serán tratados con la finalidad llevar a cabo la gestión de contactos de la empresa, la comunicación con terceros y el envío de información sobre nuestros servicios a través de medios electrónicos. Los interesados podrán ejercitar los derechos de acceso, rectificación, cancelación, revocación y oposición, incluso respecto a la recepción de comunicaciones comerciales, en la dirección lopd@aureatic.com. La información contenida en este correo electrónico tiene carácter confidencial y podrá ser utilizada y visualizada únicamente por el (los) destinatario (s). En caso de haber recibido este correo electrónico por error, deberá proceder a su inmediata destrucción sin hacer uso de la información en él contenida.

     

    Los principios que orientan a la Economía Social en España son:

    Primacía de las personas y del fin social sobre el capital, que se concreta en gestión autónoma y transparente, democrática y participativa, que lleva a priorizar la toma de decisiones más en función de las personas y sus aportaciones de trabajo y servicios prestados a la entidad o en función del fin social, que en relación a sus aportaciones al capital social. - Aplicación de los resultados obtenidos de la actividad económica principalmente en función del trabajo aportado y servicio o actividad realizada por las socias y socios o por sus miembros y, en su caso, al fin social objeto de la entidad.- Promoción de la solidaridad interna y con la sociedad que favorezca el compromiso con el desarrollo local, la igualdad de oportunidades entre hombres y mujeres, la cohesión social, la inserción de personas en riesgo de exclusión social, la generación de empleo estable y de calidad, la conciliación de la vida personal, familiar y laboral y la sostenibilidad.- Independencia respecto a los poderes públicos.

     

     

     

     

    by David Cuellas - 11:01 - 17 Jul 2024

    1 replies 1 replies

    • 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
  • Specific Identification Inventory Valuation Method
    Dear OCA Community,

    Is anyone aware of an OCA module that implements "Specific Identification Inventory Valuation Method"?  If the OCA were interested in adopting such a module, to which project or repository would it be assigned?

    I will soon start work on a 16.0 module to implement the new costing method. Simple FIFO does not work for my business.  The situation is explained somewhat in the following posts:


    Matt

    by Matt - 07:41 - 15 Jul 2024

    2 replies 2 replies

  • Next OCA Live Session This Week - Tuesday 16th July
    Hello OCA Contributors.

    I hope this finds you all well.

    I just wanted to share that our next OCA Live Session happens this week.

    Screen Shot 2024-07-04 at 8.58.34 PM.png
    Tuesday 16th July at 8pm CEST/ 6pm UTC here: https://meet.google.com/dio-otmm-trk We want to be available to anyone interested or involved in the OCA who has questions or needs help on any OCA-related topic, once a month during a live open session. Anyone is welcome, any profile, any level of knowledge about the OCA. 

    Take this opportunity to give us feedback on what you need from us, to understand what the OCA can help you with and what you can do for the OCA to thrive!

    No need to register - just join the meeting.

    Have a great week,
    Rebecca

    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly (OCA) - 07:21 - 15 Jul 2024

    1 attachments 1 attachments

    Screen Shot 2024-07-04 at 8.58.34 PM.png
  • POS payment terminal
    Dear community,

    I was asked for POS payment terminal module for version 17.

    I am a developer, I can upgrade and push it into the GitHub repository, but if someone already did that I can test what he made.

    Please let me know if someone has tried before to save my time.

    thanks very much
    by Mohamed Alkobrosly - 01:46 - 13 Jul 2024

    1 replies 1 replies

    • Re: POS payment terminal
      It’s not claimed yet. So I guess you should grab it. 
      Von: mohamed alkobrosly <notifications@odoo-community.org>
      Gesendet: Saturday, July 13, 2024 1:47:23 PM
      An: Contributors <contributors@odoo-community.org>
      Betreff: POS payment terminal
       

      ACHTUNG! Diese E-Mail stammt von außerhalb der Organisation. Klicken Sie nicht auf Links und öffnen Sie keine Anhänge, es sei denn, Sie kennen den Absender und wissen, dass der Inhalt sicher ist.

      Dear community,

      I was asked for POS payment terminal module for version 17.

      I am a developer, I can upgrade and push it into the GitHub repository, but if someone already did that I can test what he made.

      Please let me know if someone has tried before to save my time.

      thanks very much

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

      by Nils Coenen - 01:55 - 13 Jul 2024
  • Request for Review and Approval - OCA Commit

    Dear OCA Core Maintainers,

    I hope this message finds you well.

    I have submitted a pull request to the OCA/web repository and would appreciate your review and approval. The details of the pull request are as follows:

    Pull Request URL: https://github.com/OCA/web/pull/2864

    Please let me know if there are any changes or additional information required.

    Thank you for your time and assistance.

    Best regards,
    Angel Patel

    by angel@rooteam.net - 04:51 - 12 Jul 2024
  • Purchase order line delivery state
    Hi, 

    did someone ever developed the purchase order line counterpart for sale_order_line_delivery_state ? In Odoo14 or very similar versions. Didn't find it in OCA repos.

    Thanks,
    Francesco Ballerini
    by Francesco Ballerini - 11:56 - 10 Jul 2024

    3 replies 3 replies

  • Weblate updated to v5 
    Dear OCA community,

For information, I have just completed upgrade of OCA Weblate platform 
from 4.17 to 5.0.2.

I have tested a couple of things successfully, however I am not able to 
test that it behaves correctly for creating new modules when merged in 
any repo.


Also, I wanted to migrate to latest version (5.6.2) but got an issue 
with packaging of some scripts that we have developped to update 
automatically projects / components, so I had to postpone this upgrade 
to latest version for now.

Please come back to me in case you find new issues with the updated 
version !

Best Regards,


-- 
Rémi
    by Rémi Cazenave - 02:26 - 6 Jul 2024

    7 replies 7 replies

    • Re: Weblate updated to v5
      Yea it works!
      Thanks Rémi and Stéphane for all the great work!

      Da "Rémi CAZENAVE - Le Filament" notifications@odoo-community.org
      A "Contributors" contributors@odoo-community.org
      Cc
      Data Mon, 08 Jul 2024 08:17:42 -0000
      Oggetto Re: Weblate updated to v5

      I see the module was merged about 1h ago.

Cron is running every 4 hours on Weblate server to add 
project/components. Next time should be at 10:00 UTC (12:00 CEST), so in 
about 2 hours we should check if component pingen_env was properly 
created in 
https://translation.odoo-community.org/projects/report-print-send-16-0/

I have also seen that Stéphane has fixed a few things in the cron 
yesterday, thanks for that Stéphane !

Best regards,

Rémi


Le 08/07/2024 à 08:57, Pedro M. Baeza a écrit :

> When this module gets merged can be a good occasion to check if it works:

>

> https://github.com/OCA/report-print-send/pull/327

>

> 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



      Stefano Consolaro
      www.mymage.it
      by Stefano Consolaro - 02:21 - 8 Jul 2024
    • Re: Weblate updated to v5 
      I see the module was merged about 1h ago.

Cron is running every 4 hours on Weblate server to add 
project/components. Next time should be at 10:00 UTC (12:00 CEST), so in 
about 2 hours we should check if component pingen_env was properly 
created in 
https://translation.odoo-community.org/projects/report-print-send-16-0/

I have also seen that Stéphane has fixed a few things in the cron 
yesterday, thanks for that Stéphane !

Best regards,

Rémi


Le 08/07/2024 à 08:57, Pedro M. Baeza a écrit :

> When this module gets merged can be a good occasion to check if it works:

>

> https://github.com/OCA/report-print-send/pull/327

>

> 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 Rémi Cazenave - 10:16 - 8 Jul 2024
    • Re: Weblate updated to v5
      When this module gets merged can be a good occasion to check if it works:


      Regards.
      by Pedro M. Baeza - 08:56 - 8 Jul 2024
    • Re: Weblate updated to v5
      Thanks a lot, Rémi!

      Le sam. 6 juil. 2024, 15:22, Rémi CAZENAVE - Le Filament <notifications@odoo-community.org> a écrit :
      I see I am not the only one working on week-ends :)

I think we have to wait for new modules to be added in existing repos 
(or new repos to be created) and then check that these are properly 
created in Weblate as well !

Thanks to help from Stéphane, I solved also the problem I had for 
migrating to latest version, so Weblate is now up to date in version 5.6.2.

Best Regards,

Le 06/07/2024 à 14:37, Pedro M. Baeza a écrit :


> Thanks for the work!


>


> How can we test the option you are commenting on?


>


> 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

      by Virginie Dewulf (OCA) - 07:51 - 6 Jul 2024
    • Re: Weblate updated to v5 
      I see I am not the only one working on week-ends :)

I think we have to wait for new modules to be added in existing repos 
(or new repos to be created) and then check that these are properly 
created in Weblate as well !

Thanks to help from Stéphane, I solved also the problem I had for 
migrating to latest version, so Weblate is now up to date in version 5.6.2.

Best Regards,

Le 06/07/2024 à 14:37, Pedro M. Baeza a écrit :

> Thanks for the work!

>

> How can we test the option you are commenting on?

>

> 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 Rémi Cazenave - 03:21 - 6 Jul 2024

  • spreadsheet_dashboard_oca's module: Is printing process available?
    Hi everyone,

    I currently use spreadsheet_dashboard_oca v16, which works well. However, I need to print (as PDF report) the content of  a spreadsheet.dashboard. Doesn't seem to be available with the current version of the module that I use.

    Did I miss something? Or is there another way (combination with an existing module, library) to realise that?

    Thanks in advance for your answer,




    --
    SMILE

    7 Boulevard Louis XIV 59800 Lille
    Laurent WEBER
    Développeur


    Twitter Facebook LinkedIn Github


    eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
    by Laurent Weber - 03:36 - 5 Jul 2024

    2 replies 2 replies

  • Bank sync for Societe Generale (France)
    Hello,

    I hope this is not inappropriate for this list.

    I'm seeking for help on configuring the bank sync for Societe Generale.
    I see Saltedge support EBICS connection (with Odoo Enterprise Edition).

    But I'm being asked what format should be used for the bank statement:
    - CFONB 120
    - Swift MT 940
    - camt.053.001.02

    Anyone has gone though this before?

    Thank you!

    --
    DANIEL REIS
    MANAGING PARTNER

    Meet with me.
    M: +351 919 991 307
    E: dreis@OpenSourceIntegrators.com
    A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

    [Logo OpenSourceIntegrators.com]

    by Daniel Reis - 10:35 - 5 Jul 2024

    6 replies 6 replies

  • New repo web-api-contrib
    Hi all,

    I'm proposing the creation of a new repo.


    Bests

    --
    Simone Orsi

    Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
    by Simone Orsi. - 08:51 - 4 Jul 2024

    2 replies 2 replies

    • Re: New repo web-api-contrib 
      +1 too

On 04/07/2024 08:57, Simone Orsi wrote:

> Hi all,

> 

> I'm proposing the creation of a new repo.

> 

> Please check https://github.com/OCA/repo-maintainer-conf/pull/27 

> <https://github.com/OCA/repo-maintainer-conf/pull/27>

> 

> Bests

> 

> -- 

> 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
      by Alexandre Fayolle - 02:43 - 16 Jul 2024
    • Re: New repo web-api-contrib
      It makes sense: +1

      On Thu, Jul 4, 2024 at 8:57 AM Simone Orsi <notifications@odoo-community.org> wrote:
      Hi all,

      I'm proposing the creation of a new repo.


      Bests

      --
      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
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      by Laurent Mignon - 12:36 - 4 Jul 2024
  • ODOO Update versions V.15 to V.17 - Historical data.

    Hello everyone.

     

    I am doing an upgrade project from version 15 to 17, I am not going to migrate historical data, I will leave the historical data in version 15, up to the date of Go Live, and, in version 17 I will start with initial balances and operations from scratch , example: New Purchase Orders, New customer orders, etc.

     

    My questions are: Is there a way to extract information from data that I will leave in version 15, for example: historical sales data, processed purchase orders, historical inventory data, etc.? Is there a connector or application for I can use Power BI to manage this data and be able to do reports, demand analysis, inventory analysis, etc.?

     

    Thank you all in advance for your comments and recommendations.

     

    Regards.

     

    HF

    by Hugo Ferrer - 11:40 - 3 Jul 2024

    3 replies 3 replies

    • Re: ODOO Update versions V.15 to V.17 - Historical data.
      On the contrary, I give more value to old data, and more with all the generative AIs coming. In this case, migrating the instance to v17 with OpenUpgrade (not yet there, but you can wait a bit or do a progressive migration - we do it constantly on our customers -) is the best strategy IMO.

      I introduce another factor on your previous suggestion: you have to maintain the old system. Apart from keeping the resources used by this system, their foundation software, libraries, etc should be also kept, and this is more and more a burden as times pass by. And even worse, both the foundation and the old Odoo version become vulnerable, as they are not updated by their manufacturers at any point, so you have an attack surface that is also a concern due to the RGPD.

      Regards.
      by Pedro M. Baeza - 09:01 - 4 Jul 2024
    • Re: ODOO Update versions V.15 to V.17 - Historical data.

      Hi Hugo,

      i agree with that Graeme said. In most cases where we had such challenges we simply decided to keep a version of the old system running (with the data of the last day in productive use and reset to that every night if necessary). This has 2 advantages

      1.) This is the cheapest approach that you can probably take (at the jost of manually logging on to an old system in the case its needed)

      2.) It literally shows you (either obvserved or measured by monitoring) how infrequently this system is being used.

      Any kind of integration just makes a system more complex and doesn't render the base of decision making better imho

      Best Frederik

      Am 04.07.24 um 00:19 schrieb Graeme Gellatly:
      Not for less than the cost of just migrating the historical data in the first place IMO if it is Odoo. Other historical systems, sometimes (most times) the cost isn't worth it.

      Indeed I have one project like that. A v7 instance still running after nearly 14 years plus 8 historical systems still after 25 years. One of the dumber things I agreed to.

      Any connector I'd do at database level. Most people that use Power BI, Jasper, Crystal or any reporting tools do at db level.

      In any case, consider that the historical data is immutable and devalues quickly. You can probably just produce the historical summary reports / flat tables you need and stick them in tables/views in whatever software you want including Odoo. Maybe override some reports to add Unions on the historical. In fact that is something I'm considering even for instances where all the data is migrated, it sucks waiting minutes for reports when 90% of the information is aggregations of historical data that will never change.



      On Thu, Jul 4, 2024 at 9:42 AM hugo.ferrer <notifications@odoo-community.org> wrote:

      Hello everyone.

       

      I am doing an upgrade project from version 15 to 17, I am not going to migrate historical data, I will leave the historical data in version 15, up to the date of Go Live, and, in version 17 I will start with initial balances and operations from scratch , example: New Purchase Orders, New customer orders, etc.

       

      My questions are: Is there a way to extract information from data that I will leave in version 15, for example: historical sales data, processed purchase orders, historical inventory data, etc.? Is there a connector or application for I can use Power BI to manage this data and be able to do reports, demand analysis, inventory analysis, etc.?

       

      Thank you all in advance for your comments and recommendations.

       

      Regards.

       

      HF

      _______________________________________________
      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

      -- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247
      by Frederik Kramer. - 08:36 - 4 Jul 2024
    • Re: ODOO Update versions V.15 to V.17 - Historical data.
      Not for less than the cost of just migrating the historical data in the first place IMO if it is Odoo. Other historical systems, sometimes (most times) the cost isn't worth it.

      Indeed I have one project like that. A v7 instance still running after nearly 14 years plus 8 historical systems still after 25 years. One of the dumber things I agreed to.

      Any connector I'd do at database level. Most people that use Power BI, Jasper, Crystal or any reporting tools do at db level.

      In any case, consider that the historical data is immutable and devalues quickly. You can probably just produce the historical summary reports / flat tables you need and stick them in tables/views in whatever software you want including Odoo. Maybe override some reports to add Unions on the historical. In fact that is something I'm considering even for instances where all the data is migrated, it sucks waiting minutes for reports when 90% of the information is aggregations of historical data that will never change.



      On Thu, Jul 4, 2024 at 9:42 AM hugo.ferrer <notifications@odoo-community.org> wrote:

      Hello everyone.

       

      I am doing an upgrade project from version 15 to 17, I am not going to migrate historical data, I will leave the historical data in version 15, up to the date of Go Live, and, in version 17 I will start with initial balances and operations from scratch , example: New Purchase Orders, New customer orders, etc.

       

      My questions are: Is there a way to extract information from data that I will leave in version 15, for example: historical sales data, processed purchase orders, historical inventory data, etc.? Is there a connector or application for I can use Power BI to manage this data and be able to do reports, demand analysis, inventory analysis, etc.?

       

      Thank you all in advance for your comments and recommendations.

       

      Regards.

       

      HF

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

      by "Graeme Gellatly" <graeme@moahub.nz> - 12:18 - 4 Jul 2024
  • Odoo Community 17 issues

    Good morning,

    I hope you are doing great.

     

    We are starting to work with the Odoo Community platform and we have some situations, such as not being able to delete companies that we created in the system.

    Validation Error

    The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

    Model: Picking Type (stock.picking.type)

    Constraint: stock_picking_type_company_id_fkey

     

    Another situation is that one of our employees, when clearing the browser cache, was deleted from the system and was unable to log in again, not even through a new invitation.

     

    I would love to hear from you if there are any solutions for the correct configuration and operation of the Odoo Community 17 system?

    I hope I hear from you soon.

    Thanks in advance!

    Best regards,

     

     

     

    by Dan Vasques - 09:56 - 2 Jul 2024

    7 attachments 7 attachments

    image007.gif
    image006.png
    image005.png
    image004.png
    image003.png
    image002.png
    image001.gif

    4 replies 4 replies

    • RE: Odoo Community 17 issues

      Dear,

       

      When you archived the partners, they stay in your res.partner table as a record. When there is a field with a ‘unique’ constraint, you cannot create another record with the same field value. When this field is not a relational field ( = not a link to another table ), the easiest way is to simply go in the database with pgadmin and change the field in the archived record in for example ‘value_old’. That’s fast and do the trick. Of course, maybe your field don’t need to be ‘unique’. Than you can build a small module and remove the constraint from the field.

       

      Kind regards,

       

      Van Hirtum Johan

       

      Van: Dan Vasques [mailto:notifications@odoo-community.org]
      Verzonden: dinsdag 2 juli 2024 13:57
      Aan: Contributors
      Onderwerp: R      E: Odoo Community 17 issues

       

      Hi everyone,

      I´ve archived the companies but when I try to add a new one, it keeps refusing. It comes up with the notification that it has to have a unique name.
      I believe that it has something to do with the previous ones that were deleted, as they have the same name.
      So, is there a way to really delete the archived ones?

      Thanks in advance for the assistance!

      Dan Vasques

       

      De: Tom Blauwendraat <notifications@odoo-community.org>
      Enviada: 2 de julho de 2024 09:09
      Para: Contributors <contributors@odoo-community.org>
      Assunto: Re: Odoo Community 17 issues

       

      Hi Dan,

      this is normal; deletion of records is tricky if there are already references to it. Archiving would be the best option here.

      This is the same in Odoo Enterprise, btw (Enterprise runs on the same core modules)

      -Tom

      On 7/2/24 09:57, Dan Vasques wrote:

      Good morning,

      I hope you are doing great.

       

      We are starting to work with the Odoo Community platform and we have some situations, such as not being able to delete companies that we created in the system.

      Validation Error

      The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

      Model: Picking Type (stock.picking.type)

      Constraint: stock_picking_type_company_id_fkey

       

      Another situation is that one of our employees, when clearing the browser cache, was deleted from the system and was unable to log in again, not even through a new invitation.

       

      I would love to hear from you if there are any solutions for the correct configuration and operation of the Odoo Community 17 system?

      I hope I hear from you soon.

      Thanks in advance!

      Best 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 johan - 02:15 - 2 Jul 2024
    • RE: Odoo Community 17 issues

      Hi everyone,

      I´ve archived the companies but when I try to add a new one, it keeps refusing. It comes up with the notification that it has to have a unique name.
      I believe that it has something to do with the previous ones that were deleted, as they have the same name.
      So, is there a way to really delete the archived ones?

      Thanks in advance for the assistance!

      Dan Vasques

       

      De: Tom Blauwendraat <notifications@odoo-community.org>
      Enviada: 2 de julho de 2024 09:09
      Para: Contributors <contributors@odoo-community.org>
      Assunto: Re: Odoo Community 17 issues

       

      Hi Dan,

      this is normal; deletion of records is tricky if there are already references to it. Archiving would be the best option here.

      This is the same in Odoo Enterprise, btw (Enterprise runs on the same core modules)

      -Tom

      On 7/2/24 09:57, Dan Vasques wrote:

      Good morning,

      I hope you are doing great.

       

      We are starting to work with the Odoo Community platform and we have some situations, such as not being able to delete companies that we created in the system.

      Validation Error

      The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

      Model: Picking Type (stock.picking.type)

      Constraint: stock_picking_type_company_id_fkey

       

      Another situation is that one of our employees, when clearing the browser cache, was deleted from the system and was unable to log in again, not even through a new invitation.

       

      I would love to hear from you if there are any solutions for the correct configuration and operation of the Odoo Community 17 system?

      I hope I hear from you soon.

      Thanks in advance!

      Best regards,

       

       

       

      by Dan Vasques - 01:56 - 2 Jul 2024
    • RE: Odoo Community 17 issues

      Hi Tom,

      Thank you so much for the quick response.
      I really appreciate your assistance.

       

      Kind regards,

       

       

       

      De: Tom Blauwendraat <notifications@odoo-community.org>
      Enviada: 2 de julho de 2024 09:09
      Para: Contributors <contributors@odoo-community.org>
      Assunto: Re: Odoo Community 17 issues

       

      Hi Dan,

      this is normal; deletion of records is tricky if there are already references to it. Archiving would be the best option here.

      This is the same in Odoo Enterprise, btw (Enterprise runs on the same core modules)

      -Tom

      On 7/2/24 09:57, Dan Vasques wrote:

      Good morning,

      I hope you are doing great.

       

      We are starting to work with the Odoo Community platform and we have some situations, such as not being able to delete companies that we created in the system.

      Validation Error

      The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

      Model: Picking Type (stock.picking.type)

      Constraint: stock_picking_type_company_id_fkey

       

      Another situation is that one of our employees, when clearing the browser cache, was deleted from the system and was unable to log in again, not even through a new invitation.

       

      I would love to hear from you if there are any solutions for the correct configuration and operation of the Odoo Community 17 system?

      I hope I hear from you soon.

      Thanks in advance!

      Best regards,

       

       

       

      by Dan Vasques - 10:31 - 2 Jul 2024

      7 attachments 7 attachments

      image007.gif
      image006.png
      image005.png
      image004.png
      image003.png
      image002.png
      image001.gif
    • Re: Odoo Community 17 issues

      Hi Dan,

      this is normal; deletion of records is tricky if there are already references to it. Archiving would be the best option here.

      This is the same in Odoo Enterprise, btw (Enterprise runs on the same core modules)

      -Tom

      On 7/2/24 09:57, Dan Vasques wrote:

      Good morning,

      I hope you are doing great.

       

      We are starting to work with the Odoo Community platform and we have some situations, such as not being able to delete companies that we created in the system.

      Validation Error

      The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

      Model: Picking Type (stock.picking.type)

      Constraint: stock_picking_type_company_id_fkey

       

      Another situation is that one of our employees, when clearing the browser cache, was deleted from the system and was unable to log in again, not even through a new invitation.

       

      I would love to hear from you if there are any solutions for the correct configuration and operation of the Odoo Community 17 system?

      I hope I hear from you soon.

      Thanks in advance!

      Best 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 Tom Blauwendraat - 10:02 - 2 Jul 2024
  • v18 early migration work based on master
    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.
    by Simone Orsi. - 12:41 - 1 Jul 2024

    9 replies 9 replies

    • Re: Re: v18 early migration work based on master 
      Hallo liebe Leute,

Unser Büro ist in der Zeit vom Mo., 5. August bis Mo. 13. August nicht besetzt.

Sobald wir zurück sind, melden wir uns sobald als möglich zurück.

Liebe Grüße und schöne Sommerferien,

Das Team von it-fact

Am 18.07.2024 um 15:02 schrieb David Beal <notifications@odoo-community.org>:


> 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.

> 

> Regards

> 

> David BEAL

> Akretion

> Consultant ERP Odoo

> 

> 

> 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.

> 

> -sbi

> 

> On Thu, Jul 18, 2024 at 11:23 AM Simone Orsi <simahawk@gmail.com> wrote:

> Thanks everybody for the feedback :)

> 

> @Stéphane Bidoul regarding

> 

> I'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.

> 

> +1

> 

> On 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 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
> 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 Andreas Maurhart - 08:06 - 5 Aug 2024

      1 attachments 1 attachments

      attachment
    • 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.

      Regards

      David BEAL
      Consultant ERP Odoo


      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.

      -sbi

      On Thu, Jul 18, 2024 at 11:23 AM Simone Orsi <simahawk@gmail.com> wrote:
      Thanks everybody for the feedback :)


      I'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.

      +1

      On 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 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
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      by David BEAL - 03:01 - 18 Jul 2024
    • Re: v18 early migration work based on master
      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.

      -sbi

      On Thu, Jul 18, 2024 at 11:23 AM Simone Orsi <simahawk@gmail.com> wrote:
      Thanks everybody for the feedback :)


      I'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.

      +1

      On 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 Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
      by Stéphane Bidoul - 11:46 - 18 Jul 2024
    • Re: v18 early migration work based on master
      Thanks everybody for the feedback :)


      I'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.

      +1

      On 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 Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
      by Simone Orsi. - 11:25 - 18 Jul 2024
    • Re: v18 early migration work based on master
      >  I'd go for branch opt 3 + mod version opt 2.

      +1

      On 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

      by Laurent Mignon - 03:26 - 16 Jul 2024

  • Sensitive information fields - controlled access, encryption, display, ...

    Hello,


    I am dealing with a scenario where some personal data needs to be handled in a special way. Unprivileged users should not see them at all or only see their encrypted/hashed/garbled versions. Privileged users should have a way to display the data ideally after some additional step which would be logged. Ideally the sensitive data should be encrypted at database level.


    Has anyone has similar requirements? Is there any module providing foundation / ideas for such thing? Setup of employee classes (hr.employee, hr.employee.base and hr.employee.public) and groups seems could be somewhat an inspiration to this.


    Any ideas / pointers are welcome. Thank you very much.


    Best regards


        Radovan Skolnik

    by Radovan Skolnik - 11:46 - 1 Jul 2024

    1 replies 1 replies