Archives
Contributors
-
Activating tab on form from code?
Hello,
I would need to make certain tab active based on field contents of the record in basically 2 scenarios:
1) As a result of the action
2) When opening the record in form view
The idea is to lead the user to a tab where they need to fill in some stuff.
2) would override default system behavior that tries to keep last open tab open when switching to next record - i.e. I open one record from tree view and the press Next. It should also work when I open the first one.
1) would seem to be easier but I do not have any idea how to tacke this. Manipulating view architecture does not seem to work because there is no information on the record being displayed
Am I missing something? Any pointers on how to do this?
Thank you very much. Best regards
Radovan
by Radovan Skolnik - 07:56 - 31 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
In my experience, and from what I can read, unreachable commits get garbage collected at some point and effectively disappear from GitHub.This makes sense, for instance when you need to remove security sensitive stuff that would have been committed by accident.This is the main drawback of any force push operation:Integrators who would have pinned commits posterior to the commit that added the .deb files will likely encounter errors at some point,and will have difficulties to recover code that is identical to what they have pinned.The other attention point I see is that weblate will enter in conflict for all these branches.This will require a manual operation to rebase or reset all affected branches in GitLab.So if we do this, we must make sure people stop translating a few hours before the force push.Regarding the repo size, I'm also not convinced we will gain that much in practice.In OCA CI, action/checkout fetches the last commit only by default, and the OCA bot has a git cache, so the effect is probably negligible compared to everything else that is going on.And since the Odoo ecosystem is used to wrestle a huge repo, a lot of folks have developed strategies to save bandwidth (shallow clones, git worktrees, etc).Also, do we know what will happen to PR that have been created after the .deb commit?So yeah, sorry for the mistake, happy to change my mind if anything I said above is wrong, but at this stage I'm not convinced this is worth the manual effort and downstream disturbances.Best,-StéphaneOn Mon, Jul 29, 2024 at 8:58 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:> I'm more concerned about commit history after the file merge. Nothing more.Try this if you want:- Do a pull request with a migration.- Copy a permalink of something of the migration commit.- git commit --amend and git push -f- Open the previous permalink and it will work.Anyway, the path of these branches is still very young, and it is better to do it as soon as possible (also for avoiding more and more clones).Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 12:51 - 31 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
> I'm more concerned about commit history after the file merge. Nothing more.Try this if you want:- Do a pull request with a migration.- Copy a permalink of something of the migration commit.- git commit --amend and git push -f- Open the previous permalink and it will work.Anyway, the path of these branches is still very young, and it is better to do it as soon as possible (also for avoiding more and more clones).Regards.
by Pedro M. Baeza - 08:57 - 29 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
> Apart of that, an ecological reason cannot be put on the table here if we continue to recreate main branches from scratch as that leads to more repository space than the problem here araised.Are you seriously comparing at least 30 MB - on OCA/social it's 60 MB - each time a clone / pull is done (and all the automated tools that require cloning from scratch without depth control) vs 2-3 MB of the existing clones to reset the branch?
by Pedro M. Baeza - 08:57 - 29 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
As said, I understand the technical reasons.I'm more concerned about commit history after the file merge. Nothing more.Le lun. 29 juil. 2024, 20:42, Enric Tobella Alomar <notifications@odoo-community.org> a écrit :If we remove the file in a commit, it will not be removed from history, so, it will take a lot of Mb when we download the repository. The only way is to remove the file from history.El lun, 29 jul 2024 a las 20:38, Roussel, Denis (<notifications@odoo-community.org>) escribió:Even if I understand the issue here, I'm more doubtful about the force push mandatory operation (even if I understand the technical reason behind not to have the file appearance at all).I'm more concerned by the sha hashes problems we can have towards authorship.That said, I'm more to a commit removing the conflicting file.Apart of that, @Pedro Manuel Baeza , an ecological reason cannot be put on the table here if we continue to recreate main branches from scratch as that leads to more repository space than the problem here araised.Le lun. 29 juil. 2024, 18:12, Pedro M. Baeza <notifications@odoo-community.org> a écrit :Due to a mistake on the tool to generate the READMES (fixed in [1]), some very big files ~30 MB each~ (with extension .deb or .dmg for Mac users) have been added both by the merge bot or by users doing a module migration.This makes that on branch/repository clonation, or any free pull operation on any local git repository copy (of any branch) wastes a lot of bandwidth and resources, and is not ecological friendly.Due to this, and although not ideal, we plan to force push the affected repositories (note that this has been only in 17.0 branches), following [3] technique recommended by Nils.The drawback of doing this is that your next `git pull` operations on that branches will fail, saying about unrelated commit histories or creating a merge commit with possible conflicts.The solution for avoiding it is to do the commands:g it fetch origin 17.0 git reset --hard origin/17.0(beingoriginthe OCA remote). In fact, this is the recommended way to do it in automated pulling systems.If you don't have any strong counter-arguments, I will perform it at the end of the week. I will announce here the affected repositories after the operation.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Enric Tobella AlomarCEO & Founder_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Denis Roussel - 08:51 - 29 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
If we remove the file in a commit, it will not be removed from history, so, it will take a lot of Mb when we download the repository. The only way is to remove the file from history.El lun, 29 jul 2024 a las 20:38, Roussel, Denis (<notifications@odoo-community.org>) escribió:Even if I understand the issue here, I'm more doubtful about the force push mandatory operation (even if I understand the technical reason behind not to have the file appearance at all).I'm more concerned by the sha hashes problems we can have towards authorship.That said, I'm more to a commit removing the conflicting file.Apart of that, @Pedro Manuel Baeza , an ecological reason cannot be put on the table here if we continue to recreate main branches from scratch as that leads to more repository space than the problem here araised.Le lun. 29 juil. 2024, 18:12, Pedro M. Baeza <notifications@odoo-community.org> a écrit :Due to a mistake on the tool to generate the READMES (fixed in [1]), some very big files ~30 MB each~ (with extension .deb or .dmg for Mac users) have been added both by the merge bot or by users doing a module migration.This makes that on branch/repository clonation, or any free pull operation on any local git repository copy (of any branch) wastes a lot of bandwidth and resources, and is not ecological friendly.Due to this, and although not ideal, we plan to force push the affected repositories (note that this has been only in 17.0 branches), following [3] technique recommended by Nils.The drawback of doing this is that your next `git pull` operations on that branches will fail, saying about unrelated commit histories or creating a merge commit with possible conflicts.The solution for avoiding it is to do the commands:g it fetch origin 17.0 git reset --hard origin/17.0(beingoriginthe OCA remote). In fact, this is the recommended way to do it in automated pulling systems.If you don't have any strong counter-arguments, I will perform it at the end of the week. I will announce here the affected repositories after the operation.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 08:41 - 29 Jul 2024 -
Re: pandoc-*.deb cleaning in OCA repositories
Even if I understand the issue here, I'm more doubtful about the force push mandatory operation (even if I understand the technical reason behind not to have the file appearance at all).I'm more concerned by the sha hashes problems we can have towards authorship.That said, I'm more to a commit removing the conflicting file.Apart of that, @Pedro Manuel Baeza , an ecological reason cannot be put on the table here if we continue to recreate main branches from scratch as that leads to more repository space than the problem here araised.Le lun. 29 juil. 2024, 18:12, Pedro M. Baeza <notifications@odoo-community.org> a écrit :Due to a mistake on the tool to generate the READMES (fixed in [1]), some very big files ~30 MB each~ (with extension .deb or .dmg for Mac users) have been added both by the merge bot or by users doing a module migration.This makes that on branch/repository clonation, or any free pull operation on any local git repository copy (of any branch) wastes a lot of bandwidth and resources, and is not ecological friendly.Due to this, and although not ideal, we plan to force push the affected repositories (note that this has been only in 17.0 branches), following [3] technique recommended by Nils.The drawback of doing this is that your next `git pull` operations on that branches will fail, saying about unrelated commit histories or creating a merge commit with possible conflicts.The solution for avoiding it is to do the commands:
g it fetch origin 17.0 git reset --hard origin/17.0(beingoriginthe OCA remote). In fact, this is the recommended way to do it in automated pulling systems.If you don't have any strong counter-arguments, I will perform it at the end of the week. I will announce here the affected repositories after the operation.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Denis Roussel - 08:37 - 29 Jul 2024 -
pandoc-*.deb cleaning in OCA repositories
Due to a mistake on the tool to generate the READMES (fixed in [1]), some very big files ~30 MB each~ (with extension .deb or .dmg for Mac users) have been added both by the merge bot or by users doing a module migration.This makes that on branch/repository clonation, or any free pull operation on any local git repository copy (of any branch) wastes a lot of bandwidth and resources, and is not ecological friendly.Due to this, and although not ideal, we plan to force push the affected repositories (note that this has been only in 17.0 branches), following [3] technique recommended by Nils.The drawback of doing this is that your next `git pull` operations on that branches will fail, saying about unrelated commit histories or creating a merge commit with possible conflicts.The solution for avoiding it is to do the commands:
git fetch origin 17.0 git reset --hard origin/17.0(beingoriginthe OCA remote). In fact, this is the recommended way to do it in automated pulling systems.If you don't have any strong counter-arguments, I will perform it at the end of the week. I will announce here the affected repositories after the operation.Regards.
by Pedro M. Baeza - 06:11 - 29 Jul 2024 -
Re: ledger
Hello,The module account_asset_management is available in version 17 here:Regarding translations issues, first you need to find the module where the term to translate comes from (make sure it's an OCA module) and if something prevents you from translating them in Weblate, you can contact the email address showed on this page:I'm note sure if you are trying to change terms on a local database or in the OCA translation files related to OCA accounting modules, when reading your question. If it's the second option, what I just told you is relevant.Have a nice day,Le mer. 3 juil. 2024 à 11:55, Angel García-Junco Lora <notifications@odoo-community.org> a écrit :Dear colleages,we installed the accounting modules for the Ledgers,but when we try to lranaslate the ledger terms, General Ledger and Partner Ledger, these items arent don't translateSome one know what do we can to trabslate these terms of the Contabilidad Menu?Thanks in advanceEl 24/06/2024 20:14 CEST Angel García-Junco Lora <software@jlbberp.com> escribió:Dear Colleagues,
We try to install ledger in odoo comunity version 17, but the modules involved in it aren't compatible someone would know how, or if you could give us some indications, about compatibilize the module account_asset_management module, from v16 to v17?Thanks in advance
Best Regards,Angel Luis García-Junco Lora (Departamento de Software)SOFTWARE Y SERVICIOS TECNOLÓGICOS desde 1984Calle Democracia nº5 | San José de la Rinconada41300 LA RINCONADA ( ANDALUCÍA) - ESPAÑA Teléfono Centralita :(+34)955 085 361 Móvil Telegram y WhatsApp : (+34)601325581 Email:software@jlbberp.com NORMATIVA LEGAL DEL TRATAMIENTO DE LOS DATOS APLICABLE: EN RELACIÓN A LA APLICACIÓN DEL NUEVO REGLAMENTO (UE) 2016/679 DEL PARLAMENTO EUROPEO Y DEL CONSEJO, DE 27 DE ABRIL DE 2016, RELATIVO A LA PROTECCIÓN DE LAS PERSONAS FÍSICAS EN LO QUE RESPECTA AL TRATAMIENTO DE DATOS PERSONALES Y A LA LIBRE CIRCULACIÓN DE ESTOS DATOS, SE LE INFORMA Y CONSIENTE EXPRESAMENTE DE LOS SIGUIENTES EXTREMOS: "QUE, JOSE LUIS BAÑOS CONSULTING Y LA PLATAFORMA DE SERVICIOS TECNOLÓGICOS PMTK BUSINESS IN THE CLOUD, SON LOS RESPONSABLES DEL TRATAMIENTO DE SUS DATOS CON SEDE SOCIAL EN C/. DEMOCRACIA NÚM. 5 - SAN JOSE DE LA RINCONADA | 41300 LA RINCONADA ANDALUCIA ; CUYA FINALIDAD SE BASA EN UNA RELACIÓN CONTRACTUAL Y LEGAL Y, QUE LOS MISMOS, PUEDEN SER CEDIDOS A LOS SOLOS EFECTOS CONTRACTUALES; QUE LA EMPRESA LE BRINDA PODER EJERCR LOS DERECHOS A.R.C.O. Y OTROS (EL ACCESO A LOS DATOS PERSONALES RELATIVOS AL INTERESADO, Y SU RECTIFICACIÓN O SUPRESIÓN, O LA LIMITACIÓN DE SU TRATAMIENTO, O A OPONERSE AL TRATAMIENTO, ASÍ COMO EL DERECHO A LA PORTABILIDAD DE LOS DATOS); ANTE NUESTRO DELEGADO DE PROTECCIÓN DE DATOS, CUYO RESPONSABLE ES D. JOSÉ LUIS BAÑOS BELLIDO NIF 30412908P, TENIENDO COMO CANAL DE COMUNICACIÓN EL CORREO: CONSULTORIA@JLBBERP.COMAtentamente,Angel Luis García-Junco Lora (Departamento de Software)SOFTWARE Y SERVICIOS TECNOLÓGICOS desde 1984Calle Democracia nº5 | San José de la Rinconada41300 LA RINCONADA ( ANDALUCÍA) - ESPAÑA Teléfono Centralita :(+34)955 085 361 Móvil Telegram y WhatsApp : (+34)601325581 Email:software@jlbberp.com NORMATIVA LEGAL DEL TRATAMIENTO DE LOS DATOS APLICABLE: EN RELACIÓN A LA APLICACIÓN DEL NUEVO REGLAMENTO (UE) 2016/679 DEL PARLAMENTO EUROPEO Y DEL CONSEJO, DE 27 DE ABRIL DE 2016, RELATIVO A LA PROTECCIÓN DE LAS PERSONAS FÍSICAS EN LO QUE RESPECTA AL TRATAMIENTO DE DATOS PERSONALES Y A LA LIBRE CIRCULACIÓN DE ESTOS DATOS, SE LE INFORMA Y CONSIENTE EXPRESAMENTE DE LOS SIGUIENTES EXTREMOS: "QUE, JOSE LUIS BAÑOS CONSULTING Y LA PLATAFORMA DE SERVICIOS TECNOLÓGICOS PMTK BUSINESS IN THE CLOUD, SON LOS RESPONSABLES DEL TRATAMIENTO DE SUS DATOS CON SEDE SOCIAL EN C/. DEMOCRACIA NÚM. 5 - SAN JOSE DE LA RINCONADA | 41300 LA RINCONADA ANDALUCIA ; CUYA FINALIDAD SE BASA EN UNA RELACIÓN CONTRACTUAL Y LEGAL Y, QUE LOS MISMOS, PUEDEN SER CEDIDOS A LOS SOLOS EFECTOS CONTRACTUALES; QUE LA EMPRESA LE BRINDA PODER EJERCR LOS DERECHOS A.R.C.O. Y OTROS (EL ACCESO A LOS DATOS PERSONALES RELATIVOS AL INTERESADO, Y SU RECTIFICACIÓN O SUPRESIÓN, O LA LIMITACIÓN DE SU TRATAMIENTO, O A OPONERSE AL TRATAMIENTO, ASÍ COMO EL DERECHO A LA PORTABILIDAD DE LOS DATOS); ANTE NUESTRO DELEGADO DE PROTECCIÓN DE DATOS, CUYO RESPONSABLE ES D. JOSÉ LUIS BAÑOS BELLIDO NIF 30412908P, TENIENDO COMO CANAL DE COMUNICACIÓN EL CORREO: CONSULTORIA@JLBBERP.COM_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Virginie Dewulf - 12:15 - 26 Jul 2024 -
Re: Reflections on Odoo
Hi Jon,Thanks a lot for sharing this: wonderful to see the value the OCA brings to the Odoo world in your perspective.Hope to see you again in September/October for our OCA Days!Le jeu. 18 juil. 2024 à 12:19, Jon Baxter <notifications@odoo-community.org> a écrit :Hi there.I've put together some thoughts on software implementation and cost, using the experience of a council in the UK as an example. I make the point the exorbitant cost of the usual ERP solution providers has contributed to the failure and suggest (in a nutshell) to try Odoo.If you think it's worth commenting on or sharing, please do so.I hope it helps.ThanksJon
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Virginie Dewulf - 11:41 - 26 Jul 2024 -
Re: Mod 193 Odoo 14
There's no work planned for that model for now, so you can do it. Go to OCA/l10n-spain for more discussion about it.Regards.
by Pedro M. Baeza - 04:26 - 20 Jul 2024 -
Re: v18 early migration work based on master
Hi,Allowing a PR on a future version is a good way to go further.We are in august, and the new version is in October, then we don't have so much time to move,then the roadmap must be short I suppose.Le jeu. 18 juil. 2024 à 11:47, Stéphane Bidoul <notifications@odoo-community.org> a écrit :Hm, I don't have a good feeling with merging stuff that is not proven compatible with the real 18.0, that's going to be confusing.Also, all the dependency management relies on merged stuff being available on PyPI.But that can still be considered in a second step when we have learned to fly with unmerged PRs first.-sbiOn Thu, Jul 18, 2024 at 11:23 AM Simone Orsi <simahawk@gmail.com> wrote:Thanks everybody for the feedback :)@Stéphane Bidoul regardingI'd also suggest not merging nor pushing to PyPI until the Odoo 18.0 branch has been created, so work only with git PR references in test-requirements.txt for dependencies.
So we'd probably need to add protections in the bot to avoid premature merges or pushes to PyPI
I agree on not pushing to PyPI but we should merge, to not enter a valley of pain later.IMO the version of the module should serve as the way to check if it is fully migrated or not and we could update the repo readme generation to make it more visible, same for the module's readme. Maybe a ribbon?We could also add a non blocking warning test in the CI.WDYT?On Tue, Jul 16, 2024 at 3:27 PM Mignon, Laurent <notifications@odoo-community.org> wrote:> I'd go for branch opt 3 + mod version opt 2.+1On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:I think this could be nice. I would favor Option 2 for branch naming. This could be an indicator for the OCAbot to behave differently about the version numbers when a PR s merged (and we can have option 1 for module version). Alexandre On 01/07/2024 12:42, Simone Orsi wrote: > Hi everybody, > > We would like to start working on migrating some base modules to v18 > before it gets released. > > AFAIR there's no "official" policy for it, if not "do it on your own > fork and then open PRs when the release is out". > > From my POV it would be nice to define one. > > For the branch, I see these options: > > 1. add a `master` branch that can be used w/ any version > 2. add a `$nextVersion-[master|dev]` branch that can be used w/ odoo > master for a specific version > 3. simply have $nextVersion branch and stick to version policy nr 2 (see > below) > > For the module version: > > 1. append `dev`to the version (eg: 18.0.1.0.0dev) > 2. start w/ a number lesser than 1.0.0 and switch to 1.0.0 only when the > release is out (eg: 18.0.0.0.1) > > I'd go for branch opt 3 + mod version opt 2. > > For the test suite: I'm not sure we have a way to run tests against > master ATM. > > Am I missing something? > > In general, what do you think? > > -- > Simone Orsi > > Full stack Python web developer, Odoo specialist, Odoo Community Board > Member, in love with open source. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > <https://odoo-community.org/groups/contributors-15> > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe > <https://odoo-community.org/groups?unsubscribe> > -- Alexandre Fayolle Senior Software Engineer Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by David BEAL - 03:01 - 18 Jul 2024 -
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.-sbiOn 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.+1On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:I think this could be nice. I would favor Option 2 for branch naming. This could be an indicator for the OCAbot to behave differently about the version numbers when a PR s merged (and we can have option 1 for module version). Alexandre On 01/07/2024 12:42, Simone Orsi wrote: > Hi everybody, > > We would like to start working on migrating some base modules to v18 > before it gets released. > > AFAIR there's no "official" policy for it, if not "do it on your own > fork and then open PRs when the release is out". > > From my POV it would be nice to define one. > > For the branch, I see these options: > > 1. add a `master` branch that can be used w/ any version > 2. add a `$nextVersion-[master|dev]` branch that can be used w/ odoo > master for a specific version > 3. simply have $nextVersion branch and stick to version policy nr 2 (see > below) > > For the module version: > > 1. append `dev`to the version (eg: 18.0.1.0.0dev) > 2. start w/ a number lesser than 1.0.0 and switch to 1.0.0 only when the > release is out (eg: 18.0.0.0.1) > > I'd go for branch opt 3 + mod version opt 2. > > For the test suite: I'm not sure we have a way to run tests against > master ATM. > > Am I missing something? > > In general, what do you think? > > -- > Simone Orsi > > Full stack Python web developer, Odoo specialist, Odoo Community Board > Member, in love with open source. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > <https://odoo-community.org/groups/contributors-15> > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe > <https://odoo-community.org/groups?unsubscribe> > -- Alexandre Fayolle Senior Software Engineer Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
by Stéphane Bidoul - 11:46 - 18 Jul 2024 -
Re: v18 early migration work based on master
Thanks everybody for the feedback :)@Stéphane Bidoul regardingI'd also suggest not merging nor pushing to PyPI until the Odoo 18.0 branch has been created, so work only with git PR references in test-requirements.txt for dependencies.
So we'd probably need to add protections in the bot to avoid premature merges or pushes to PyPI
I agree on not pushing to PyPI but we should merge, to not enter a valley of pain later.IMO the version of the module should serve as the way to check if it is fully migrated or not and we could update the repo readme generation to make it more visible, same for the module's readme. Maybe a ribbon?We could also add a non blocking warning test in the CI.WDYT?On Tue, Jul 16, 2024 at 3:27 PM Mignon, Laurent <notifications@odoo-community.org> wrote:> I'd go for branch opt 3 + mod version opt 2.+1On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:I think this could be nice. I would favor Option 2 for branch naming. This could be an indicator for the OCAbot to behave differently about the version numbers when a PR s merged (and we can have option 1 for module version). Alexandre On 01/07/2024 12:42, Simone Orsi wrote: > Hi everybody, > > We would like to start working on migrating some base modules to v18 > before it gets released. > > AFAIR there's no "official" policy for it, if not "do it on your own > fork and then open PRs when the release is out". > > From my POV it would be nice to define one. > > For the branch, I see these options: > > 1. add a `master` branch that can be used w/ any version > 2. add a `$nextVersion-[master|dev]` branch that can be used w/ odoo > master for a specific version > 3. simply have $nextVersion branch and stick to version policy nr 2 (see > below) > > For the module version: > > 1. append `dev`to the version (eg: 18.0.1.0.0dev) > 2. start w/ a number lesser than 1.0.0 and switch to 1.0.0 only when the > release is out (eg: 18.0.0.0.1) > > I'd go for branch opt 3 + mod version opt 2. > > For the test suite: I'm not sure we have a way to run tests against > master ATM. > > Am I missing something? > > In general, what do you think? > > -- > Simone Orsi > > Full stack Python web developer, Odoo specialist, Odoo Community Board > Member, in love with open source. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > <https://odoo-community.org/groups/contributors-15> > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe > <https://odoo-community.org/groups?unsubscribe> > -- Alexandre Fayolle Senior Software Engineer Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
by Simone Orsi - 11:25 - 18 Jul 2024 -
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
C/ Rosalía de Castro N17, Puerta1 Entresuelo
36201 Vigo Pontevedra
Tel.: 886138703
Fax: 886137958
Móvil 678206430
Antes de imprimir este correo electrónico piense bien si es necesario hacerlo: El medioambiente es cosa de todos.
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 -
Re: v18 early migration work based on master
> I'd go for branch opt 3 + mod version opt 2.+1On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:I think this could be nice. I would favor Option 2 for branch naming. This could be an indicator for the OCAbot to behave differently about the version numbers when a PR s merged (and we can have option 1 for module version). Alexandre On 01/07/2024 12:42, Simone Orsi wrote: > Hi everybody, > > We would like to start working on migrating some base modules to v18 > before it gets released. > > AFAIR there's no "official" policy for it, if not "do it on your own > fork and then open PRs when the release is out". > > From my POV it would be nice to define one. > > For the branch, I see these options: > > 1. add a `master` branch that can be used w/ any version > 2. add a `$nextVersion-[master|dev]` branch that can be used w/ odoo > master for a specific version > 3. simply have $nextVersion branch and stick to version policy nr 2 (see > below) > > For the module version: > > 1. append `dev`to the version (eg: 18.0.1.0.0dev) > 2. start w/ a number lesser than 1.0.0 and switch to 1.0.0 only when the > release is out (eg: 18.0.0.0.1) > > I'd go for branch opt 3 + mod version opt 2. > > For the test suite: I'm not sure we have a way to run tests against > master ATM. > > Am I missing something? > > In general, what do you think? > > -- > Simone Orsi > > Full stack Python web developer, Odoo specialist, Odoo Community Board > Member, in love with open source. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > <https://odoo-community.org/groups/contributors-15> > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe > <https://odoo-community.org/groups?unsubscribe> > -- Alexandre Fayolle Senior Software Engineer Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Laurent Mignon - 03:26 - 16 Jul 2024
