Archives
Contributors
-
Repository for repair module
Hello,I'll be working on a module to make a procurement from a repair order in the repair module for V14. But I don't know in which repository I can make the PR, I have searched in OCA Shop and I found modules related to repair in field-service and manufacture repositories.Where is the best repo to add this module?Thanks in advance
by Jesús Alan Ramos Rodriguez - 09:00 - 20 Jan 2021 -
Muli Cloud and Hybrid Cloud for Odoo Solutions
Hi Contributors,JuanDCG.
I've been 4 months researching about IaC with Terraform for Odoo implementations at multi cloud level.
I've also been researching in hybrid cloud with kubernetes for Odoo solutions.
This research is cover by the open source project "TerradooCloud" (https://github.com/TerradooCloud), where I want offer a documentation reference for all the possible deployments scenarios for Odoo on Cloud.
Recently, Google Cloud launch a course and already have a docs for SAP (https://cloud.google.com/solutions/sap/docs).
This is like my intends to build for Odoo instead for SAP.
At this moment, I don't have more time to spend in this research, I only can offer management of GitHub projects and reviews, but due to it is a very big and ambitious project, only can be possible with contributors interested.
Now, I'm focusing in IoT and electronics, so I continue with microk8s and Odoo for server side of IoT, but my focus will be in electronics side.
If there are anyone interested in participate in this project is already invited to be a member of the organization, but with external PRs is the best way to participate.
Thank you very much, I hope this project will be interested to anyone,
by Juan Del Castillo Gómez - 01:36 - 20 Jan 2021 -
Header sorting in form view
Dear community,I'm looking for an addon or a way to keep user sorting choices.As you know, you can click on a One2Many or Many2Many header (of a stored field) to sort the lines but any action in the form (validate something or encoding quantities, etc.) reload it and reset the user sort.I don't have a great JS expertise that's why I'm asking here before starting to work on a new module/hook dedicated to this feature.Thank you.--Yann Papouin
by Yann Papouin - 11:11 - 11 Jan 2021 -
Re: OCA and security notices
Hi, Xavier,The delay depends on 2 factors:- The technical work to be done, which is the installed core modules to be covered by OpenUpgrade + the OCA modules to be migrated. This can be complemented with use cases test suite to be checked.- The customer alignment for the best moment to migrate, depending on their activity.FYI, we are migrating our customers to v13 now, having 4 of them on 13.0 already, and the rest coming in the following months.Regards.El mié, 6 ene 2021 a las 19:07, Xavier Brochard (<xavier@alternatif.org>) escribió:Hi Pedro I've found your post very interesting. However can you elaborate a bit on the delay before migration ? Obviously you can't migrate before the newest version is stabilized enough, but you can't also migrate before OpenUpgrade is available (or do you migrate "by hand" ?). So, are you curently running Odoo 13 and planning migrations around june ? Best regards Xavier / zeroheure --- Librement, Xavier Brochard xavier@alternatif.org La liberté est à l'homme ce que les ailes sont à l'oiseau (Jean-Pierre Rosnay) Le 05.01.2021 09:27, Pedro M. Baeza (Tecnativa) a écrit : > Hi, Tom, > > Each version can have some bugs, but it's better to handle them > between more people than let SaaS users or the same partners to > notify/fix them. You think it's "safer" to be on a previous version > for avoiding such bugs, but the facts are: > > - Such a bug is because of your use cases, and it will be found on the > version you are using, no matter if outdated or not. Nobody till then > may notify it. > - Odoo is fixing bugs very quickly and without effort by your part on > the latest version (or the previous one), as they are committed to > "stabilize" that version, but not on very old versions. A note about > this: notifying properly a bug is the key for having it solved. You > can't expect to have the work done not doing a minimum effort on your > part. > > - Bugs can happen even on unsupported versions, so the maintenance > cost starts to rise if you need to fix them by yourself and you are > introducing regression risks. > - There are even occasions where the bug is fixed or doesn't apply on > higher versions, but you don't have it in an outdated one. See the > recent CVE cases and the effort needed by Stefan and Nils. > - Odoo continues to improve its test suite, and each version has more > and more stability/quality. > > Other facts about using outdated versions: > > - You need to "backport" features that are on higher versions or lack > them. > - Framework evolves, and using an outdated framework makes your > development team to require more time to complete the same tasks, or > to not have available some tools. Programming in 2020 with the old API > or the v8/v9 hybrid for me is horrible. > - Collaboration possibilities are reduced working on an outdated > version, as there are less contributors on them. You can see the same > examples on your 7.0 PRs, or even on the 10.0 PRs, that is more > recent, but the same unattended. > - As a complement to the previous one, new contributors push newer > versions, not old ones. > - Underlying libraries and dependencies are outdated as well, with the > problems this supposes. > > So at Tecnativa we deal with this not having middle positions: all our > customers go to latest versions (the supported ones), and we reject > those that don't want this approach. That way, we focus on dealing > with a reduced set of Odoo versions, we migrate them regularly (not > forcing a yearly migration, but more and more customers demand to go > to each version and they don't want to keep the same version 2/3 > years), and we report bugs to Odoo constantly that makes the versions > stable enough. > > Migrating OCA modules is not a problem while you are on the wheel. The > keys are: > > - Having a team used to OCA guidelines. All our developments follow > strict guidelines. This makes the team to take the habit and don't > require more time to be "OCA". Anyway, 95% of our developments are > directly OCA. OCA first approach is also very important for us. > > - Having good test coverage. This is vital for easing the migrations. > Doing good tests is not easy, but the time spent on that will be for > sure gained later. This includes also JS tour/Qunit tests if needed. > - Reviewing PRs between colleagues as part of your development cycle. > This raises a lot your team skills and don't stuck PRs. People > complain about their PRs not being reviewed, but they don't review > others in exchange or don't push colleagues to review them. > > We also take a proactive position for handling some "polemical" > decisions taken on the versions, creating OCA modules that fill the > gaps. This is better IMO than staying on an older version and > complaining that "Odoo has removed this or changed that". In general > you win more than you lose on newer versions. > > And finally, customers receive a refresh training on each version > change. Being proactive as well on the changes they have makes people > to not reject the new version and embrace the new features from the > beginning. > > Do I convince you, hehe? > > Regards. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Pedro M. Baeza - 12:36 - 7 Jan 2021 -
Re: Sales terms
Thanks a lot Pedro for your insight !RegardsLe jeu. 7 janv. 2021 à 11:22, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> a écrit :You have base_comment_template module + extensions (account_comment_template for example).Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Pierre
by Pierre Verkest - 11:30 - 7 Jan 2021 -
Re: Sales terms
You have base_comment_template module + extensions (account_comment_template for example).Regards.
by Pedro M. Baeza - 11:21 - 7 Jan 2021 -
Sales terms
Hi there !I wish you the best for 2021 !I'm on the way to add terms.template model to be able to define different terms template onSale Order (maybe on invoice as well later) so that users can choose the template that will populate terms ( note fields as Html field). Expected behaviour is what happens with email template, the user chooses a term template, the note field will be populated and the user can change it afterwards.Do you know a such module exists if not what do you think to create a such module in Sale Workflow repoRegards,
by Pierre Verkest - 11:16 - 7 Jan 2021 -
Re: A module to add methods to convert datetime between UTC and
user's timezone
Yes, that's it. Thank you, Lorenzo!--Yoshi TashiroOn Wed, Jan 6, 2021 at 5:02 PM Lorenzo Battistini <elbaddy@gmail.com> wrote:On Wed, 6 Jan 2021 at 04:42, Yoshi Tashiro <tashiro@quartile.co> wrote:I think I've seen somewhere under OCA a module to add generic methods to convert datetime between UTC and user's timezone, but I somehow can't find it now. A pointer would be appreciated.--Yoshi Tashiro_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Lorenzo Battistini
https://github.com/eLBati_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Yoshi Tashiro. - 09:21 - 6 Jan 2021 -
Re: A module to add methods to convert datetime between UTC and
user's timezone
On Wed, 6 Jan 2021 at 04:42, Yoshi Tashiro <tashiro@quartile.co> wrote:I think I've seen somewhere under OCA a module to add generic methods to convert datetime between UTC and user's timezone, but I somehow can't find it now. A pointer would be appreciated.--Yoshi Tashiro_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Lorenzo Battistini
https://github.com/eLBati
by Lorenzo Battistini. - 09:01 - 6 Jan 2021 -
Re: A module to add methods to convert datetime between UTC and
user's timezone
OK, I'd better look into odoo.tools, although there might be cases where we do not want to apply the formats by the language. Thanks a lot, Graeme!--Yoshi TashiroOn Wed, Jan 6, 2021 at 4:12 PM Graeme Gellatly <gdgellatly@gmail.com> wrote:HiThe first 2 cases are already done better in odoo.tools and also exposed to mail.template, maybe reports too, well except it also formats the string for the users language too I think. Easily importable.The 3rd case isn't worth it IMO, it seems quite specific and written in a very long way. Something like datetime.now(pytz.timezone('tz')).utcoffset() will do it in a 1 liner with maybe a bit of math and its a ton easier using python main datetime and pytz modulesI used to maintain a report date helper module but never use it anymore.On Wed, 6 Jan 2021, 7:27 pm Yoshi Tashiro, <tashiro@quartile.co> wrote:Thanks Graeme and Dominique. What I'm looking for is a collection of methods that are not covered in Date and Datetime classes of vanilla Odoo. For example:# Convert datetime object to date stringdef _convert_to_user_date_string(self, datetime, hours):user_datetime = datetime + relativedelta(hours=hours)return fields.Date.to_string(fields.Date.to_date(user_datetime))# Convert date string with timestamp to datetime objectdef _convert_to_user_datetime_string(self, date, timestamp, hours):datetime_value = fields.Datetime.from_string("{} {}".format(date, timestamp))return fields.Datetime.to_string(datetime_value - relativedelta(hours=hours))# Return the time difference (in hours), e.g. if user's timezone is in# GMT+9 this method will return 9.0def _get_tz_hours_diff(self):current_time = fields.Datetime.now()user_time = pytz.utc.localize(current_time).astimezone(tz)utc_time = timezone("UTC").localize(current_time)hours_diff = ((user_time.utcoffset() - utc_time.utcoffset()) / timedelta(minutes=1) / 60)return hours_diffI vaguely remember seeing somewhere someone extending Date and Datetime in a somewhat similar manner. If there is nothing under OCA we may create a module and make a PR.--Yoshi TashiroOn Wed, Jan 6, 2021 at 2:12 PM Dominique k <dominique.k@elico-corp.com.sg> wrote:oh... will check that. thanks a lot--On Wed, 6 Jan 2021 at 12:42 PM, Graeme Gellatly <gdgellatly@gmail.com> wrote:It is built in to odoo and sometimes uses babel under hood.For today jobs fields.Date.context_today(record with tz context, optional timestamp) is my general go to available in views as context_today.odoo.tools.format_datetime or something like that does it too for datetime plus locale specific representation as string.There is some more. Check fields.Date* and odoo.toolsIn record rules it is tons harder but if you have the patience you can handroll a very ugly rule using time module.Regards from UTC+13.On Wed, 6 Jan 2021, 5:22 pm Dominique k, <dominique.k@elico-corp.com.sg> wrote:i would be curious if there is one, or contribute for developing oneUTC --> user timezone is a real real pain to develop. particularly when trying to get "today" jobsRegards,DominiqueOn Wed, 6 Jan 2021 at 11:42, Yoshi Tashiro <tashiro@quartile.co> wrote:I think I've seen somewhere under OCA a module to add generic methods to convert datetime between UTC and user's timezone, but I somehow can't find it now. A pointer would be appreciated.--Yoshi Tashiro
_______________________________________________
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
Dominique KON-SUN-TACK [Project Manager]Odoo Gold Partner, best Odoo Partner 2014 for APACMobile: + 65 8502 2399Skype: dominique_elicoWebsite: www.elico-corp.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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Yoshi Tashiro. - 08:26 - 6 Jan 2021 -
Re: A module to add methods to convert datetime between UTC and
user's timezone
HiThe first 2 cases are already done better in odoo.tools and also exposed to mail.template, maybe reports too, well except it also formats the string for the users language too I think. Easily importable.The 3rd case isn't worth it IMO, it seems quite specific and written in a very long way. Something like datetime.now(pytz.timezone('tz')).utcoffset() will do it in a 1 liner with maybe a bit of math and its a ton easier using python main datetime and pytz modulesI used to maintain a report date helper module but never use it anymore.On Wed, 6 Jan 2021, 7:27 pm Yoshi Tashiro, <tashiro@quartile.co> wrote:Thanks Graeme and Dominique. What I'm looking for is a collection of methods that are not covered in Date and Datetime classes of vanilla Odoo. For example:# Convert datetime object to date stringdef _convert_to_user_date_string(self, datetime, hours):user_datetime = datetime + relativedelta(hours=hours)return fields.Date.to_string(fields.Date.to_date(user_datetime))# Convert date string with timestamp to datetime objectdef _convert_to_user_datetime_string(self, date, timestamp, hours):datetime_value = fields.Datetime.from_string("{} {}".format(date, timestamp))return fields.Datetime.to_string(datetime_value - relativedelta(hours=hours))# Return the time difference (in hours), e.g. if user's timezone is in# GMT+9 this method will return 9.0def _get_tz_hours_diff(self):current_time = fields.Datetime.now()user_time = pytz.utc.localize(current_time).astimezone(tz)utc_time = timezone("UTC").localize(current_time)hours_diff = ((user_time.utcoffset() - utc_time.utcoffset()) / timedelta(minutes=1) / 60)return hours_diffI vaguely remember seeing somewhere someone extending Date and Datetime in a somewhat similar manner. If there is nothing under OCA we may create a module and make a PR.--Yoshi TashiroOn Wed, Jan 6, 2021 at 2:12 PM Dominique k <dominique.k@elico-corp.com.sg> wrote:oh... will check that. thanks a lot--On Wed, 6 Jan 2021 at 12:42 PM, Graeme Gellatly <gdgellatly@gmail.com> wrote:It is built in to odoo and sometimes uses babel under hood.For today jobs fields.Date.context_today(record with tz context, optional timestamp) is my general go to available in views as context_today.odoo.tools.format_datetime or something like that does it too for datetime plus locale specific representation as string.There is some more. Check fields.Date* and odoo.toolsIn record rules it is tons harder but if you have the patience you can handroll a very ugly rule using time module.Regards from UTC+13.On Wed, 6 Jan 2021, 5:22 pm Dominique k, <dominique.k@elico-corp.com.sg> wrote:i would be curious if there is one, or contribute for developing oneUTC --> user timezone is a real real pain to develop. particularly when trying to get "today" jobsRegards,DominiqueOn Wed, 6 Jan 2021 at 11:42, Yoshi Tashiro <tashiro@quartile.co> wrote:I think I've seen somewhere under OCA a module to add generic methods to convert datetime between UTC and user's timezone, but I somehow can't find it now. A pointer would be appreciated.--Yoshi Tashiro_______________________________________________
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
Dominique KON-SUN-TACK [Project Manager]Odoo Gold Partner, best Odoo Partner 2014 for APACMobile: + 65 8502 2399Skype: dominique_elicoWebsite: www.elico-corp.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
by Graeme Gellatly - 08:11 - 6 Jan 2021 -
Re: A module to add methods to convert datetime between UTC and
user's timezone
Thanks Graeme and Dominique. What I'm looking for is a collection of methods that are not covered in Date and Datetime classes of vanilla Odoo. For example:# Convert datetime object to date stringdef _convert_to_user_date_string(self, datetime, hours):user_datetime = datetime + relativedelta(hours=hours)return fields.Date.to_string(fields.Date.to_date(user_datetime))# Convert date string with timestamp to datetime objectdef _convert_to_user_datetime_string(self, date, timestamp, hours):datetime_value = fields.Datetime.from_string("{} {}".format(date, timestamp))return fields.Datetime.to_string(datetime_value - relativedelta(hours=hours))# Return the time difference (in hours), e.g. if user's timezone is in# GMT+9 this method will return 9.0def _get_tz_hours_diff(self):current_time = fields.Datetime.now()user_time = pytz.utc.localize(current_time).astimezone(tz)utc_time = timezone("UTC").localize(current_time)hours_diff = ((user_time.utcoffset() - utc_time.utcoffset()) / timedelta(minutes=1) / 60)return hours_diffI vaguely remember seeing somewhere someone extending Date and Datetime in a somewhat similar manner. If there is nothing under OCA we may create a module and make a PR.--Yoshi TashiroOn Wed, Jan 6, 2021 at 2:12 PM Dominique k <dominique.k@elico-corp.com.sg> wrote:oh... will check that. thanks a lot--On Wed, 6 Jan 2021 at 12:42 PM, Graeme Gellatly <gdgellatly@gmail.com> wrote:It is built in to odoo and sometimes uses babel under hood.For today jobs fields.Date.context_today(record with tz context, optional timestamp) is my general go to available in views as context_today.odoo.tools.format_datetime or something like that does it too for datetime plus locale specific representation as string.There is some more. Check fields.Date* and odoo.toolsIn record rules it is tons harder but if you have the patience you can handroll a very ugly rule using time module.Regards from UTC+13.On Wed, 6 Jan 2021, 5:22 pm Dominique k, <dominique.k@elico-corp.com.sg> wrote:i would be curious if there is one, or contribute for developing oneUTC --> user timezone is a real real pain to develop. particularly when trying to get "today" jobsRegards,DominiqueOn Wed, 6 Jan 2021 at 11:42, Yoshi Tashiro <tashiro@quartile.co> wrote:I think I've seen somewhere under OCA a module to add generic methods to convert datetime between UTC and user's timezone, but I somehow can't find it now. A pointer would be appreciated.--Yoshi Tashiro
_______________________________________________
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
Dominique KON-SUN-TACK [Project Manager]Odoo Gold Partner, best Odoo Partner 2014 for APACMobile: + 65 8502 2399Skype: dominique_elicoWebsite: www.elico-corp.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 Yoshi Tashiro. - 07:26 - 6 Jan 2021 -
Re: A module to add methods to convert datetime between UTC and user's timezone
oh... will check that. thanks a lot--On Wed, 6 Jan 2021 at 12:42 PM, Graeme Gellatly <gdgellatly@gmail.com> wrote:It is built in to odoo and sometimes uses babel under hood.For today jobs fields.Date.context_today(record with tz context, optional timestamp) is my general go to available in views as context_today.odoo.tools.format_datetime or something like that does it too for datetime plus locale specific representation as string.There is some more. Check fields.Date* and odoo.toolsIn record rules it is tons harder but if you have the patience you can handroll a very ugly rule using time module.Regards from UTC+13.On Wed, 6 Jan 2021, 5:22 pm Dominique k, <dominique.k@elico-corp.com.sg> wrote:i would be curious if there is one, or contribute for developing oneUTC --> user timezone is a real real pain to develop. particularly when trying to get "today" jobsRegards,DominiqueOn Wed, 6 Jan 2021 at 11:42, Yoshi Tashiro <tashiro@quartile.co> wrote:I think I've seen somewhere under OCA a module to add generic methods to convert datetime between UTC and user's timezone, but I somehow can't find it now. A pointer would be appreciated.--Yoshi Tashiro_______________________________________________
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
Dominique KON-SUN-TACK [Project Manager]Odoo Gold Partner, best Odoo Partner 2014 for APACMobile: + 65 8502 2399Skype: dominique_elicoWebsite: www.elico-corp.com
by dominique.k - 06:06 - 6 Jan 2021 -
Re: A module to add methods to convert datetime between UTC and
user's timezone
It is built in to odoo and sometimes uses babel under hood.For today jobs fields.Date.context_today(record with tz context, optional timestamp) is my general go to available in views as context_today.odoo.tools.format_datetime or something like that does it too for datetime plus locale specific representation as string.There is some more. Check fields.Date* and odoo.toolsIn record rules it is tons harder but if you have the patience you can handroll a very ugly rule using time module.Regards from UTC+13.On Wed, 6 Jan 2021, 5:22 pm Dominique k, <dominique.k@elico-corp.com.sg> wrote:i would be curious if there is one, or contribute for developing oneUTC --> user timezone is a real real pain to develop. particularly when trying to get "today" jobsRegards,DominiqueOn Wed, 6 Jan 2021 at 11:42, Yoshi Tashiro <tashiro@quartile.co> wrote:I think I've seen somewhere under OCA a module to add generic methods to convert datetime between UTC and user's timezone, but I somehow can't find it now. A pointer would be appreciated.--Yoshi Tashiro
_______________________________________________
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 Graeme Gellatly - 05:40 - 6 Jan 2021 -
A module to add methods to convert datetime between UTC and user's timezone
I think I've seen somewhere under OCA a module to add generic methods to convert datetime between UTC and user's timezone, but I somehow can't find it now. A pointer would be appreciated.--Yoshi Tashiro
by Yoshi Tashiro. - 04:40 - 6 Jan 2021 -
Re: OCA and security notices
Hi, Tom,Each version can have some bugs, but it's better to handle them between more people than let SaaS users or the same partners to notify/fix them. You think it's "safer" to be on a previous version for avoiding such bugs, but the facts are:- Such a bug is because of your use cases, and it will be found on the version you are using, no matter if outdated or not. Nobody till then may notify it.- Odoo is fixing bugs very quickly and without effort by your part on the latest version (or the previous one), as they are committed to "stabilize" that version, but not on very old versions. A note about this: notifying properly a bug is the key for having it solved. You can't expect to have the work done not doing a minimum effort on your part.- Bugs can happen even on unsupported versions, so the maintenance cost starts to rise if you need to fix them by yourself and you are introducing regression risks.- There are even occasions where the bug is fixed or doesn't apply on higher versions, but you don't have it in an outdated one. See the recent CVE cases and the effort needed by Stefan and Nils.- Odoo continues to improve its test suite, and each version has more and more stability/quality.Other facts about using outdated versions:- You need to "backport" features that are on higher versions or lack them.- Framework evolves, and using an outdated framework makes your development team to require more time to complete the same tasks, or to not have available some tools. Programming in 2020 with the old API or the v8/v9 hybrid for me is horrible.- Collaboration possibilities are reduced working on an outdated version, as there are less contributors on them. You can see the same examples on your 7.0 PRs, or even on the 10.0 PRs, that is more recent, but the same unattended.- As a complement to the previous one, new contributors push newer versions, not old ones.- Underlying libraries and dependencies are outdated as well, with the problems this supposes.So at Tecnativa we deal with this not having middle positions: all our customers go to latest versions (the supported ones), and we reject those that don't want this approach. That way, we focus on dealing with a reduced set of Odoo versions, we migrate them regularly (not forcing a yearly migration, but more and more customers demand to go to each version and they don't want to keep the same version 2/3 years), and we report bugs to Odoo constantly that makes the versions stable enough.Migrating OCA modules is not a problem while you are on the wheel. The keys are:- Having a team used to OCA guidelines. All our developments follow strict guidelines. This makes the team to take the habit and don't require more time to be "OCA". Anyway, 95% of our developments are directly OCA. OCA first approach is also very important for us.- Having good test coverage. This is vital for easing the migrations. Doing good tests is not easy, but the time spent on that will be for sure gained later. This includes also JS tour/Qunit tests if needed.- Reviewing PRs between colleagues as part of your development cycle. This raises a lot your team skills and don't stuck PRs. People complain about their PRs not being reviewed, but they don't review others in exchange or don't push colleagues to review them.We also take a proactive position for handling some "polemical" decisions taken on the versions, creating OCA modules that fill the gaps. This is better IMO than staying on an older version and complaining that "Odoo has removed this or changed that". In general you win more than you lose on newer versions.And finally, customers receive a refresh training on each version change. Being proactive as well on the changes they have makes people to not reject the new version and embrace the new features from the beginning.Do I convince you, hehe?Regards.
by Pedro M. Baeza - 09:21 - 5 Jan 2021 -
Re: OCA and security notices
Interesting conversation about SDLC.
And very important to take in account in real life projects with OCA.
I've a doubt if working from scratch with Odoo OCB and OCA or from Odoo CE because no all repositories are migrated.
I'm agree with Pedro to work at edge in last version, this is fundamental for security reasons of dependencies packages, but it's ideal if you work with OCA without migrated repositories.I propose discuss about SDLC with a discord channel and maybe another channel for S-SDLC ( Security/SecDevOps ).Happy year Contributors !!!JuanDCGEl jue, 31 dic 2020 a las 16:07, Raphaël Valyi (<rvalyi@akretion.com>) escribió:a few considerations,About a 2 years based LTS:yes at Akretion we mostly skipped the uneven Odoo versions since version 8 (before that evolution was so much needed that we couldn't). But that may change. It happens Odoo SA screwed v9 release badly and so far they screwed no even version. But should they screw v16, we might totally change our "LTS" policy and we have no control over what version Odoo will screw or not. That being said, there is also an OCA effort resonance happening on Odoo uneven releases. Look how many modules every Odoo version has 1 year or 2 years after release and it will be clear that this is not just an Akretion thing. In the future, eventually migrations become simpler and we follow every version, I can not tell you except that this would be the condition.About migration cycles:Even if you go for an uneven LTS strategy, not every company may migrate every 2 years (or less), that is just not true. Large projects may need to invest for 1 full year for the implementation, not sure it's appealing to invest 20% of the implementation cost the next year to migrate immediately. The newer the version you migrate too, the more expensive it will be as you will eventually need to migrate the OCA modules yourself or even dig into the early OpenUpgrade bugs/limitations. A company can have a bad year, the integrator may not be available. The market is growing a lot, lots of new integrators have just not the experience to be able to migrate 1 or 2 years after they started their 1st projects where they likely did a lot of shit...As soon as you admit this, having secure versions for only 3 years before being forced to migrate is not appealing at all. I think 4 years (2 LTS cycles) would be a wiser stance.A business opportunity for the OCA?Since Odoo SA says they take care of security for only 3 years, eventually this gives room for the OCA to brag "the OCA ensures the security patches from recent Odoo releases are backported for 4 or 5 years". We may not promise it's all secure, but IMHO promising this backport is cheap and may drive more audiences to the OCA.About Odoo SA trying to please the VCs.It has been very true in the past and eventually shaped the released cycle. But we know it's no longer true: despite nearly losing control to the VCs back in 2015 (as Fabien admits himself that had only 2 month of cash if they didn't made the last VC round where they had to change the license and start doing proprietary code), they now managed to get totally independent from them again. Eventually we were pissed of by the risk taken while we didn't choose open source for that kind of risk. But it's over now. That being said, Odoo SA is now a company with many salesmen and managers, sort of unproductive people and consequently they need to sell new projects like mad to feed everybody. So eventually they are structurally doomed to keep riding the rocket.About security and Python versions:again IMHO the OCA is not wise when it follows Odoo SA Python version policy, like have the v14 CI run Python 3.6 (end of life next year). Because what we see with the Odoo CVE also just happens in the Python packages we depend on. In new fields like web, API connectors, ecommerce, SOAP... Python packages come and go, replaced by newer technologies. Newer packages use recent Python versions and loose compatibility with older Pythons. Hence if you use an old Python, chances are your Python packages have much more CVE that will not get fixed, not even for a newer Python (a new lib might be used instead). IMHO, Odoo SA supports older Pythons by accident because they come from legacy, But just because they support it by accident is not a good reason for the OCA to align to this policy. We don't run the CI on windows just because Odoo SA also make Odoo instalable on Windows, right? So why cannot we say: "you want Odoo 14? The OCA CI ensures it works on Python 3.7+, so evolve your distro before starting your real life project, doing that may give you 1 extra year of CVE free packages in the future."About web enabled ERP and security:We have to face it: how many not up to date Odoo ecommerces and portals are there around in the wild? Now think about how easy it is to take the CVE list of Odoo and of its old Python dependencies and scan the web to attack these older Odoos? Think how hard it is to migrate and how naive were some companies to do an Odoo ecommerce before understanding this. Think if company X has an unfair competitor Y ready to pay a hacker to use these CVE to attack the old Odoo, think how easy it is to take over the company X data or even spoil its ERP... At Akretion this is the kind of reasoning we had before building Shopinvader for instance.Regards.On Thu, Dec 31, 2020 at 11:12 AM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:For me the path is clear: upgrade to the latest possible Odoo version, and that's why OpenUpgrade is done and funded by OCA itself, and the most famous OCA modules are migrated to all versions by regular contributors.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
by Juan Del Castillo Gómez - 03:01 - 2 Jan 2020