This business template contains a framework to integrate stripe checkout payments in ERP5.

To configure the connector:

 - Create an account on stripe.com
 - In stripe.com's dashboard: Developers / API keys use "Create restricted key" to create a key with write access to "All Checkout resources".
 - Create a stripe connector in portal_web_services. Set URL to `https://api.stripe.com/v1/` and the restricted key created in the previous step
 - In stripe.com's dashboard: Developers / Webhooks use "Add endpoint", with "Endpoint URL" set to https://your.erp5.public.hostname/ERP5Site_receiveStripeWebHook and "Events to send" including all events from "checkout.session" category.

To integrate in an ERP5 project:

 - Implement a custom script to start a checkout session. The script should call `StripePaymentSessionModule_createStripeSession` to initiate the session and redirect the end user to stripe checkout page.
 - Implement an interaction workfow on `Stripe Payment Session.complete` which inspects the value of `state_change['kwargs']['payment_status']` and implement the logic (such as create a payment transaction) depending on the status `"paid"` or `"unpaid"`.

Example script to create session

```py
web_site = context.getWebSiteValue()
data = {
  # custom web sections for success and cancel URLs
  "success_url": web_site.stripe_payment_session_success.absolute_url(),
  "cancel_url": web_site.stripe_payment_session_cancel.absolute_url(),
  "line_items": {
      "price_data": {
        "currency": "EUR",
        "unit_amount": 2000, # for 20.00 EUR
        "product_data": {
          "name": "Product Name",
        }
      },
      "quantity": 1
    }
}

 # this will redirect the user to stripe checkout page
return module.StripePaymentSessionModule_createStripeSession(
  connector,
  data,
  context.getRelativeUrl(),
  resource="service_module/...",
)
```

Example interaction workflow script

```py
if state_change['kwargs']['payment_status'] == 'paid':
  portal.accounting_module.newContent(
    portal_type='Payment Transaction',
    causality_value=state_change['object'],
    description="Stripe checkout ...",
    ...
  )

```

Implementation notes:

* Add new stripe connector in ERP5 to access retrieve Stripe session
* New ERP5 functional module to handle Stripe Payment Sessions
* Stripe Payment Session reflects a payment transaction/session initiated using the Stripe Checkout solution.
* Workflow associated with Stripe Payment Sessions provides for the "draft", "open", "completed" and "expired" states in order to reflect the existing states on Stripe.
* Each Stripe Payment Session offers a history and complete traceability of the HTTP exchanges carried out between ERP5 and Stripe from the start and the end of the payment transaction. All Stripe API calls (createSession, retrieveSession) and Stripe webhook POSTs are logged as system events (HTTP Exchange ERP5) related to a Stripe Payment Session.
* Add alarm to handle Stripe Payment Sessions open whose date are expired
* Set web service as source in Stripe Payment Session
Reviewed-by: Jérome Perrin <jerome@nexedi.com>
Reviewed-on: nexedi/erp5!1656

f0808ac6 (workflow: add workflow transition guard for non-user
actions as well., 2015-11-18) broke some custom security
configurations where doing an action on a document would modify an
accounting transaction - but the user doing this action does not have
access to accounting.

This repairs the situation for accounting, by using the Associate
role. The idea is that for such patterns where users "do something
which will interact with accounting", the users also need an
Associate role on accounting transaction portal types, which is in
line with the meaning of Associate.

To be consistent with slapos.core RSS and default values of fields
in ERP5, where we only check the permission on the "context" document
and tolerate displaying properties of context document even if
accessing some properties of related documents caused an error.

See also nexedi/slapos.core!433

This reverts commit 035d099a.
Installing BTs which do not come from produt/ERP5/bootstrap breaks site
creation, except in unit tests.
This commit is very desirable, but not ready, so unfortunately I have
to revert it.

display service stably

Grouping feature checks that the sum of all selected lines == 0, which
is often not the case as the values are float. For that, our approach
is to round the values with the precision of the accounting currency,
since these precisions are usually small (typically 0, 2 or 3), we
don't have problems with rounding. Using the section currency is not
just a workaround for rounding, it's also correct because we don't
consider more precise amounts in accounting transaction lines.

The problem with this approach was for the case where no accounting
currency is set on the section organisation, in that case we did not
round and this sometimes led to "grouping is impossible" errors that
are hard to find for users. At this level it's better to use a default
rounding precision that would make it possible to use the grouping
feature even when section currency is not set.

Some objects, in our case BTrees.Length.Length in a ZODB connection
have a __str__ method that returns unicode on python2:

u'<BTrees.Length.Length object at 0x7f850932e0d0 oid 0x1e334 in <Connection at 7f854bc0f190>>'

They cause an unicode error in the history view when they are
concatenated together with other str (encoded as UTF-8) properties,
this can be observed when using history view with a "folderish"
document (but not with a File as in test_ZODBHistoryBinaryData).

To prevent this issue, we use the fact that ''.format unlike '' %
seem to apply a str() on arguments and use it instead.
Co-authored-by: Yusei Tahara <yusei@nexedi.com>

Some objects become unicode when %s is applied and may cause
UnicodeDecodeError, thus use %r insead.

This reverts commit 40fded3e.

It is not good to mix unicode and str for UI. Use utf8 str only.

This should detect any Business Template with non-migrated workflows.
Exclude the Business Template which is precisely made to test workflow
migration.

Migrate oauth2_session_refresh_interaction_workflow to new-style workflows.
This time, the migration should be complete.

This reverts commit e925dc0b.
This commit is breaking more than it is fixing. Revert until I have a
working version of this migration.

Migrate oauth2_session_refresh_interaction_workflow to new-style workflows.

display comment by default

check contributor's organisation ealier

display corporate name instead of title

display web site instead of default document

add logo field for leaflet

display value used in dialog

update css

ValidationFailed is now a "real" class from Products.ERP5Type.Core.Workflow

See merge request !1676

this only supported http and never supported https, probably nobody is
using this and it makes porting to python3 more complicated

we had a patch to close <input/> elements, but with HTML5 this is no
longer recommended.

template_keep_path_list, template_keep_workflow_path_list and
template_keep_last_workflow_history_only_path_list were not sorted
for no reason

The _getOrderedList approach was not ideal, because the properties were
saved when being displayed, so the typical workflow was:

 1. enter the property as non sorted
 2. click save (property is saved as non sorted)
 3. the page displays the property again as sorted
 4. click save again so that the property is saved as sorted

by sorting the properties at save time, step 1 is enough

This change back the accessors to be "standard" accessors, ie. returning
lists, like every other list accessors, so a few tests and a few scripts
had to be adjusted for the new API.

Lazy loading img are also not loaded, which speed up page rendering.

This should evolve to become a browser-side OAuth2 client.

So every new instance is able to use self-contained oauh2 authentication.
In turn, this triggers atomated migration of a few portal types, which
cause the coding style tests to fail. So commit these as well.

Replace CookieCrumbler's cookie with OAuth2 tokens:
- add the notion of authenticated sessions: period from a login action to
  either a logout or the expiration of tokens
- avoids session fixation (knowing one token does not grant near-permanent
  access to the session)
- reduces the per-request cost of authentication (removes the need to
  compute user's groups, and the need to cache these groups for a fixed
  period).

Also, to reliably open login_form, log out.