Community mailing list archives
Re: Unexpected diffrences between Odoo Enterprise and Odoo Community interfacesby
I agree with Andreas and he is making a good point here. Just like any other open source software project Community and Commercial (subscription basis) the core version are always similar. The advantage of Commercial is that the support is there and the people behind it are readily available.
On Sunday, 24 April 2016, Andreas Becker <email@example.com> wrote:
With every difference in code between Enterprise and Community Edition both versions are drifting away from each other and Enterprise customers will have to deal with vendor login methods to bind them to the Enterprise Version - which is a yearly subscription service. Sad. Switching back to community Version will be getting more and more difficult.Though they should better start with the community Version right from start and get features they like from Enterprise be done in the community Version. Only than they will be able to calculate long term and can make sure that their data and features also be available later in Community Version without a headache of getting data back from Enterprise to Community after they stopped paying for the Enterprise Version.It would actually be good if there would be a list of differences in code between both versions. Like it has been said already some stuff is easy to fix but some probably not and it might break stuff!Is the OCA taking care that the differences between both versions are not getting into the core affecting the community Version?On Sun, Apr 24, 2016 at 3:22 AM, Pedro Manuel Baeza Romero <firstname.lastname@example.org> wrote:Regards.Nhomar, I think you are mixing the functionality of the module with the issue told by Jerome. His problem is not with the Google Drive API (although you may be right), but placing a menu in the toolbar for enabling the functionality, and he is saying that the elements in both versions are not referred the same (with the only tag attribute that he can use - class -).Please correct me if I'm wrong, Jerome.2016-04-23 22:15 GMT+02:00 Nhomar Hernandez <email@example.com>:On Sat, Apr 23, 2016 at 2:42 PM, Jerome Sonnet <firstname.lastname@example.org> wrote:Can you be more specific as why my design is wrong ? Google provides a JS API that works quite well and I don't see why I should go through the server in order to do this ? I am actually using the ir_attachement ORM, but when I do have to URL and the name to use, see .
Basically (IMHO it is a matter of PoV not Wrong and Good).gdrive has a python api which is part of the official dependencies also:Then if I understand correctly, your module want to save always attachments on gdrive (given some proper IF statements), why did not you simply overwrite on python sime 6 lines of code per CRUD element on server side?:Benefits:1.- ORM will secur for you the relation with the attachment.2.- NO parallel processing with different logic than the ORM itself.3.- 0 js code ;-)Then it is a matter of perspective but to give a proper behavior of what you describe in your descriptor (which sound nice) I think the correct approach is overwrite properlly the core methods ot impact ocnssitently 100% of attachments features....Read the doc of those methods IMHO the talk by themselves.You can see a fairly simple implementation but using S3 from amazon here:It needs refactor for v9 and some proper configuration interfaces and more pythonistic code but technically it is a clean implementation.Regards
Sent from OSS Tech iPhone