Archives
Contributors
-
Re: Module for uploading multiple images/attachments to website
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
by Radovan Skolnik - 04:35 - 13 Oct 2020 -
OCA Days - Sprint Document
Hi,If you will participate in the code sprint, please add topics you would plan to work on in this document: https://docs.google.com/document/d/1VHx8kKg3THAbxmx89wHZRa35_YfcU8F_g2E9sMlHnTU/edit?usp=sharingDo not forget to join the discord server for real time collaboration: https://discord.gg/tNby4kuIf you need specific additional channel topics on discord, just ask there in the #general channel.Best regards,-sbi--
by Stéphane Bidoul - 04:11 - 13 Oct 2020 -
Re: calendar colors
Hi Akim,We've done this for 12.0, and very recently in 14.0.Not for 13.0, though.I'm not quite happy with the 12.0 implementation, as it requires several overrides, but it works. You can check it out here: https://github.com/druidoo/druidoo-addons/tree/12.0/web_calendar_color_fieldThe 14.0 version is much simpler, since Odoo improved the code a bit and partially introduced this feature through filters. Hence I take the opportunity to PR to OCA: https://github.com/OCA/web/pull/1703Best,Iván TodorovichEl mar., 13 oct. 2020 a las 7:07, Akim Juillerat (<akim.juillerat@camptocamp.com>) escribió:Hello communityIs there a module or anything that's already been done to select the color of a calendar event according to a type in recent versions (looking for v13.0)?For example, in the event modules, the colors are used according to the event type but there's no way to say Type1=red and Type2=blue. This could also be useful in the leaves module to display leaves according to their type (paid leave=green, sickness=red).I couldn't find anything useful except old tutorials on how to do it on version 8.0Thanks
--camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSAkim JuilleratBusiness solutions Software developer_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Iván Todorovich - 03:55 - 13 Oct 2020 -
Re: module migration
I would say that migrating a module, although it only implies changing the version number as nothing more is required, already means to be in contributors list, as you have followed the procedure to migrate commit history, and so on. The same for doing bugfixes. To be on author list, your contribution have to be significant enough:- Migration requires to redo a lot in the module.- You add a feature in it that means a high amount of code/testing/etc (for example, adding a full test suite for an untested module - if that module requires testing - should mean a co-authorship).Anyway, that can be decided case by case on the PR that adds the changes.Regards.El mar., 13 oct. 2020 a las 13:11, David Beal (<david.beal@akretion.com>) escribió:Hi all,I have a small question about contributions in module migration.What is the minimal work that implies adding my name in the contributors section?- change version number- minimal fix on test or doc- other- substantial fixPotentially when I know the OCA workflow, I may migrate a module with only functional knowledge and luck.Thanks to share your opinionsConsultantOdoo 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 Pedro M. Baeza - 01:20 - 13 Oct 2020 -
module migration
Hi all,I have a small question about contributions in module migration.What is the minimal work that implies adding my name in the contributors section?- change version number- minimal fix on test or doc- other- substantial fixPotentially when I know the OCA workflow, I may migrate a module with only functional knowledge and luck.Thanks to share your opinionsConsultantOdoo Intégration / Développement
by David BEAL - 01:11 - 13 Oct 2020 -
calendar colors
Hello communityIs there a module or anything that's already been done to select the color of a calendar event according to a type in recent versions (looking for v13.0)?For example, in the event modules, the colors are used according to the event type but there's no way to say Type1=red and Type2=blue. This could also be useful in the leaves module to display leaves according to their type (paid leave=green, sickness=red).I couldn't find anything useful except old tutorials on how to do it on version 8.0Thanks
--camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSAkim JuilleratBusiness solutions Software developer
by Akim Juillerat - 12:05 - 13 Oct 2020 -
Re: 14.0 branches
On Tue, Oct 13, 2020 at 11:11 AM Jairo Llopis <jairo.llopis@tecnativa.com> wrote: > 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... As I said earlier: > in the past the only arguments I had received were of the general class "I don't like it", but nothing really concrete. > So yeah, I guess I'm pushing a little bit in the hope of getting solid feedback. I honestly did not expect a flamewar on this but it probably illustrates why the topic was stuck before. But we are now making progress, so that's good :) And I repeat this was and still is totally revertible, and it has had zero impact on anyone's workflow in practice yet. > 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... Since v13 we can and should use the PyPI package name in manifest external dependencies. > Do we need to create the setup folder on all PRs? Or does the bot do it? There is a pre-commit hook that does it for you, it's part of the template. > If pip dependencies can be expressed through git, have you considered dropping the wheelhouse and using always git as dep system (with pip)? The problem is then locating the repo in the first place. Having a flat space with all OCA addons easily installable is a simplification, IMO. > 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. The wheelhouse predates the decision to push to PyPI, it's not really been a maintenance burden so far (especially compared to all the rest of the OCA infra :). I think it still has value as an OCA only source. > Where can we find docs about all of this? If none, then may you add them please? The OCA infrastructure lacks documentation in general. I'm trying to organize my slides of Thursday in a format that we can use as a reference in the future. Now I think I'll mute this thread otherwise said slides are never going to materialize :) > 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 +1 -sbi
by Stéphane Bidoul - 11:46 - 13 Oct 2020 -
Re: 14.0 branches
This scenario shouldn't happen in the OCA (for Odoo module versions, I mean).
If this is the case, the problem should be fixed at the source.
So it is a non issue, as far as OCA CI is concerned.
Now, if you are entertaining the idea to use pip instead of git in your dev workflows, this this is a good question.
AFAIK pip can use git and install from it, and supports everything that git does, so you can pip install a particular pinned commit.
--dr
On 13/10/2020 09:11, Houssine BAKKALI wrote:
I'm curious to know how specific module version dependency will be handled with pip... At least with github we can rely on the repository state at time t.
This case won't happen often but sometimes fix or improvements on module A, imply dev on module B so you will depend on a certain version on module B for the version bringing the fix or improvements on module A.
Or an other case is that on version of module B(on a different repository) brings a bug or regression on you module A so you may want to stick with one version of the module B. How you handle that ?Anyway I'm not against this move as far as we still have a way to handle the dependency without pip.
On 13/10/2020 09:57, Daniel Reis wrote:
I believe the external_dependencies manifest key supports pinned versions. On 13/10/2020 08:36, Pedro M. Baeza (Tecnativa) 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.
_______________________________________________
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 Daniel Reis - 10:26 - 13 Oct 2020 -
Re: 14.0 branches
On Tue, Oct 13, 2020 at 9:36 AM 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. First a word about version pinning in general. As much as possible we must avoid *strict* pins in OCA repos, because it creates a risk of conflicts when installing other repos requiring the same libraries, or downstream projects. If there is a minimum version we need to support, we can say libN >= x.y. And if there is a need to declare a maximum version, we can also say "libN >= x.y, <= z.t" (see PEP 440 [3] for details). We need to keep in mind that the more constraint we place (especially on upper versions), the more risk we have to create downstream version conflicts. Of course the above applies to OCA repos only. In customer projects, it is highly recommended to pin as strictly as possible, of course. As to where these constraints have to be declared, it would be in - setup.py, as it is already the case today (external_dependencies_override [1]), because unfortunately Odoo does not allow specifying constraints in the manifest (I opened the discussion with Odoo without much success so far [2]) - or in test-requirements.txt if these are dependencies that cannot be declared in the addon manifests for some reason -sbi [1] https://pypi.org/project/setuptools-odoo/2.5.10/#controlling-setuptools-odoo-behaviour [2] https://github.com/odoo/odoo/pull/35800 [3] https://www.python.org/dev/peps/pep-0440/
by Stéphane Bidoul - 10:26 - 13 Oct 2020 -
Re: 14.0 branches
I'm curious to know how specific module version dependency will be handled with pip... At least with github we can rely on the repository state at time t.
This case won't happen often but sometimes fix or improvements on module A, imply dev on module B so you will depend on a certain version on module B for the version bringing the fix or improvements on module A.
Or an other case is that on version of module B(on a different repository) brings a bug or regression on you module A so you may want to stick with one version of the module B. How you handle that ?Anyway I'm not against this move as far as we still have a way to handle the dependency without pip.
On 13/10/2020 09:57, Daniel Reis wrote:
I believe the external_dependencies manifest key supports pinned versions. On 13/10/2020 08:36, Pedro M. Baeza (Tecnativa) 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.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Houssine BAKKALI - 10:10 - 13 Oct 2020 -
Re: 14.0 branches
I believe the external_dependencies manifest key supports pinned versions. On 13/10/2020 08:36, Pedro M. Baeza (Tecnativa) 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.
by Daniel Reis - 09:56 - 13 Oct 2020 -
Re: 14.0 branches
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.
by Pedro M. Baeza - 09:36 - 13 Oct 2020 -
Re: 14.0 branches
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
by Stéphane Bidoul - 09:30 - 13 Oct 2020 -
Re: weblate
Hi Yves, Your user has permissions on French translations. If the problem persists, please send an email with details to transbot@odoo-community.org. -sbi On Tue, Oct 13, 2020 at 8:01 AM Yves Goldberg <yves@ygol.com> wrote: > > Hi would like to add translation to weblate but I can't save translates terms. > Is it a permission setting issue? > If yes who has admin right and could help me? > tnx > > -- > Yves Goldberg > -- > > _______________________________________________ > 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:06 - 13 Oct 2020 -
Re: 14.0 branches
+1 for generated requirements.txt and oca_dependencies.txt too if possibleI 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 everydayYou have to decouple things for your own interestmy 2 ctsLe 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
by David BEAL - 08:56 - 13 Oct 2020 -
Re: 14.0 branches
+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
by Stefan Rijnhart - 08:46 - 13 Oct 2020 -
weblate
Hi would like to add translation to weblate but I can't save translates terms.Is it a permission setting issue?If yes who has admin right and could help me?tnx--Yves Goldberg--
by Yves Goldberg - 08:00 - 13 Oct 2020 -
Re: 14.0 branches
El lun., 12 de oct. de 2020 a la(s) 18:56, Graeme Gellatly (gdgellatly@gmail.com) escribió:@Nhomar Hernandez it was just a simplified example, skipping a few steps. We use doodba these days, so for general purposes dev/test/production are the same. But using doodba, in general you do any non client specific development in a seperate generalised build. Otherwise you end up in another special type of git hell.
Andale! we are doing the same, pip on modules my itself with doodba does not add any value, docket is doing the job.We use oca_dependencies to refer to PR's and those stuff (no PIP needed).Thanks for the comment.
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
by Nhomar Hernández - 03:10 - 13 Oct 2020 -
Migration to v14 requirement - readony / invisible
Hello All,
I note on the wiki at https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0#howto reference to:
Some XML modifiers in views disappear: invisible and readonly. They should be assigned through general modifier attrs.
Can anyone shed light on this? I see no reference in base Odoo to deprecation of these modifiers?
Richard
Richard deMeester
Senior Development Analyst
WilldooIT Pty Ltd
E: richard.demeester@willdooit.com
M: +61 403 76 76 76
P: +61 3 9135 1900
A: 10/435 Williamstown Road, Port Melbourne, Vic 3207
Making growth through technology easy
DISCLAIMER | This electronic message together with any attachments is confidential. If you are not the recipient, do not copy, disclose, or use the contents in any way. Please also advise us by e-mail that you have received this message in error and then please destroy this email and any of its attachments. WilldooIT Pty. Ltd. is not responsible for any changes made to this message and/or any attachments after sending by WilldooIT Pty. Ltd. WilldooIT Pty. Ltd. use virus scanning software but exclude all liability for virus or anything similar in this email or attachment.
by Richard deMeester <richard.demeester@willdooit.com> - 02:31 - 13 Oct 2020
