Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • Re: V14, python version
    Hi Stephan,

    Python 3.6 is supported until end 2021.

    Imagine you have to migrate a very very complex project to v14.0. Planification learn us migration date will be on December 2021

    Then If you align your project on the same version as OCA to have the best reproducibility, you use a version which is unsupported the day you go in production. Probably it's suboptimal and it can be really risky to explicit that to your customer.

    I understand the idea to protect projects using python 3.6. But here again, it's suboptimal to begin implementing a project with lower performance than last very stable. Maybe it could be considered as bad practice by OCA ! ?  A warning could be logged in this case.
    For odoo sh users, I don't know if it's possible to choose python version or if the default is or not 3.8.
    But if Odoo customers asked for Odoo SA to allow them to choose 3.8 to ensure OCA modules as better fit, there is no reason in the interest of the customer to refuse it.

    Regards


    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement


    Le mer. 14 oct. 2020 à 10:47, Stéphane Bidoul <stephane.bidoul@acsone.eu> a écrit :
    I think OCA CI must run with the same python version as the oldest supported by Odoo.
    If we test, say with python 3.8, people installing OCA modules on otherwise Odoo supported python versions may face compatibility issues.
    In the other direction, compatibility issues will be much much less frequent, python being pretty good at ensuring backward compatibility.

    Python 3.6 is supported until end 2021.

    But we may want to clarify if what Odoo says in setup.py is correct. I don't know what python version Odoo uses on their runbot for instance.

    -sbi


    On Wed, Oct 14, 2020 at 10:07 AM David Beal <david.beal@akretion.com> wrote:
    Ok I haven't seen that before, thanks.

    The problem to begin with an old version is that even for recent projects, 12.0, you get bad signal only after 2 year.

    DEPRECATION: Python 3.5 reached the end of its life on September 13th, 2020. Please upgrade your Python as Python 3.5 is no longer maintained. pip 21.0 will drop support for Python 3.5 in January 2021. pip 21.0 will remove support for this functionality.

    I don't think it is a good thing for my customer to early have a deprecated python version.
    I suppose that the better way to avoid it is to have a recent python version used on OCA CI and then in our project whatever Odoo SA python policy version.

    Bonne journée


    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement


    Le mer. 14 oct. 2020 à 09:42, Stéphane Bidoul <stephane.bidoul@acsone.eu> a écrit :
    I've not looked into the cases you mentioned yet, but I note Odoo declares itself as supporting python 3.6:

    That's why the OCA 14.0 branches have been created for python 3.6 too.

    -sbi

    On Wed, Oct 14, 2020 at 9:27 AM David Beal <david.beal@akretion.com> wrote:
    Hi all,

    The last very stable python is 3.8 (first version in November 2019), 3.8.6 in September 2020

    Odoo 14.0 released in October supports python 3.7 and upper but that's not without consequence

    We can ask ourself what is the benefit to support 3.7.

    If yes, we have to deal with this kind of code in our OCA 14.0 module like here

    Maybe there is a better way to manage this version incompatibility but if not
    it can be difficult to ensure 3.7 compatibility in our modules

    Without this compatibility code we have this kind of error

    Are you really sure that supports 3.7 is good thing for our client in a fresh new project 14.0 while python 3.8 is very stable ?

    Even in debian targeted version we may upgrade to 3.8

    What do you think ?

    Regards

    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement

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

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

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

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

    by David BEAL - 12:56 - 14 Oct 2020
  • Re: New PMS Proposal
    We'll need to know PSC information.

    Will this be managed by an existing PSC ?
    Is it a new PSC ? If yes, who will be the PSC representative and first members ?

    -sbi


    On Wed, Oct 7, 2020 at 3:07 PM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:
    +1

    On Wed, 7 Oct 2020, 18:42 Roussel, Denis, <denis.roussel@acsone.eu> wrote:
    +1

    On Tue, Oct 6, 2020 at 10:26 PM dario <dario@commitsun.com> wrote:

    Hi!

    We have been working for two years on a Property Management System on Odoo. These modules are used to manage reservations for establishments of all kinds, hotels, tourist apartments, rural houses...
    and we have 42 establishments in production for two years (including Sada Marina in Galicia where the OCA 2019 codesprint was made! ;)

    We are currently committed to a major refactoring and upgrade to V14 of the entire base, we are working on it, and we will have it ready for December.

    The work for December includes:

    1. Reservations Management
    2. Revenue Prices
    3. Onboard Services
    4. Completed generic API REST based on odoo-connectos -thanks!!- (availability, reservations, restrictions, partners, pricelists, smartlocks)
    5. Specific implementation API with Channel Manager Wubook (what allow us connect with booking.com, expedia and many other OTAs..
    6. Customer Portal for Pre-Check in and invoice wizard


    Specifically, this is the repository on which the refactoring is being worked: https://github.com/commitsun/pms

    The original repository, base for the refactoring and which is currently in production on V11 is: https://github.com/hootel/hootel

    The work will still be WIP for the OCA days, but it would make me very happy to see it at OCA from there.

    The current vertical-hotel repository is incompatible with the development of this pms, and although when we started working on this project, two years ago, we tried to do it from the current vertical hotel (of those not yet in OCA), we had to start from zero for not being able to make this development compatible with the structure and flows that we have been learning in the sector (for example, to connect it with sales channels such as booking.com, expedia, etc ...). I do not know if the option of having two independent repositories is valid, but it is the only one that occurs to me to be able to transfer this work to OCA.

    I hope it is possible to see a new pms repository in OCA from the 15th of this month, any doubt or question, you tell me



    Thank you very much for your attention and for all your work that has made this project possible!

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



    --
    __________________________________________
    Denis Roussel
    Software Engineer
    Acsone SA, Succursale de Liège (Val Benoît)
    Tel    : +32 2 888 31 49
    Fax   : +32 2 888 31 59
    Gsm : +32 472 22 00 57

    Acsone sa/nv
    Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels  | Belgium
    Quai Banning, 6 (Val Benoît) | B-4000 Liège | Belgium
    Zone Industrielle 22 | L-8287 Kehlen | Luxembourg

    _______________________________________________
    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 Stéphane Bidoul - 12:45 - 14 Oct 2020
  • Re: Module for uploading multiple images/attachments to website 
    Thanx for info. What I wanted to achieve was to somehow upload batch of images 
into website so they could be used in HTML of blog posts we are migrating from 
old site. Or generally have the option in Media selection dialog in web editor 
to upload  a batch of images. However I found that this would be rather 
complicated because the URL of those images would be something like /web/
image/107007/image.png The number is generated so not much of a prediction 
where it'd go. 

I solved it in another way. I create a simple module that only contains 
static/src/img directory with all the images from original blog. That way it 
was easy to update the HTML content to point to these as the path would be 
fixed to /module_name/static/src/img/

Still I think it would be beneficial if it was possible to upload media in 
batch into website editor to be used later because now you have to upload them 
one by one.

S pozdravom

	Radovan Skolnik

On streda 14. októbra 2020 10:32:23 CEST Daniel Reis wrote:

> For a one time load you could use a single use module with an XML

> data file.

> XML data files are capable of importing directly from files.

> Example:

> https://github.com/odoo/odoo/blob/14.0/odoo/addons/base/data/res_partner_dem

> o.xml#L54 [1]

> 

> You would need to script the XML generation from a directory

> containing the files to import.

> 

> --dr

> 

> 

> On 14/10/2020 08:32, Peter Hahn wrote:

> 

> If I got you right you are asking for a one-time import job for

> migration, not for a front end based user friendly solution, right?

> 

> 

> _______________________________________________

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

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

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

> 

> 

> 

> [1]

> https://github.com/odoo/odoo/blob/14.0/odoo/addons/base/data/res_partner_de

> mo.xml#L54 [2] https://odoo-community.org/groups/contributors-15

> [3] https://odoo-community.org/groups?unsubscribe
    by Radovan Skolnik - 11:21 - 14 Oct 2020
  • Re: 14.0 branches
    + 1 for generating oca_dependencies.txt and requirements.txt

    In any case, thanks a lot for your work Stéphane


    On Tue, 13 Oct 2020 at 09:32, Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
    On Mon, Oct 12, 2020 at 5:32 PM Stéphane Bidoul
<stephane.bidoul@acsone.eu> wrote:


> I'll see if I can find an easy way to generate oca_dependencies.txt


> and requirements.txt.

I have been giving some thought to this and I believe it is possible
to create a reasonably fast pre-commit hook that generates
oca_dependencies.txt and requirements.txt.
Roughly, requirements.txt would be generated from the
external_dependencies manifest keys in the repo.
oca_dependencies.txt would be generated by looking at the website key
in manifests of first level dependencies which we find in the url key
of wheels (it is supposed to have the form
https://github.com/OCA/{repo} and we can enforce if we don't do it
yet).
There are some devils in the details (like what to do with
test-requirements.txt, and what to do when there are conflicting
requirements) but that seems manageable at first glance.
The result should be identical to manually crafted files and help
ensure consistency.

Would that work for people who care about those two files ?

For the rest, yeah, I guess this thread shows how deeply people care
about their project workflows, and that is only normal.
I can only repeat that *this should not have any impact on them*.
When I have more time I'll answer to some comments that worry about a
pip project workflow being broken or something (spoiler: it is not :)

Cheers,

-sbi

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



    --
    by Lorenzo Battistini. - 11:06 - 14 Oct 2020
  • Re: 14.0 branches
    PS: can you share the command to tray it from github?

    Hi Nhomar,
    the way I prefer:



    --
    by Lorenzo Battistini. - 11:00 - 14 Oct 2020
  • Re: V14, python version
    +1 for freezing version like 3.8.5 in OCA CI

    Bonne journée


    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement


    Le mer. 14 oct. 2020 à 10:07, Jean-Charles Drubay <jc@komit-consulting.com> a écrit :
    What do you think about freezing a specific python version for each odoo version? Or at least make it the recommended python version on which all the builds will run.

    Example:
    • Odoo 14: python  3.8.5
    • Odoo 13: python 3.7.9
    • ...
    This can be achieved by using pyenv-virtualenv.

    BTW, thanks Stéphane for all your late efforts and courage facing the avalanche of tough feedback. I admire both your contributions and communications. 

    Jean-Charles Drubay

    On Wed, Oct 14, 2020 at 2:42 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
    I've not looked into the cases you mentioned yet, but I note Odoo declares itself as supporting python 3.6:

    That's why the OCA 14.0 branches have been created for python 3.6 too.

    -sbi

    On Wed, Oct 14, 2020 at 9:27 AM David Beal <david.beal@akretion.com> wrote:
    Hi all,

    The last very stable python is 3.8 (first version in November 2019), 3.8.6 in September 2020

    Odoo 14.0 released in October supports python 3.7 and upper but that's not without consequence

    We can ask ourself what is the benefit to support 3.7.

    If yes, we have to deal with this kind of code in our OCA 14.0 module like here

    Maybe there is a better way to manage this version incompatibility but if not
    it can be difficult to ensure 3.7 compatibility in our modules

    Without this compatibility code we have this kind of error

    Are you really sure that supports 3.7 is good thing for our client in a fresh new project 14.0 while python 3.8 is very stable ?

    Even in debian targeted version we may upgrade to 3.8

    What do you think ?

    Regards

    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement

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

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

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

    by David BEAL - 10:46 - 14 Oct 2020
  • Re: 14.0 branches
    Hi Pedro,
    in case you can't avoid it, you can pin the version in setup.py file, like the following:


    On Tue, 13 Oct 2020 at 09:36, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:
    Stéphane, how to pin specific Python libraries versions in this workflow in the generated requirements.txt? We have several places with this requirement.

    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 Lorenzo Battistini. - 10:46 - 14 Oct 2020
  • Re: V14, python version
    I think OCA CI must run with the same python version as the oldest supported by Odoo.
    If we test, say with python 3.8, people installing OCA modules on otherwise Odoo supported python versions may face compatibility issues.
    In the other direction, compatibility issues will be much much less frequent, python being pretty good at ensuring backward compatibility.

    Python 3.6 is supported until end 2021.

    But we may want to clarify if what Odoo says in setup.py is correct. I don't know what python version Odoo uses on their runbot for instance.

    -sbi


    On Wed, Oct 14, 2020 at 10:07 AM David Beal <david.beal@akretion.com> wrote:
    Ok I haven't seen that before, thanks.

    The problem to begin with an old version is that even for recent projects, 12.0, you get bad signal only after 2 year.

    DEPRECATION: Python 3.5 reached the end of its life on September 13th, 2020. Please upgrade your Python as Python 3.5 is no longer maintained. pip 21.0 will drop support for Python 3.5 in January 2021. pip 21.0 will remove support for this functionality.

    I don't think it is a good thing for my customer to early have a deprecated python version.
    I suppose that the better way to avoid it is to have a recent python version used on OCA CI and then in our project whatever Odoo SA python policy version.

    Bonne journée


    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement


    Le mer. 14 oct. 2020 à 09:42, Stéphane Bidoul <stephane.bidoul@acsone.eu> a écrit :
    I've not looked into the cases you mentioned yet, but I note Odoo declares itself as supporting python 3.6:

    That's why the OCA 14.0 branches have been created for python 3.6 too.

    -sbi

    On Wed, Oct 14, 2020 at 9:27 AM David Beal <david.beal@akretion.com> wrote:
    Hi all,

    The last very stable python is 3.8 (first version in November 2019), 3.8.6 in September 2020

    Odoo 14.0 released in October supports python 3.7 and upper but that's not without consequence

    We can ask ourself what is the benefit to support 3.7.

    If yes, we have to deal with this kind of code in our OCA 14.0 module like here

    Maybe there is a better way to manage this version incompatibility but if not
    it can be difficult to ensure 3.7 compatibility in our modules

    Without this compatibility code we have this kind of error

    Are you really sure that supports 3.7 is good thing for our client in a fresh new project 14.0 while python 3.8 is very stable ?

    Even in debian targeted version we may upgrade to 3.8

    What do you think ?

    Regards

    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement

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

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

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

    by Stéphane Bidoul - 10:45 - 14 Oct 2020
  • Re: Module for uploading multiple images/attachments to website
    For a one time load you could use a single use module with an XML data file.
    XML data files are capable of importing directly from files.
    Example: https://github.com/odoo/odoo/blob/14.0/odoo/addons/base/data/res_partner_demo.xml#L54

    You would need to script the XML generation from a directory containing the files to import.

    --dr


    On 14/10/2020 08:32, Peter Hahn wrote:
    If I got you right you are asking for a one-time import job for
migration, not for a front end based user friendly solution, right?

    by Daniel Reis - 10:31 - 14 Oct 2020
  • Re: Migration to v14 requirement - readony / invisible 
    Hello Pedro,

I can see "invisible" still being used in v14 code, and couldn't find a 
deprecation notice.
Do you have a reference for this deprecation, please?

--daniel

On 14/10/2020 08:52, Pedro M. Baeza (Tecnativa) wrote:

> You can't put `invisible="1"`, but `attrs="{'invisible': <conditions>}"`

>

> Regards.

>

> _______________________________________________

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

>
    by Daniel Reis - 10:31 - 14 Oct 2020
  • Re: V14, python version
    Ok I haven't seen that before, thanks.

    The problem to begin with an old version is that even for recent projects, 12.0, you get bad signal only after 2 year.

    DEPRECATION: Python 3.5 reached the end of its life on September 13th, 2020. Please upgrade your Python as Python 3.5 is no longer maintained. pip 21.0 will drop support for Python 3.5 in January 2021. pip 21.0 will remove support for this functionality.

    I don't think it is a good thing for my customer to early have a deprecated python version.
    I suppose that the better way to avoid it is to have a recent python version used on OCA CI and then in our project whatever Odoo SA python policy version.

    Bonne journée


    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement


    Le mer. 14 oct. 2020 à 09:42, Stéphane Bidoul <stephane.bidoul@acsone.eu> a écrit :
    I've not looked into the cases you mentioned yet, but I note Odoo declares itself as supporting python 3.6:

    That's why the OCA 14.0 branches have been created for python 3.6 too.

    -sbi

    On Wed, Oct 14, 2020 at 9:27 AM David Beal <david.beal@akretion.com> wrote:
    Hi all,

    The last very stable python is 3.8 (first version in November 2019), 3.8.6 in September 2020

    Odoo 14.0 released in October supports python 3.7 and upper but that's not without consequence

    We can ask ourself what is the benefit to support 3.7.

    If yes, we have to deal with this kind of code in our OCA 14.0 module like here

    Maybe there is a better way to manage this version incompatibility but if not
    it can be difficult to ensure 3.7 compatibility in our modules

    Without this compatibility code we have this kind of error

    Are you really sure that supports 3.7 is good thing for our client in a fresh new project 14.0 while python 3.8 is very stable ?

    Even in debian targeted version we may upgrade to 3.8

    What do you think ?

    Regards

    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement

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

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

    by David BEAL - 10:01 - 14 Oct 2020
  • Re: V14, python version
    What do you think about freezing a specific python version for each odoo version? Or at least make it the recommended python version on which all the builds will run.

    Example:
    • Odoo 14: python  3.8.5
    • Odoo 13: python 3.7.9
    • ...
    This can be achieved by using pyenv-virtualenv.

    BTW, thanks Stéphane for all your late efforts and courage facing the avalanche of tough feedback. I admire both your contributions and communications. 

    Jean-Charles Drubay

    On Wed, Oct 14, 2020 at 2:42 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
    I've not looked into the cases you mentioned yet, but I note Odoo declares itself as supporting python 3.6:

    That's why the OCA 14.0 branches have been created for python 3.6 too.

    -sbi

    On Wed, Oct 14, 2020 at 9:27 AM David Beal <david.beal@akretion.com> wrote:
    Hi all,

    The last very stable python is 3.8 (first version in November 2019), 3.8.6 in September 2020

    Odoo 14.0 released in October supports python 3.7 and upper but that's not without consequence

    We can ask ourself what is the benefit to support 3.7.

    If yes, we have to deal with this kind of code in our OCA 14.0 module like here

    Maybe there is a better way to manage this version incompatibility but if not
    it can be difficult to ensure 3.7 compatibility in our modules

    Without this compatibility code we have this kind of error

    Are you really sure that supports 3.7 is good thing for our client in a fresh new project 14.0 while python 3.8 is very stable ?

    Even in debian targeted version we may upgrade to 3.8

    What do you think ?

    Regards

    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement

    _______________________________________________
    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 Jean-Charles Drubay - 10:01 - 14 Oct 2020
  • Re: Migration to v14 requirement - readony / invisible
    You can't put `invisible="1"`, but `attrs="{'invisible': <conditions>}"`

    Regards.
    by Pedro M. Baeza - 09:51 - 14 Oct 2020
  • Re: V14, python version
    I've not looked into the cases you mentioned yet, but I note Odoo declares itself as supporting python 3.6:

    That's why the OCA 14.0 branches have been created for python 3.6 too.

    -sbi

    On Wed, Oct 14, 2020 at 9:27 AM David Beal <david.beal@akretion.com> wrote:
    Hi all,

    The last very stable python is 3.8 (first version in November 2019), 3.8.6 in September 2020

    Odoo 14.0 released in October supports python 3.7 and upper but that's not without consequence

    We can ask ourself what is the benefit to support 3.7.

    If yes, we have to deal with this kind of code in our OCA 14.0 module like here

    Maybe there is a better way to manage this version incompatibility but if not
    it can be difficult to ensure 3.7 compatibility in our modules

    Without this compatibility code we have this kind of error

    Are you really sure that supports 3.7 is good thing for our client in a fresh new project 14.0 while python 3.8 is very stable ?

    Even in debian targeted version we may upgrade to 3.8

    What do you think ?

    Regards

    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement

    _______________________________________________
    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 - 09:36 - 14 Oct 2020
  • Re: Module for uploading multiple images/attachments to website 
    Hello Radovan,

If I got you right you are asking for a one-time import job for
migration, not for a front end based user friendly solution, right?

If that’s the case the best way to do it is using the python shell
interface for odoo and writing import scripts.

Usual way we do stuff like this is to dump data from the old system in
some structured way (access old DB, export to CSV/XML etc.) and read and
transform using python scripts.

Example for writing:
```
image_path = "/".join([self.image_base_path, path])
try:
    with Image.open(image_path) as image:
        buf = io.BytesIO()
        image.save(buf, format=image.format)
        b64_image = base64.b64encode(buf.getvalue())
        return b64_image, basename(image_path)
except FileNotFoundError as e:
    _logger.warning(
        f"Could not import image {image_path}",
        exc_info=_no_traceback(e))

```

Attached is a simple script for reading.
It just reads an image from a custom model. Doesn’t make sence for your
case, but you can use this as a minimal starting example for the script
and combine with the above code.

If you use Odoo with buildout simply call:
`bin/python_odoo <your_script.py> [your script arguments]`
to run it.


regards, Peter






Am 13.10.20 um 16:36 schrieb Radovan Skolnik:

> Nobody has anything on this? I really hate repetitive tasks - in this case

> uploading images one by one. Isn't there a way for example to import

> attachments? I've seen something like base64 encoding the content of image and

> the provide it as content. But still needs to set Resource Model to ir.ui.view

> which seems to be read only? Am I missing somethin crucial here? Any advice is

> highly appreciated. Thank you.

> Best regards

> Radovan

> On pondelok 28. septembra 2020 10:42:15 CEST Radovan Skolnik wrote:

>> Hello,

>>

>> we are migrating old site (done in WordPress) into Odoo created site. I am

>> looking for a way to upload and store multiple images for use in the

>> migrated pages/blogs. So far I couldn't find a way to do this but I have a

>> hunch I am missing something here :-) Any help is appreciated. Thank you.

