This could be solved by adding extra asserts for wait for page be entirely load, but it is not required.

This could be solved by adding extra asserts for wait for page be entirely load, but it is not required.

The password is re-set anyway later, however it is required to comply to Authentication Policy, generating an acceptable value.

The user language will be stored on Subscription Request and on Person, defining the language used to notify the customer.

This is required when a computer reboots and there is an excessive number of break casts

The commit dee343f3 said:
slapos_jio: after activate the login come back to WebSite and not to the portal.
    
But it actually went to the WebSection and not the WebSite.
    
This fixes ERP5Site_activeLogin on slapos master because right now we
have this URL in emails sent to customer to activate their login:
    
https://slapos.vifib.com/hateoas/connection/ERP5Site_activeLogin?key=XXX
    
So the script is setupping the came from as:
    
https://slapos.vifib.com/hateoas/connection/#!login?p.page=slapos{&n.me}
    
which is not working (returns AttributeError: form_view error)
    
The URL https://slapos.vifib.com/#!login?p.page=slapos{&n.me} is working
though.


See merge request !223

The idea is to make it possible while embedding SlapOS in an existing partition to configure that some requests are forwarded to the master of the partition and to make these requests as the partition - so that when this partition is destroyed all other partitions from the embedded partitions are destroyed.

A bit more integration in slapos is still needed, but is intended to be used in theia (and why not webrunner):

At the beginning theia's instance  looks like this:

![screenshot of theia hosting subscription on slapos master, with the default 3 partitions](/uploads/9a297dbbae49996fb7ee69e89ea75da1/image.png)

after an ERP5 instance is requested in theia's embedded slapos, the partition requests are forwarded as this partition and appear here, as requested by theia:

![screenshot of theia hosting subscription on slapos master, frontend partitions requested by ERP5 appears as requested by theia](/uploads/37b8b30ca117a1251fc2bd099a5dac82/image.png)

This can also allow transparent integration, because the partition credentials are known by the partition, unlike the user credentials.

See merge request !218

The commit dee343f3 said:
slapos_jio: after activate the login come back to WebSite and not to the portal.

But it actually went to the WebSection and not the WebSite.

This fixes ERP5Site_activeLogin on slapos master because right now we
have this URL in emails sent to customer to activate their login:

https://slapos.vifib.com/hateoas/connection/ERP5Site_activeLogin?key=XXX

So the script is setupping the came from as:

https://slapos.vifib.com/hateoas/connection/#!login?p.page=slapos{&n.me}

which is not working (returns AttributeError: form_view error)

The URL https://slapos.vifib.com/#!login?p.page=slapos{&n.me} is working
though.

This is required to comply with erp5_authentication_policy

Set "value" cause some overprocessing in this case (which breaks some tests when invoked under superuser)

You can run it and increate by a certain amount the transaction ids used for payment, this may prevent ids conflics on payzen side when multiple developers are trying to test it during the same day.

If the payment is recently created (in the latest 30 min) process it every minute, if it is older them 30 min, process every 30 min.

We want to acknowledge the payment as fast as possible and usually when it occurs, it is processed on the first minutes.

... not from the Payment Transaction

slapos_subscription_request: (test) Link on the email comes from the invoice

This is an acceptable speed up as the amount of processing is small, and pontual, as states are updated quickly.

This is helpfull to configure configure computers to simulate connection parameters and allocation.

This is a change from Thomas Gambier.

This is a change from Thomas Gambier, I'm just commiting

Don't clear and allow us to pass parameters for the ansible commant which allow us pass extra variables.

  slapos_erp5: Add erp5_authentication_policy as project dependency
  slapos_cloud: Define standard configuration for authentication policy
  Update tests on various bt5.

  Modifies the Workflows meaning for Support Request Workflow

    Draft: Reservation isn't Payed, Person is created
    Planned: Reservation is Payed, User is going to be Notified
    Ordered: First month isn't payed, Hosting Subscription is created
             (started), user is notified about the payment to be done.

    Confirmed: Hosting Subscription is stopped until the payment
               is done. Once it done, instance is started and
               user is Notified.

    Started: User is available for this user.

    Stopped/Delivered aren't implemented.

  Nothing is implemented inside the workflow itself, alarms calls the
  scripts which changes the transitions once everything is ready to move
  foward.

  Allocation aoccur when if subscription request is in ordered state. We
  allocate earlier to reserve the space until the payment is done.

Call the API rather them wait for the alarm hourly alarm. This might update simulation as soon as possible once the Hosting Subscription is created.

See merge request !221

 * Remove duplication of unmodified scripts from Chinese translation
 * Use slapos_jio_ui_test as dependency of slapos_jio_zh_ui_test as we can reuse scripts
 * slapos_ui_zh_tests: Massively Remove unecessary duplication
 * Fixup! default_address_region was replaced by a selection
 * Correctly ident the entire html from the tests and templates (using
monaco autoformat)

This allow to use standalone slapos with some requests being forwarded
to another slapos master. The intended use case is to make have frontend
requests forwarded to "real" slapos master when embedding slapos in
theia or slaprunner.

In SlapOS, both users or partitions can requests partitions. With the
multimaster support of slapos proxy, all requests where made as a user,
but in the case of recursive slapos - where a partition from the "outer"
slapos includes an "inner" slapos, it makes sense to forward partitions
requests as the partition in the "outer" slapos - this way when this
partition is destroyed all partitions that might have been requested are
also destroyed.

To request as partition, the multi-master entry must define two extra
keys:
 - computer, that can be optained by $${slap-configuration:computer}
from instance buildout
 - partition, that can be optained by $${slap-configuration:partition}

When these are not set, the request will be made as a user, like it was
the case before.

We also change the test to unset SLAPGRID_INSTANCE_ROOT because this
implementation has side effect - the environment variable is set and
never unset. Without this, test fail when running the full test suite
because a previous test was leaking SLAPGRID_INSTANCE_ROOT. This is
definitely something we'll have to improve later.

Eventhough implementation might be a bit more efficient is we use the
low level API, we probably don't need performance here and it's easier
to use the request API

revert accidentally pushed commit and fix test failures introduced by nexedi/slapos.core!192

See merge request !216

fixup 31864c5c to make test pass

This reverts commit 3160c589.

pushed by mistake. This is unfinished but it was wrong because we copy
this log file to snapshot directory before we are done writing to it.

When we recurse in instance to find nested slapos that might be using
parts from ourselves, we check all files named slapos.cfg but we may
encounter some slapos.cfg that are not actual slapos config files, for
example in testnodes we have a working copy of slapos repository which
contains a stack/slapos.cfg which is completly different.

This was breaking prune with an error like this:

    2020-04-29 20:07:28 slapos[2097] DEBUG Reading config at /srv/slapgrid/slappart9/srv/testnode/czp/slapos-repository/stack/slapos.cfg
    2020-04-29 20:07:28 slapos[2097] ERROR No section: 'slapos'

See merge request !211