Hi Guewen,
Thanks for replying and sorry for my late reply, the notification got junked.
We completely uninstalled the module via the uninstall option (which removed db
entries and deleted the respective addons folder)
No there is no result section, the job just shows as ‘done’. Requeue the
2 things that you must *never ever* do:
- uninstall a module with data: you may have screwed your database
since it removed all the columns and data owned by the connector
- install or upgrade modules using the 'Apps' menus, it would copy a
version of the connector in a server folder instead of
Hi, Guewen, count with me to help in the transition.
Regards.
2014-06-21 14:09 GMT+02:00 Bidoul, Stéphane stephane.bid...@acsone.eu:
Hi,
Some comments about migration strategy below.
On Fri, Jun 20, 2014 at 3:08 PM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
The
Thanks for sharing, we'll have a look
On Sat, Jun 21, 2014 at 7:50 AM, David Arnold - El Alemán da...@elaleman.co
wrote:
*Hi Community*
*Hi Publisher*
some time ago, there has been this discussion about the code review
process. I ignore the status of the discussion, but I just stumbled
Hi,
First thank you for your feedback. About the LP - Github migration. The
main arguments in favor of keeping v 6.1 and 7.0 on LP and mirror on Github
is that we do have lot's of reviews in progress. It'll be difficult to
maintain reviews on LP if the master is Github.
Moreover, the
Hi!
I am still convinced it would be somewhat less painful to have 6.1 and
7.0 in github, too.
Existing MPs scare me less, since it's a one-time problem, and it's
easy to spread the work: each person can take care to duplicate their
own MPs to github, so there is no enormous task or management
Hi all,
I create a new thread to avoid hijacking the other discussion with
this temporary issue.
I was wondering about what is the best way to work on v8 OCA modules
today, i.e. before a decision has been taken on how to handle them.
As an example, I would like to forward port the module
Hello,
my suggestion is:
1) do v8 dev on Github only and as soon as we have our new branches.
2) do business as usual for some time on 6.1 and 7.0 on LP while we still
work marginally on v8 and while we still have most of MP on LP with 6.1 and
7.0 MP.
3) then, as people will transition to v8, the
Hi Leonardo,
Thanks for pushing this topic. It is on the way to decide what to do, but
the process is launched and leaded by Guewen.
I tend to think that if you create you own branch, not sure you can then
make a pull request on the official branch because the parent will not be
the same... But
On Mon, Jun 23, 2014 at 12:48 PM, Joël Grand-Guillaume
joel.grandguilla...@camptocamp.com wrote:
I tend to think that if you create you own branch, not sure you can then
make a pull request on the official branch because the parent will not be
the same... But I'm not sure. In the worst case,
On 06/23/2014 11:16 AM, Joël Grand-Guillaume wrote:
Hi,
First thank you for your feedback. About the LP - Github migration.
The main arguments in favor of keeping v 6.1 and 7.0 on LP and mirror
on Github is that we do have lot's of reviews in progress. It'll be
difficult to maintain reviews
On Mon, Jun 23, 2014 at 12:58 PM, Lorenzo Battistini
lorenzo.battist...@agilebg.com wrote:
On 06/23/2014 11:16 AM, Joël Grand-Guillaume wrote:
Hi,
First thank you for your feedback. About the LP - Github migration. The
main arguments in favor of keeping v 6.1 and 7.0 on LP and mirror on
On Mon, Jun 23, 2014 at 12:04 PM, Leonardo Pistone
leonardo.pist...@camptocamp.com wrote:
Hi!
I am still convinced it would be somewhat less painful to have 6.1 and
7.0 in github, too.
Existing MPs scare me less, since it's a one-time problem, and it's
easy to spread the work: each person
Il 23/06/2014 12:58, Lorenzo Battistini ha scritto:
On 06/23/2014 11:16 AM, Joël Grand-Guillaume wrote:
Hi,
First thank you for your feedback. About the LP - Github migration.
The main arguments in favor of keeping v 6.1 and 7.0 on LP and mirror
on Github is that we do have lot's of
I started to work on the tools:
https://github.com/OCA/maintainers-tools
The first script is the one that copies the members of the maintainers
team to the other teams.
The branch also contains a function to login on GitHub using a token,
that should be shared by all the other scripts.
The other
HI,
I am also in favor of an earlier migration to github. We are a community,
and as such I would like to avoid introducing processes and tools that
would be specific OCA. The greater part of us probably have enough
experience to continue with both systems and even if IMHO it will introduce
a lot
Hello,
+1 with full migration to github... with scripts.
In github you will have new runbot available with PR for test it.
In github you will have just one tool of version control.
And you can make some script to migrate base branches and merge proposal
branches.
Note, in old runbot refactory by
On Mon, Jun 23, 2014 at 3:32 PM, Moises Lopez moylop...@vauxoo.com wrote:
Hello,
+1 with full migration to github... with scripts.
In github you will have new runbot available with PR for test it.
In github you will have just one tool of version control.
And you can make some script to
Ok, I agree on the principle as well (moving to github with mirroring on
LP). I let the responsiblity to gather the opinions and take the decision
to you Guewen.
On Mon, Jun 23, 2014 at 4:00 PM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
On Mon, Jun 23, 2014 at 3:32 PM, Moises
On the topic of Runbot.
Here at SLF, I have managed to deploy it for our own uses.
I am sure many of you have read it already but for those who didn't here's the
result of my experiment[1].
Since then, I have made an addon to runbot which gives more customisability to
what runbot runs, mainly
On Mon, Jun 23, 2014 at 6:37 AM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
On Mon, Jun 23, 2014 at 12:04 PM, Leonardo Pistone
leonardo.pist...@camptocamp.com wrote:
Hi!
I am still convinced it would be somewhat less painful to have 6.1 and
7.0 in github, too.
Existing
Hi there,
Since new branding name Odoo appeared and OpenERP 8 is available too, I'd
like to know a few things:
1. Odoo and OpenERP will be the same piece of code on the same development
place (https://github.com/odoo/odoo)?
2. Will Odoo keep working the On Premise version available for download
Thank you Raphael! I'm on the edge of understanding ;) After further
research, I would even consider my previous question obsolete, as all
(relevant stuff) that fields.property() does is implement a company_id
statment on a domain search.. This company_id-domain search however is in
my case
Another Idea:
Couldn't there be a company_id field as a many2many field or is this
incopatible with the core rutoines on company_id fields? Like this every
object could be individually assigned to various companies in a flexible
way.
I'm sure though I missed something.. ;)
Hi David,
I thought about adding pep8 checking.
Though it is possible, the design of runbot does not exactly make this easy,
and since we already have travis doing this, I have not made it a priority.
In the official runbot code, there is some commented out coverage code, so they
have obviously
Hi Sandy,
You're right. I think the way out is to create a new project/repository
called runbot (any other suggestions ?) under the responsibility of the
Maintainer team. This way you can push the needed community addon repo.
What do you think ? For me, it makes sense and I agree we don't want
I do not have the rights to add repos to OCA, but runbot-addons has a nice ring
to it ;)
--
Sandy
- Mail original -
De: Joël Grand-Guillaume joel.grandguilla...@camptocamp.com
À: Sandy Carter sandy.car...@savoirfairelinux.com
Cc: Moises Lopez moylop...@vauxoo.com, openerp-community
@Sandy,
In old-runbot we make a change for add pylint custom error.
TODO: Changes in new-runbot
pylint make critical errors, example undefined variable.
and make wishlist errors like pep8
A cool IMP should be, make a list of error's that you want test it,
repository by repository.
Example:
Raphäel, David:
I really believe we should not fall in love with Odoo, so hard than we try
to explain everything in a Odoo compatible way.
Taxes are part of legislation. And in all countries I know, they are
organized in three levels: Federal or nationals, Federal States and local
(Municipal).
*comments in plain red*
2014-06-23 18:34 GMT-05:00 Gustavo Adrian Marino gamar...@gmail.com:
Raphäel, David:
I really believe we should not fall in love with Odoo, so hard than we try
to explain everything in a Odoo compatible way.
Taxes are part of legislation. And in all countries I
Last but not least, this concept is at least configurable by an accountant.
So far we oftentimes see hard coded concepts that are only configurable by
developers. I acknowledge that with the pace of changing tax jurisdiction
in south america this might be a sustainable resource of income.
But it
On 2014-06-23 17:45, David Arnold - El Alemán wrote:
I see this mailing list as a somewhat ineffictient tool to organize
discussion (and there are very valuable ones!).
As a 'hardliner fireplacer' I'd want to see a superior system before
supporting a switch. Never have yet.
Comments in
*Hi*
if we compare the statistics in odoo on issue categorizing and issue
resolution compared to other high volume projects, a benchmark
automatically might come to our mind.
I'm personally not able to set something up, but I want to drop this, in
order to strategically help crafting a healthy
2014-06-23 21:02 GMT-05:00 Martin Collins mar...@mkcollins.org:
Looks green to me. The main problem I see with mailing lists is most
people don't know how to use them properly anymore. I admit the large
body of netiquette required for maximum effectiveness is not all
self-evident, and many
I don't understand exactly what is the point David?.
FYI, we had this kind of info available from launchpad
https://docs.google.com/a/openerp.com.ve/spreadsheet/ccc?key=0Al2dk8YmCgI0dDRRMnVwX3JKTUpuS3V2NW13RF9EVXcusp=drive_web#gid=66
(not as cool as github) but we had it.
2014-06-23 21:32
2014-06-22 23:10 GMT+02:00 Alex Comba - Agile BG alex.co...@agilebg.com:
Lorenzo,
please have a look at my last commit, now it should be ok.
Thanks Alex,
maybe we could handle even more particular cases by using the address_get
method to retrieve the company?
--
Review: Needs Fixing
Hi
You don't have to test if available_option.mandatory is True but you can only
use if available_option.mandatory as it's a boolean the is True is useless.
--
@sebastien,
fix done, thank you for review
--
https://code.launchpad.net/~akretion-team/carriers-deliveries/7-split-default-option-state-from-deliv-method-dbl/+merge/224027
Your team Stock and Logistic Core Editors is subscribed to branch
lp:carriers-deliveries.
--
Mailing list:
Review: Approve code review, no test
LGTM
--
https://code.launchpad.net/~akretion-team/carriers-deliveries/7-split-default-option-state-from-deliv-method-dbl/+merge/224027
Your team Stock and Logistic Core Editors is subscribed to branch
lp:carriers-deliveries.
--
Mailing list:
Review: Approve code review
Hi, David, thanks for the improvement.
You have to change module version number and provide a proper migration script
for those that have previously the module installed.
Regards.
--
Review: Needs Fixing code review, no tests
Never used it, code looks shaggy, and there are not tests.
Are there known issues?
In it's current state, this module is not on par with the standards of OCA and
it needs care and love.
If someone has use for this module and is volunteering to
Hi Pedro
module is renamed and ready for merge
Thank you
Regards
--
https://code.launchpad.net/~akretion-team/partner-contact-management/7.0-partner-helper-dbl/+merge/221501
Your team Partner and Contact Core Editors is subscribed to branch
lp:partner-contact-management.
--
Mailing list:
Review: Approve code review
Great, thanks.
Regards.
--
https://code.launchpad.net/~akretion-team/partner-contact-management/7.0-partner-helper-dbl/+merge/221501
Your team Partner and Contact Core Editors is subscribed to branch
lp:partner-contact-management.
--
Mailing list:
Katja Matthes has proposed merging
lp:~initos.com/sale-reports/7.0-fix_lang_for_draft into lp:sale-reports.
Requested reviews:
Sale Core Editors (sale-core-editors)
For more details, see:
https://code.launchpad.net/~initos.com/sale-reports/7.0-fix_lang_for_draft/+merge/224106
Steps to
Katja Matthes has proposed merging
lp:~initos.com/account-invoice-report/7.0-fix_lang_for_draft into
lp:account-invoice-report.
Requested reviews:
Account Core Editors (account-core-editors)
For more details, see:
Review: Needs Fixing code review
Hi, Katja,
You're right that current code doesn't work, but this is because the line that
made the work is incorrect:
try :
lang = self.browse(cr, uid, inv_id).partner_id.lang
inv_id is an id, not a list of ids, so you don't need to put index 0 to access
Review: Needs Fixing code review
This is the same as the other MP you have made
(https://code.launchpad.net/~initos.com/account-invoice-report/7.0-fix_lang_for_draft/+merge/224109),
so please change it in the same way.
Regards.
--
Migrate script works for me.
I think it could merge
Only miss Yannick review
--
https://code.launchpad.net/~akretion-team/carriers-deliveries/7-split-default-option-state-from-deliv-method-dbl/+merge/224027
Your team Stock and Logistic Core Editors is subscribed to branch
setting the MP as work in progress. Please set it back to needs review when
requested changes are made.
--
https://code.launchpad.net/~alejandrosantana/account-financial-tools/7.0-account-financial_tools--add--account_account_extended_search/+merge/200092
Your team OpenERP Community
Review: Needs Fixing code review, no tests
If people are willing to maintain this, then I'm not opposed to merging in
server-env-tools.
2 points, though, to gain my approval:
* the various size constraints seem overzealous to me (esp. server URL and
domain which are obviously too short for
Review: Needs Fixing
I would really love to see this code exercised by a couple of yaml tests...
--
https://code.launchpad.net/~pedro.baeza/account-financial-report/6.1-balance-reporting/+merge/201166
Your team Account Report Core Editors is subscribed to branch
Hello Alexis, many thanks for the module.
What do you think about creating the res.country.state records if they don't
exist, before mapping them in the 'states' dictionary?
The current version is supposed to correctly work with states if you first
create states data by modules like
52 matches
Mail list logo