>>

>> Best regards

>>

>> 	Radovan Skolnik

> 

> 

> 

> _______________________________________________

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

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

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

> 

> 

> 

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

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

>
    by Pete Hahn - 09:31 - 14 Oct 2020

    1 attachments 1 attachments

    pil_watermarking.py
  • V14, python version
    Hi all,

    The last very stable python is 3.8 (first version in November 2019), 3.8.6 in September 2020

    Odoo 14.0 released in October supports python 3.7 and upper but that's not without consequence

    We can ask ourself what is the benefit to support 3.7.

    If yes, we have to deal with this kind of code in our OCA 14.0 module like here

    Maybe there is a better way to manage this version incompatibility but if not
    it can be difficult to ensure 3.7 compatibility in our modules

    Without this compatibility code we have this kind of error

    Are you really sure that supports 3.7 is good thing for our client in a fresh new project 14.0 while python 3.8 is very stable ?

    Even in debian targeted version we may upgrade to 3.8

    What do you think ?

    Regards

    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement
    by David BEAL - 09:26 - 14 Oct 2020
  • OCA Days - Zoom hosts and moderators - still need a few more
    Hi folks,

    OCA Days are nearly upon us and we do need a few extra hands on deck to "host/moderate", help with the Zoom technical side of things over the two days. There are still a few time slots left.

    If you feel you can help for a couple of hours that would be amazing, please pop your name on the schedule with your email address so we can get in touch.

    Thanks in advance,
    Rebecca

    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly - 06:21 - 14 Oct 2020
  • Re: 14.0 branches


    El mar., 13 de oct. de 2020 a la(s) 01:57, David Beal (david.beal@akretion.com) escribió:
    +1 for generated requirements.txt and oca_dependencies.txt too if possible

    IMHO I think that can not be optional but mandatory for the sake of stability and take 2 versions to stabilize.

    I wonder how will be the management of a wired repository.

    I mean:

    oca_dependency.txt.

    folder git/repo branch

    And force the dependency be taken/updated from it.

    Regards.

     


    I love the effort that has been made to autodiscover the dependencies from __manifest__
    Please don't discourage it with arguments about your own deployments.
    You may use pip in OCA workflow as proposed, and use git for your development/production as I do everyday

    You have to decouple things for your own interest

    my 2 cts

    Bonne journée


    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement


    Le mar. 13 oct. 2020 à 08:47, Stefan Rijnhart <stefan@opener.am> a écrit :
    +1 for generated requirements.txt and oca_dependencies.txt

    Stefan

    On 12-10-2020 14:52, Alexandre Fayolle wrote:
    I'm happy with generated requirements.txt and oca_dependencies files. This will remove some errors caused by manual management of these files anyway.

    Regarding oca_dependencies: I use them to easily find when an addon is defined, where to direct a contribution, etc. I also happened to "discover" some OCA repositories that way.

    Regarding requirements.txt: the latest version of Odoo's runbot uses these to install the requirements. It will help using OCA repositories on Odoo.sh, and I think it is a valuable service we provide to our users.

    Regarding pip installation of addons, I'm not sure this is available on odoo.sh, and I think this is a use case we should not underestimate.

    Le lun. 12 oct. 2020 à 09:07, Mignon, Laurent <laurent.mignon@acsone.eu> a écrit :
    HI Folks,

    I think it's very important to keep the debate open and to present your arguments in a constructive way.I must admit that I am a little saddened to read accusations of half-truths when the process is meant to be open and constructive. It seems to me that the goal here is not to impose a new methodology but to confront our practices with those of the python community. The fact that the aim of this approach is to simplify the maintenance of our OCA repositories as well as to reduce the learning curve for new developers, I find this more than remarkable and valuable.

    Since many integrators' tools/processes are now based on the oca_dependencies.txt and requirement.txt files, in view of the discussion it seems necessary that somehow these should be available again. It seems to me that automating the generation of these files would be more than beneficial because it would avoid inconsistencies in the future for all the processes based on them.

    Over the years I have used different tools and methodologies to try to improve the management of our dev -> prod processes of our python projects. I personally contributed to buildout, imagined and wrote git-agggregator, .... The goal has always been to improve the traceability and reproducibility of our developments and deployments. Today, and thanks to the evolutions around pip, I'm happy to see that python tools allow me to improve and simplify these processes without having to use specific tools. (While bringing more freedom and features).

    Is it possible to envisage an evolution of our integration mechanisms towards pip support while retaining the necessary elements for the other approaches developed by the various parties?

    I find it motivating to confront this approach with all the use cases of each other in order to determine the limits of this approach. This will at least allow us to improve our knowledge and perhaps correct certain ideas.

    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



    --

    Nhomar G Hernández

    Vauxoo | CEO

    ¡Construyamos algo genial!
    Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

    México · Venezuela · Costa Rica · Perú

    phone nhomar@vauxoo.com phone vauxoo.com/contactus  

    by Nhomar Hernández - 04:06 - 14 Oct 2020
  • Re: 14.0 branches


    El mar., 13 de oct. de 2020 a la(s) 04:11, Jairo Llopis (jairo.llopis@tecnativa.com) escribió:
    Hi all!

    There's one thing that's true, Stéphane, and it's that you asked nobody... I'm sad but you have to admit that. 🤷‍ Actually in the template, the default value was "OCA", so this was a total surprise. I don't agree with the flamewar itself, but I guess you should have expected it...]

    I just think this is the real point of the arguments.

    The current architecture took +/- 2 years to stabilize (considering all the corner cases).

     

    Anyways, I see that not having to deal manually with requirements.txt and oca_dependencies.txt is good! Also that will make new contributors lifes' easier (no, I don't have statistics if you ask for them 😝, but surely if pushing a module code makes travis go green instead of red, that's a good definition of "easier").

    But losing the current ones (or making them work without time to hurry up) is not good either, It is not for nothing that python itself took >10 years between 2-3 and everybody knows in the meanwhile it will happen.

     

    There are plenty of deployment styles here at OCA (we use doodba, you know... so this doesn't affect us), so in general terms, OCA should care more about OCA itself and their contributors.

    There's some weird stuff around the thread saying that you can't pin installs with pip, which I don't really understand because you totally can... Also I don't see what's worse on that (if true) than unpinned .txt files elsewhere... Well, nevermind.

    For those of you that don't like requirements.txt syntax (I don't also), check out Poetry. It's a total pleasure. I'm not saying I'll use pip to deploy odoo, it's just a tip for those of you considering doing that. 😊

    Now, I do have some questions / suggestions:
    1. What happens when the module name differs from the package name? Or when several packages provide modules with the same name? How do we specify that in the manifest? AFAIK, until today only the module name is used there...
    2. Do we need to create the setup folder on all PRs? Or does the bot do it?
    3. If pip dependencies can be expressed through git, have you considered dropping the wheelhouse and using always git as dep system (with pip)? If the wheelhouse is meant to be used as a playground before real packages are pushed to pypi, have you considered using https://test.pypi.org? These might be dumb questions, but if it speeds up OCA workflow and removes the maintenance burden, it can be good.
    4. If the problem is that people needs a way to know what are a given module's dependencies, and where can they be found, would it be possible to have a script that parses a manifest and provides such info? Or could we include that info in the README automatically built by the bot, or in the module page at https://odoo-community.org/shop, or could https://odoo-community.org/ provide an API to get that info in JSON? Probably all these solutions would be better that a random text file.
    5. Where can we find docs about all of this? If none, then may you add them please?
    Finally a word for PSCs that want to disable this behavior in some specific repos: instead of directly writting to .travis.yml, please use copier instead: copier update -fd dependency_installation_mode=OCA
    There are some reasons behind this, but I think that's another subject. Just take it as a rule of thumb to ease template updates.

    Hugs!

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



    --

    Nhomar G Hernández

    Vauxoo | CEO

    ¡Construyamos algo genial!
    Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

    México · Venezuela · Costa Rica · Perú

    phone nhomar@vauxoo.com phone vauxoo.com/contactus  

    by Nhomar Hernández - 04:06 - 14 Oct 2020
  • unsubscribe
    Hi all!

    Please unsubscribe this email from all the OCA mailing lists please. I've already try it several times but I keep receiving new emails.

    Thank you!

    --
    Gabriel.
    by Gabriel Davini - 04:45 - 13 Oct 2020