Some thoughts about web application development with Tryton

[Cédric Krier]

Hi,

Last weeks, I had to work on a web application using Tryton as backend.
For some reasons, I did not pick up nereid which did not fit the
requirements. So I went for a light Flask application which resulted
into flask_tryton [1]. This solution was fast and worked fine for my
needs.

But I had some backend needs that are quite generic for many web
applications. So I think we could try to define them to build generic
(web framework agnostic) modules for them. Is not Tryton about sharing
generic modules with large audience?

So I have already identified two of them for which I'm looking for your
comments (and I could publish a prototype).


- web_user

The idea of this module is about having a common minimal web user
definition/support. I think such user should be identify by just
their E-mail and that the module should provide a password
authentication. I also think having a way to validate user by
verifying email address is also a common need.
Such user could be linked with a Many2Many to parties to have the
possibility to store identity information. I think M2M is the more
flexible solution because it allow simple design like O2O or more
complex design where you could have users that behave for the same
company.
The module should also provide an optional session mechanism where
any web framework could be plugged on. The goal will be to have a
shared via database session across multiple instance.

FYI, nereid has a partial implementation of this model but with many
extra features that are not always needed and also some limitation
like the link to a company or to a single party etc.
But with the generic user I describe, I think it could be used by
nereid as basis model.

- web_shop_cart

The idea of this module is about a generic simple webshop cart
implementation. I think the minimal needed fields will be:

Cart:
- company
- owner:
just a char field to identify the user and so it could be
the email of the user but we should avoid direct link
because I think we should be allowed to use any
authentication mechanism and so it could be not stored in
Tryton.
- currency: could be the default company one?
- party: must be required for checkout
- invoice_address
- shipment_address
- state: draft;checked-out
- sale: a reference field to sale.sale or any other Model
- checkout_method: define what should be generated (similar to
the project_invoice design)

Cart Line:
- product
- unit_price: could be tax included or excluded
- quantity
- unit
- amount: Function field

So as you see, I think it is important that the cart is agnostic to
the tax included or excluded. It should be handle by the checkout
method that will create the sale order correctly or a B2C sale order
(as we talked at the TUB2013).

[1] https://code.google.com/p/flask-tryton/

Thanks,
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Sergi Almacellas Abellana]

"Cédric Krier" <cedric...@b2ck.com> ha escrit:

>Hi,
>
>Last weeks, I had to work on a web application using Tryton as backend.
>For some reasons, I did not pick up nereid which did not fit the
>requirements. So I went for a light Flask application which resulted
>into flask_tryton [1]. This solution was fast and worked fine for my
>needs.
>
>But I had some backend needs that are quite generic for many web
>applications. So I think we could try to define them to build generic
>(web framework agnostic) modules for them. Is not Tryton about sharing
>generic modules with large audience?

That makes sense for me.

>
>So I have already identified two of them for which I'm looking for your
>comments (and I could publish a prototype).
>
>
>- web_user

I will prefer external_user as it can be used for other accesses not only web. (For example a mobile app)

>
> The idea of this module is about having a common minimal web user
> definition/support. I think such user should be identify by just
> their E-mail and that the module should provide a password
> authentication. I also think having a way to validate user by
> verifying email address is also a common need.
> Such user could be linked with a Many2Many to parties to have the
> possibility to store identity information. I think M2M is the more
> flexible solution because it allow simple design like O2O or more
> complex design where you could have users that behave for the same
> company.
> The module should also provide an optional session mechanism where
> any web framework could be plugged on. The goal will be to have a
> shared via database session across multiple instance.

And user permisions? Would be out of the scope of this module?

>
> FYI, nereid has a partial implementation of this model but with many
> extra features that are not always needed and also some limitation
> like the link to a company or to a single party etc.
> But with the generic user I describe, I think it could be used by
> nereid as basis model.

That would be great!

I'm not sure about the need of this module because:

1. The checkout process can be very diferent on every implementation, so maybe it's dificult to get a simple solution usefull for all of the diferent implementations.
2. That information is represented on the sale.sale and sale.line models.

>[1] https://code.google.com/p/flask-tryton/
>
>Thanks,

--

Enviado desde mi teléfono Android con K-9 Mail. Disculpa mi brevedad

[Cédric Krier]

On 04 Jan 21:20, Sergi Almacellas Abellana wrote:
> "Cédric Krier" <cedric...@b2ck.com> ha escrit:

