[Openerp-community] [Merge] lp:~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0 into lp:openobject-client-web/6.0
Ronald Portier has proposed merging lp:~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0 into lp:openobject-client-web/6.0. Requested reviews: OpenERP Core Team (openerp) Related bugs: Bug #768918 in OpenERP Web Client: "error in evaluating view domain" https://bugs.launchpad.net/openobject-client-web/+bug/768918 For more details, see: https://code.launchpad.net/~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0/+merge/58799 -- https://code.launchpad.net/~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0/+merge/58799 Your team OpenERP Community is subscribed to branch lp:~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0. === modified file 'addons/openerp/utils/tools.py' --- addons/openerp/utils/tools.py 2011-02-17 16:25:59 + +++ addons/openerp/utils/tools.py 2011-04-22 11:56:35 + @@ -46,6 +46,7 @@ datetime=datetime, relativedelta=relativedelta) if isinstance(string, basestring): +string = string.strip() try: value = eval(string, context) except: ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
[Openerp-community] [Merge] lp:~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0 into lp:openobject-client-web
Ronald Portier has proposed merging lp:~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0 into lp:openobject-client-web. Requested reviews: OpenERP SA's Web Client R&D (openerp-dev-web) Related bugs: Bug #768918 in OpenERP Web Client: "error in evaluating view domain" https://bugs.launchpad.net/openobject-client-web/+bug/768918 For more details, see: https://code.launchpad.net/~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0/+merge/58800 -- https://code.launchpad.net/~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0/+merge/58800 Your team OpenERP Community is subscribed to branch lp:~openerp-community/openobject-client-web/ronald@therp.nl_lp768918-6.0. === modified file 'addons/openerp/utils/tools.py' --- addons/openerp/utils/tools.py 2011-03-02 15:05:11 + +++ addons/openerp/utils/tools.py 2011-04-22 11:57:51 + @@ -48,6 +48,7 @@ datetime=datetime, relativedelta=relativedelta) if isinstance(string, basestring): +string = string.strip() try: value = eval(string, context) except: ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
[Openerp-community] [Merge] lp:~openerp-community/openobject-client-web/ronald@therp.nl_lp768918 into lp:openobject-client-web
Ronald Portier has proposed merging lp:~openerp-community/openobject-client-web/ronald@therp.nl_lp768918 into lp:openobject-client-web. Requested reviews: OpenERP SA's Web Client R&D (openerp-dev-web) Related bugs: Bug #768918 in OpenERP Web Client: "error in evaluating view domain" https://bugs.launchpad.net/openobject-client-web/+bug/768918 For more details, see: https://code.launchpad.net/~openerp-community/openobject-client-web/ronald@therp.nl_lp768918/+merge/58802 -- https://code.launchpad.net/~openerp-community/openobject-client-web/ronald@therp.nl_lp768918/+merge/58802 Your team OpenERP Community is subscribed to branch lp:~openerp-community/openobject-client-web/ronald@therp.nl_lp768918. === modified file 'addons/openerp/utils/tools.py' --- addons/openerp/utils/tools.py 2011-03-02 15:05:11 + +++ addons/openerp/utils/tools.py 2011-04-22 12:36:35 + @@ -48,6 +48,7 @@ datetime=datetime, relativedelta=relativedelta) if isinstance(string, basestring): +string = string.strip() try: value = eval(string, context) except: ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] Email usability improvements
Hello, I basically agree with everything Eric Caudal wrote. I might add a few shortcomings as well. With Therp we developed one approach and module as a partial work-around. But so far only for 6.1. - One thing we encountered, already with 6.1, is that mails are retrieved from imap based on whether they have been seen (=read) or not. Result is that when users use any other mechanism to look at their mail, for instance Thunderbird or other mail client, the mails will never be retrieved by OpenERP. - Another one: also for special e-mail accounts (for instance to receive incoming invoices, of issues from customers) a lot of irrelevant messages will be received. From spam to out-of-office replies. Just blindly creating objects for those (account.invoice, project.issue) will pollute OpenERP very quickly. - A third one - we still have no workaround for this - is that sometimes e-mails are linked to leads. Or to prospects. Then they become customers. But the email traffic with leads and/or prospects it not seen under customer, therefore is incomplete. In 7.0 I noticed a weird distinction between mail.mail and mail.message. Incoming mail will be put in mail.message, which has a very limited form, making it impossible to really look at the contents and attributes of the mail. After working for some time with e-mail in OpenERP, we decided that by itself it was never going to work. People need all the functionality of their full e-mail clients. Still it is useful, or often necessary, to have a full view of e-mail correspondence with clients. Also integration between OpenERP for example for sending out invoices, or receiving issues, is very useful. The method we came up with was to let users use their normal mail client - whatever client they prefer - to send or receive e-mails. But then synchronize imap folders with OpenERP. So if an email is for or from a customer, it can be put in a folder customers. If an incoming mail is an invoice (for something we purchased), it can go into a folder invoices. So the user decides really what the nature of an e-mail is, and where it should be put in OpenERP. In this way we have the best of both worlds, the full functionality of modern email clients, with full integration with OpenERP. The fetchmail_attach_from_folder module is part of server-env-tools/6.1. It has not been upgraded to 7.0 yet. I invite people that are interested to have a look at this module, developed by my colleague Holger Brunn. Functionally the main thing still missing is adding mails send from OpenERP to imap, to have a complete synchronization. Kind regards, Ronald P.s. also in server-env-tools a very small module made by me to give normal users access to the email views: mail_client_view. W. Martin Borgert schreef op 11-10-13 19:34: > Quoting "Eric Caudal" : >> Here are the functionalities that we missed out of the box: > [your valid points removed here] > > - no useful handling of attachments when receiving mail, one cannot >click on an image attachment and it just opens etc. (I assume, >there is no MIME handling at all) > > - document attaching when sending mail is missing any re-use of > documents, e.g. one can only attach external files, that than are > added to the document store, but no re-use documents > > - no way of deciding to send a text-only (non-HTML) email > > - no spam filter support for receive emails > > - no global auto attachment for all outgoing email (e.g. company > vcard) > > - no original text when (typically indented with '>') replying, > at least not in project issue > > - no globally configurable cc/bcc addresses for certain domains > (e.g. add support person to all outgoing emails from helpdesk) > >> - Are there out there other partners/customers willing to invest in >> improving the ergonomic of OpenERP for the emailing system (again >> getting it a simple but reasonable webmail interface)? > > I hacked for my own purpose in the email module, adding support > for spam filter, auto attachment of vcard, global cc/bcc. But > this is not really helpful for anybody else, I fear. No problem > in sending you my changes anyway, but you don't want them :~) > > Making a good web mail interface is hard. Some people say, Google > did it not so bad, but I never really tried it. Wouldn't it be > better to integrate better with existing email infrastructure, > whatever people are used to use? So that people can just use their > Thunderbird or MS-Outlook or whatever? > > Cheers > > > ___ > Mailing list: https://launchpad.net/~openerp-community > Post to : openerp-community@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp -- Met vriende
Re: [Openerp-community] Proposal to improve communication and make more efficient the inclusion of new branches.
Hello, Don't know where runbot is taking its branches from, but the ocb branches are completely outdated. I should have been a warning that both the current level tested, and the tests of 20 days ago are testing the same revisions. For instance tested ocb server revno is 5109, while current revno is 5122. For addons this is 9545 and 9607 respectively. Kind regards, Ronald Fabien Pinckaers schreef op 24-10-13 18:36: > IMHO, the emergency for OCB branches is to fix bugs that have been > introduced in these branches. > > I am not sure if it's tracking the right branches, but it looks like the > OCB branches are red on runbot: > http://runbot.openerp.com/ocb.html > > Also, I would suggest every contribution to follow the runbot naming > convention so that feature branches are also tested. This simplifies the > merge proposal review a lot because you can: > - test functionalities online > - check that the branch is still green > > The rule we use for official modules is to never merge a branch that > breaks automated tests. > > On 10/23/2013 07:28 AM, Quentin THEURET wrote: >> Le 23/10/2013 01:03, Nhomar Hernández a écrit : >>> Hello. >> Hello, >>> >>> In the las days, we are seeing a really big increase in the proposal >>> to include new branchs/modules on the Community / OCA branches. >>> >>> It is one of the best moments of the community, we must continue in >>> this way. >> I'm happy to see that. It proves that community has a good future ! >> >>> BTW, when thing start to become big, we need to act fast, then, I >>> propose that the inclusion of Modules/Branches should be followed by >>> an explanation in a correct way, in the MP or in the Commit Message >>> or in the OCA site >> I think it's a good way to document all new proposals and know why we >> include this module in this project. >> >>> >>> But as everybody know the "Correct" way can be subjective, to avoid >>> this subectivity, I propose use a "Format" already known may be >>> modigied with our reality, it is the format that the Python Foundation >>> use: >>> >>> Here an example really new: >>> >>> http://www.python.org/dev/peps/pep-0453/ >> I read this. But, who should write these documents ? I don't think that >> the community has time to write these things. May be some developers >> will develop their own branches to avoid to write these documents before >> asking for a merge. And we could lost some good modules… >> We shouldn't make the new comers afraid because of that. >> >> The format to respect is IMHO too complicated according to our >> community. The OpenERP community is not larger as Python community… If >> the community is agree with this concept, we should make a simplest >> "format". >> >>> Before end I just want to say it is just an Idea, if we have a >>> agreement, We can invest more time in investigate more deeply, what >>> Tools/Concepts/Formats/Process should be involved, and share with you >>> our conclusions. >> >> I let other community members to give their point of view, because I >> think it's an important thing but we can't made a mistake on this if we >> want that all of us (and new comers) respect this "format". >> >> Regards, >> > > -- Met vriendelijke groet / Kind regards, Ronald Portier /"\ \ / X / \ ASCII Ribbon campaign against HTML E-Mail ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] Proposal to improve communication and make more efficient the inclusion of new branches.
Personally I think that if the official branches are made less strict, in the sense that they accept database changes needed to resolve bugs, then there should be no problem to proceed along the lines proposed by Olivier. I think most people who contribute features and fixes to the stable branches are well aware of the need to avoid database changes wherever possible. But I fear that having an "experimental" OCB branch in the official projects, alongside a "conservative" branch, will just make things complicated. Experiments can (and should) go into all kind of directions. An officially approved experimental branch sounds a little bit like a contradictio in terminis to me. Just some thoughts that occured to me reading the discussion Kind regards, Ronald Olivier Dony schreef op 25-10-13 18:09: > On 2013-10-25 16:44, Stefan wrote: >> On 10/25/2013 04:21 PM, Olivier Dony wrote: >>> >>> Only a few obstacles remain before this can become a reality: >>> 1/ The OCB branches would need to be relocated under the official >>> projects >>> 2/ The OCB branch management process needs to be adapted accordingly >>> 3/ Compliance with the OpenERP stable policy [2] should be added to >>> the review checklist for OCB branches, and the current branches >>> reviewed in this light >>> 4/ (Option) In order to allow for some degree of non-compliant >>> changes, an "experimental" version of the OCB branches could be >>> forked. It would not be recommended for production and not merged back >>> into the official distribution. >>> >>> Stefan, does this accurately describe the options we discussed? >>> >> >> Thanks Olivier, for highlighting your intentions in this direction again. >> >> My personal gripe is with [3]. I think having an 'unstable' series that >> does allow the occasional new field to percolate through is a major >> attraction to OCB. It must be the reason that I remember our >> conversation at the community days slightly differently: keep the OCB >> branch in its current form with its current policy, but using technical >> means to mark merged changes that conform to the OpenERP stable policy >> so that you can easily feed back bugfixes from OCB to the official >> series. We have not yet had the chance to work this out. > > I understand that you may see non-compliant changes as a desirable > feature of the OCB branches. And that does not preclude having them in > the official projects and tracking them in runbot as well, of course! > > Unfortunately I would have the same problem as Lionel if we can't simply > merge the branches after reviewing the diff. If the process becomes too > time-consuming or technically impractical for us we won't be able to > dedicate resources to do it. It also seems that cherry-picking commits > will increase the chance of conflicts when you auto-merge those commits > back into the OCB branches. That's one of the reasons why I thought we > had discussed the creation of 2 versions of the OCB branches: > - one stable version very close to the official branches (i.e. a few > commits ahead) > - one experimental version with extra commits for technical people who > know exactly what they're doing and don't mind diverging from the > official version. > > Note that you could perhaps modify your OCB scripts to automatically > maintain the "stable OCB branch" based on the "experimental" one with > some commit tags, but that may be overkill. > > On a related subject, I was also wondering about the future of those > divergences from the official version once a new OpenERP release is out. > Based on OpenERP's architecture I imagine the easiest would be to move > them to appropriate community modules? > > >> As for hosting the series branches under openobject-addons, that would >> be great. I'll gladly give up the separate projects for the ease of >> having to prepare only a single branch and MP for each fix. > > Great! > > ___ > Mailing list: https://launchpad.net/~openerp-community > Post to : openerp-community@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp -- Met vriendelijke groet / Kind regards, Ronald Portier /"\ \ / X / \ ASCII Ribbon campaign against HTML E-Mail ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] The Future of the Point of Sale
Just for your information: One of our customers has given me the demands they will have for a POS solution: - Support for a large number of products: > 16.000 - Pricelist depending on customer - Payment by invoice I think the demand to support a large number of products should be supported out of the box. I can imagine the other demands to be customer specific. Like each customer will have their demands/wishes. So easy extensebility/customization of the POS might be the number one requirement. Kind regards, Ronald Eric Caudal schreef op 30-10-13 02:07: > I have 1.6 billions Chinese here using their RFID ID card to buy their train > ticket! Can we start using it in OpenERP ;) > > More seriously, main demands on my side are: > - possibility to switch vendor in safety way (enter a password or swipe a > rfid/barcode card) > - VIP card management for points management AND prepayment (you load your > card > by credit card) > - Prepaid Gift certificates (unique number previously generated to be swiped > via > barcode or RFID) > - Possibility to have a 2-step sale (one shop keeper prepares the sale one is > checking out) > > Probably asking too much but: > - Promotion/message (appearing on ticket) based on VIP card holder. > - Special message when VIP card holder (birthday, attentions, etc...) > > > Eric CAUDAL > > Eric Caudal > /CEO/ > -- > *Elico Corporation, Shanghai branch > /OpenERP Premium Certified Training Partner/ * > Cell: + 86 186 2136 1670 > Office: + 86 21 6211 8017/27/37 > Skype: elico.corp > eric.cau...@elico-corp.com <mailto:eric.cau...@elico-corp.com> > http://www.elico-corp.com > > Elico Corp > On 10/29/2013 11:28 PM, Stefan wrote: >> On 10/29/2013 04:04 PM, Peter Langenberg wrote: >>> Alan, >>> >>> You even drive on the wrong side of the road ... can't consider you as >>> generic ... >>> >>> UK is not in the EU, ask Cameron :-) >> >> Yes Peter, but while both your country and mine are near enough to still >> cling >> on to the shameful tradition of 'blackface' Pete accompanying our fork of >> Santa Claus, I never heard of such a card either... >> >> Cheers, >> Stefan. >> >> >> ___ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : openerp-community@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp > > > > _______ > Mailing list: https://launchpad.net/~openerp-community > Post to : openerp-community@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > -- Met vriendelijke groet / Kind regards, Ronald Portier /"\ \ / X / \ ASCII Ribbon campaign against HTML E-Mail ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] [Merge] lp:~therp-nl/openerp-product-attributes/7.0_lp1272282_fixed_price into lp:openerp-product-attributes
Review: Resubmit I tried to take most remarks into account. I refer to the commit messages. Two things - I prefer having a separate file for each model created or modified. One of the big annoyances in working with the code in OpenERP in my experience is how everything is lumped together in monster .py files. grep is our friend ofcourse. But why for example is res.partner modified somewhere after 1800 (!) lines of code in account_invoice.py? The java community has had the convention of "one class per file" for ages, and that is working out perfectly. - I did not add an editable list view for the moment. This is just for lack of time. Might add it in the future. -- https://code.launchpad.net/~therp-nl/openerp-product-attributes/7.0_lp1272282_fixed_price/+merge/203348 Your team OpenERP Community is subscribed to branch lp:openerp-product-attributes. ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Re: [Openerp-community] [Merge] lp:~therp-nl/openerp-product-attributes/7.0_lp1272282_fixed_price into lp:openerp-product-attributes
@Pedro I do not quite understand why you put 'need fixing'. As far as I understand, the module now does everything you and others asked for. OK, I make fields read-only instead of completely hiding them. But what else would you like to be different? -- https://code.launchpad.net/~therp-nl/openerp-product-attributes/7.0_lp1272282_fixed_price/+merge/203348 Your team OpenERP Community is subscribed to branch lp:openerp-product-attributes. ___ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
