Keel - LDH Middleware issueshttps://source.puri.sm/liberty/host/middleware/-/issues2020-05-06T16:26:55Zhttps://source.puri.sm/liberty/host/middleware/-/issues/87Update stylesheet for radio buttons in forms2020-05-06T16:26:55ZDavid SeawardUpdate stylesheet for radio buttons in formsWe have added some radio buttons to forms. They appear with a bullet point and radio button, which is confusing, or at least ugly. Please update the stylesheet accordingly.
![image](/uploads/1d4ca58a0c8172ea0f8c54089ee3b845/image.png)We have added some radio buttons to forms. They appear with a bullet point and radio button, which is confusing, or at least ugly. Please update the stylesheet accordingly.
![image](/uploads/1d4ca58a0c8172ea0f8c54089ee3b845/image.png)Feisty first launchNoe Nietonoe.nieto@puri.smNoe Nietonoe.nieto@puri.sm2020-02-21https://source.puri.sm/liberty/host/middleware/-/issues/86Parameterise billing/bundle on registration page2019-09-13T08:37:33ZDavid SeawardParameterise billing/bundle on registration page## User story
I am an unregistered user. I want to pick my bundle before my billing period, to reduce cognitive overhead.
## Suggested solution
We are moving the period choice (monthly/annual) from the front page to the registration p...## User story
I am an unregistered user. I want to pick my bundle before my billing period, to reduce cognitive overhead.
## Suggested solution
We are moving the period choice (monthly/annual) from the front page to the registration page. The bundle choice (basic/complete/family) remains on the front page.
Let's fully parameterize the registration page, but hide irrelevant fields so that we can easily adapt to other workflows.
The business logic doesn't need to account for confusing or invalid definitions, filters and layouts. A mindless rendering of the configuration with late-stage errors is sufficient. Defining a sensible configuration will be the responsibility of the operator.
### Basic layout
* Add two new fields to the registration page, between `passphrase` and `captcha`. They should be `bundle_choice` and `period_choice`. They may be pure-GUI fields not corresponding to database fields.
* Under `period_choice` should be a text field that updates when the user changes either `bundle_choice` or `period_choice`. Every combination has a unique description and associated WooCommerce cart URL:
| Bundle | Period | Description | Cart URL |
| -------- | ------- | ----------- | -------- |
| Basic | Monthly | Just Chat and Social. Free now and forever. | https://shop.example.com/add_to_cart/1/ |
| Basic | Annual | Invalid. Please choose Basic/Monthly. | NULL |
| Complete | Monthly | All services for $7.99 per month. | .../3/ |
| Complete | Annual | All services for $5.99 per month (billed annually). | .../4/ |
| Family | Monthly | Five complete accounts for $14.99 per month. | .../5/ |
| Family | Annual | Five complete accounts for $11.25 per month (billed annually). | .../6/ |
* Marketing will request changes *Description*, so these values should be stored in config for easy editing.
* The basic layout shows all fields and all options.
* When the user clicks "Billing >>" they are redirected to the WooCommerce URL associated with the bundle/period combination.
### Filtered layout
Define special URLs that adjust the layout to hide fields and limit which options are displayed. For example:
**Complete filter**
* Limit options to "Complete | Monthly" and "Complete | Annual"
* Hide the `bundle_choice` field
* This means the user has already picked "Complete" and is choosing between Monthly and Annual
### Single layout (special filter)
There will be a period when we need to keep using the current workflow. A single layout filter replicates the current workflow:
**Complete Monthly filter**
* Limit options to "Complete | Monthly"
* Hide both the `bundle_choice` and `period_choice` fields and the description
* This means the user has already chosen, and is simply registering
### Basic layout (special filter)
Basic users do not need to fill in billing details. They should have a single layout filter *and* skip the WooCommerce step.
**Basic Monthly filter**
* Limit options to "Basic | Monthly"
* Hide both the `bundle_choice` and `period_choice` fields and the description
* Display "REGISTER >>" instead of "BILLING >>" and immediately redirect to account page
* A WooCommerce shop account must still be created, with the recovery address as the billing address
Feisty first launchBirin SanchezBirin Sanchez2019-09-13https://source.puri.sm/liberty/host/middleware/-/issues/81[tunnel/app] Alert user if their tunnel is not active2019-08-19T15:07:07ZDavid Seaward[tunnel/app] Alert user if their tunnel is not activeI imagine a workflow like this:
BASIC
* User creates basic account.
* User launches Librem Tunnel and enters credentials.
* User attempts to connect.
* User receives message "This account does not have a tunnel service."
COMPLETE (INA...I imagine a workflow like this:
BASIC
* User creates basic account.
* User launches Librem Tunnel and enters credentials.
* User attempts to connect.
* User receives message "This account does not have a tunnel service."
COMPLETE (INACTIVE)
* User creates complete account. Tunnel is inactive by default.
* User launches Librem Tunnel and enters credentials.
* User attempts to connect.
* User receives message "Tunnel service is not active. Please visit your profile to activate it."
COMPLETE (ACTIVE)
* User creates complete account. Tunnel is inactive by default.
* User activates tunnel.
* User launches Librem Tunnel and enters credentials.
* User attempts to connect.
* It works.
**Suggested solution:**
* A REST endpoint that returns a status of "unavailable", "inactive" or "active".
* App logic to match.
/cc @birin.sanchez @thomas.markiewiczFeisty first launch