> >So I have already identified two of them for which I'm looking for your
> >comments (and I could publish a prototype).
> >
> >
> >- web_user
>
> I will prefer external_user as it can be used for other accesses not only web. (For example a mobile app)

For me, it is linked to the web for 2 reasons:

- its usage is mainly for user of web application (mobile app are
mainly still web application in their design even if they don't
all use browser)

- many part of it will be designed for the web like the session
management, the user validation.

> >
> > The idea of this module is about having a common minimal web user
> > definition/support. I think such user should be identify by just
> > their E-mail and that the module should provide a password
> > authentication. I also think having a way to validate user by
> > verifying email address is also a common need.
> > Such user could be linked with a Many2Many to parties to have the
> > possibility to store identity information. I think M2M is the more
> > flexible solution because it allow simple design like O2O or more
> > complex design where you could have users that behave for the same
> > company.
> > The module should also provide an optional session mechanism where
> > any web framework could be plugged on. The goal will be to have a
> > shared via database session across multiple instance.
>
> And user permisions? Would be out of the scope of this module?

Completely out of the scope and probably even with non sense as it is
self created users so it is not possible to discriminate them.
Also I don't really see any use cases where different permission will be
needed. And even if there were cases, it should be managed by the web
application.
We must not forget that the web users are already a group of user
because we have the normal user of Tryton which have permissions.
And maybe, if you need such permissions for your web application, maybe
it is Tryton's user that you must use.

Of course it depends what you call "checkout process". For me, it is the
point where the order is created in Tryton. So it is the final step of
any complex checkout workflow of the web application.

> 2. That information is represented on the sale.sale and sale.line models.

That's wrong. Sale model is too complex to be used as a cart for web
shop. This will lead to too much operations just to fill a sale line
(fill taxes, get the right description etc.) and so kill the
performance.
More over, you will have a lot of draft death sales because web users
will fill cart without check them out. And this will also kill any
statistic report based on the sales. Of course, you could have a flag on
sale but then you could no more group all sales.

[Raimon Esteve]

> 1. The checkout process can be very diferent on every implementation, so maybe it's dificult to get a simple solution usefull for all of the diferent implementations.

+1.

The checkout is different every site: eg, not all store sites go to
payment method (some B2B) or about a code to discount is diferent.
Also, not all sites have a checkout method -a ticket/support system is
not necessary checkout or payments-

About checkout method we developed sale basket (1) module to generate
a lines about product, quantity and price. "Checkout method", convert
those lines to sale + sale lines.

Same as Nereid module, I think checkout is a new module, not included
in "Tryton Flask".

(1) https://bitbucket.org/zikzakmedia/trytond-sale_basket/src

[Jan Grasnick | Grasbauer UG]

+1 - same design in our module

+ following fields:

last_login - DateTime
visits - Integer
newsletter - Bool (bad naming - its a bool that we can send further
informations - legal stuff)

>
> - web_shop_cart
>
> The idea of this module is about a generic simple webshop cart
> implementation. I think the minimal needed fields will be:
>
> Cart: - company - owner: just a char field to identify the user and
> so it could be the email of the user but we should avoid direct
> link because I think we should be allowed to use any authentication
> mechanism and so it could be not stored in Tryton. - currency:
> could be the default company one? - party: must be required for
> checkout - invoice_address - shipment_address - state:
> draft;checked-out - sale: a reference field to sale.sale or any
> other Model - checkout_method: define what should be generated
> (similar to the project_invoice design)
>
> Cart Line: - product - unit_price: could be tax included or
> excluded - quantity - unit - amount: Function field
>
> So as you see, I think it is important that the cart is agnostic
> to the tax included or excluded. It should be handle by the
> checkout method that will create the sale order correctly or a B2C
> sale order (as we talked at the TUB2013).
>
> [1] https://code.google.com/p/flask-tryton/

+1 - same design in our module

we extended this 2 models with:

- user_group (automaticly assigned by country)
* minimal_order
* shipping_fees
* ....


- group_price (different prices depending of user_group)

Jan

[Cédric Krier]

On 04 Jan 17:05, Cédric Krier wrote:
> So I have already identified two of them for which I'm looking for your
> comments (and I could publish a prototype).
>
>
> - web_user
>
> The idea of this module is about having a common minimal web user
> definition/support. I think such user should be identify by just
> their E-mail and that the module should provide a password
> authentication. I also think having a way to validate user by
> verifying email address is also a common need.
> Such user could be linked with a Many2Many to parties to have the
> possibility to store identity information. I think M2M is the more
> flexible solution because it allow simple design like O2O or more
> complex design where you could have users that behave for the same
> company.
> The module should also provide an optional session mechanism where
> any web framework could be plugged on. The goal will be to have a
> shared via database session across multiple instance.

Here is the review: http://codereview.tryton.org/8451002/
There are still some TODO

> - web_shop_cart
>
> The idea of this module is about a generic simple webshop cart
> implementation. I think the minimal needed fields will be:
>
> Cart:
> - company
> - owner:
> just a char field to identify the user and so it could be
> the email of the user but we should avoid direct link
> because I think we should be allowed to use any
> authentication mechanism and so it could be not stored in
> Tryton.
> - currency: could be the default company one?
> - party: must be required for checkout
> - invoice_address
> - shipment_address
> - state: draft;checked-out
> - sale: a reference field to sale.sale or any other Model
> - checkout_method: define what should be generated (similar to
> the project_invoice design)
>
> Cart Line:
> - product

I put a TODO on this because I think we should allow other things than
product so it should be a reference field with product as one selection.

> - unit_price: could be tax included or excluded
> - quantity
> - unit
> - amount: Function field
>
> So as you see, I think it is important that the cart is agnostic to
> the tax included or excluded. It should be handle by the checkout
> method that will create the sale order correctly or a B2C sale order
> (as we talked at the TUB2013).

Here is the review: http://codereview.tryton.org/6351002/
There are still some TODO.

>
> [1] https://code.google.com/p/flask-tryton/

[Udo Spallek]

Sat, 4 Jan 2014 17:05:28 +0100
Cédric Krier <cedric...@b2ck.com>:

>- web_user
> The idea of this module is about having a common minimal web user
> definition/support. I think such user should be identify by just
> their E-mail and that the module should provide a password
> authentication. I also think having a way to validate user by
> verifying email address is also a common need.

yes, agree.

An other common need is IMHO a password reset request, in case the
password is lost.

At least for verification we will rely on data coming from untrusted
environments.
To be sure it is not faked/manipulated we could use itsdangerous[1] to
sign e.g. the email address with the password and/or another secret as
key.

[...]

> The module should also provide an optional session mechanism where
> any web framework could be plugged on. The goal will be to have a
> shared via database session across multiple instance.

Maybe we can marriage Tryton with beaker[2] whose sessions seem to be
supported by flask, django, pylons or pyramid applications.

[1] https://pythonhosted.org/itsdangerous
[2] http://beaker.readthedocs.org

Regards
Udo Spallek
--
_____________________________
virtual things
Preisler & Spallek GbR
München - Aachen

Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

in...@virtual-things.biz
http://www.virtual-things.biz

[Cédric Krier]

On 09 Jul 19:33, Udo Spallek wrote:
> Sat, 4 Jan 2014 17:05:28 +0100
> Cédric Krier <cedric...@b2ck.com>:

> > The module should also provide an optional session mechanism where
> > any web framework could be plugged on. The goal will be to have a
> > shared via database session across multiple instance.
>
> Maybe we can marriage Tryton with beaker[2] whose sessions seem to be
> supported by flask, django, pylons or pyramid applications.

> [2] http://beaker.readthedocs.org

I think if it is to use an external module so we should not force any
module. The initial idea was to provide such mechanism via Tryton but
indeed nothing really links the session to anything in Tryton. So I will
be in favor of doing nothing.

[Raimon Esteve]

> Cédric Krier <cedric...@b2ck.com>:

>- web_user
> The idea of this module is about having a common minimal web user
> definition/support. I think such user should be identify by just
> their E-mail and that the module should provide a password
> authentication. I also think having a way to validate user by
> verifying email address is also a common need.

Why not available login users using "username" or "email" and
"password" (not only web user)

Idea is all tryton clients login by email or username.

Now in res.user have a email field but is not required and unique.

--
Raimon Esteve

[Fabien Castarède]

What would you mean by "other things" ?

[Cédric Krier]

On 2016-01-18 09:33, Fabien Castarède wrote:
> > I put a TODO on this because I think we should allow other things than
> > product so it should be a reference field with product as one selection.
>
>
> What would you mean by "other things" ?

1.5 year after, I don't remember.