openerp-community team mailing list archive

["jeff.wang" <jeff@xxxxxxxxx>]

Hi Antony,

>> We are also converting all the rml reports into html views

I am really interest on this topic, can you describe more details about it ?

------------------
Jeff Wang |  jeff@xxxxxxxxx | 18016291663 | 02158980787
@OpenERP_Jeff "As simple as possible, As complex as needed"
                    
      Maintainer of Open ERP china community  
      http://www.openerp-china.org 


 




------------------ Original ------------------
From:  "Antony Lesuisse";<al@xxxxxxxxxxx>;
Date:  Sat, Nov 9, 2013 09:29 PM
To:  
Cc:  "openerp-community"<openerp-community@xxxxxxxxxxxxxxxxxxx>; 
Subject:  Re: [Openerp-community] Status report on OpenERP CMS branchtrunk-website-al....



huh, what are rambling about ?

Did you try the trunk-website-al branch, we want to provide all the tools to 
easily build the front-end part (website) of the openerp apps.

We did it for some of our apps, such as sale and event. You just need create 
the relevant controllers and views, it's straightforward. With this branch 
OpenERP become a full web application framework, while maintaining all its 
modular aspects (view, model and controller inheritance).

We are also converting all the rml reports into html views (we continue to use 
webkit to generate the pdf versions), those html views are extensible using 
the xpath mechanism, ie you can easily add a column on the SO by extending the 
report. The branch can be found in trunk-qweb-report ATM only 20 reports are 
currently converted.

I might be wrong, but it looks, to me, that this branch will obsolete your 
work on aktoor, except for projects where people want to mix two frameworks, 
openerp/python and rails/ruby.

Avoiding mixing frameworks was one of the key motivation behind the project, 
as i believe that the more unnecessary layers, the more bugs. OpenERP is now 
schematically HTTP (session, db matching, auth) -> Controllers (using html 
views) -> ORM. All the security is handled by the ORM we dont trust views nor 
controllers.

The changes to OpenERP are minimal: we introduce a new ir.ui.view type, the 
controllers layer has been improved (already in trunk) and that's it. Website 
define a new public user (like anonymous) this user is used when you are not 
loggued. Please check out the code.

And now the shocking news: as the project is now in bugfixing mode, we will 
start to write the documentation, and lower the barrier to developement with 
an easy quickstart guide and some scaffolding tools. The reason is that now we 
have a full stack framework we want to make it more friendly to newcomers. 
Documentation is now an high priority project, everybody can rejoice :)


On 11/08/2013 08:56 PM, Raphael Valyi wrote:
> On Fri, Nov 8, 2013 at 5:23 PM, Mario Arias <the.clone.master@xxxxxxxxx
> <mailto:the.clone.master@xxxxxxxxx>> wrote:
>
>     Fabien, Antony...
>
>     Great job so far!
>
>     Quick questions...  we will need some kind of "light user" for web
>     customers, so they can eventually check order status, RMAs, enrollment to
>     events...
>     They won't have access to the full system as they will be limited to
>     website front end...  similar to "portal" users...
>
>     Do you already have this in your roadmap?
>     How will they count towards monthly cost of OPW ?
>
>
> Hello Mario and others,
>
> notice that technically  speaking, using OOOR and AKTOOOR
> https://github.com/akretion/aktooor you can achieve that "light user" thing.
> The website I'm building will have thousands of users interacting with
> OpenERP, but only a few dozens of ERP users at most.
>
> The way it works is that a web user is a Devise user
> https://github.com/plataformatec/devise
> potentially using a different database (or not) of OpenERP.
>
> Then by overriding OOOREST authentication method, you map a logged Devise user
> to an OpenERP user (based on the email). But you could in fact very well map 1
> million of Devise users (hey they have encrypted passwords ;-) to a single
> OpenERP portal user if you like (they will just have the same OpenERP profile)
>
> So far it looks like it's just a normal OpenERP portal user.
>
> BUT, the user email will be passed in the context in every RPC call to
> OpenERP. That can be used to implement a special rule check_access_rule
> override that can for instance let you edit only the objects for which the
> email is in the list of allowed users.
> For instance in my website, a logged user is able to edit only the announces
> (a product) related to the partner they are mapped as, and only their partner
> data.
>
> Then you will think but what about the user interface? Well AKTOOOR is a kind
> of Ruby on Rails web-client for OpenERP (to be demoed soon). It doesn't
> feature all OpenERP web-clients features of course, but it features a
> reasonable set of features: navigation, CRUD, form/list, inner views, most
> types of widgets, relational ones too, native Kaminari pagination...
> The main part that is currently missing is dynamic on_change and dynamic domains.
> AKTOOOR is based on simple_form (hey it's done by Plataformatec, one of the
> few noticeable Brazilian start-up around, the Rails committers guys behind
> Devise or Elxir killer Erlang Ruby like derivative).
> simple_form is Rails form_for on steroid, adapted for Twitter Bootstrap, see
> https://github.com/plataformatec/simple_form
> http://simple-form-bootstrap.plataformatec.com.br/
> simple_form is a no fluff framework but OpenERP forms themselves looks more
> complete of course, I'll demo that soon.
>
>
> But AKTOOOR isn't meant to be a full blown web-client. You already have the
> one of OpenERP one for that. Instead, it's mean't so that you can develop any
> killer Rails scalable app where you can embed OpenERP forms that do everything
> you want in the CSS/HTML style you want without any data duplication. It's
> also multi-OpenERP instances by the way (we have one OpenERP for every city in
> the project I build).
>
> So if you use AKTOOOR to develop the forms you want these light OpenERP users
> to interact with, then you don't need to make them real OpenERP users and that
> should enable business models that the AGPL license or OPW woul forbid
> otherwise (notice that OpenERP modules themselves are still subject to the
> AGPL of course, but the the front-end website that is MIT compatible).
>
>
> I think the website we will soon make buzz about will be the first web2.0
> business model web-site with all it's logic based on OpenERP, with a proper
> encapsulation of the AGPL and non AGPL things and even compatible with the OPW
> model eventually despite thousands of users.
>
> Contact me if you are interested (though I apologize because I often lack of
> time to answer).
>
> Regards,

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp