This PR lays the ground work for making all the liveview pages more
uniform in how they are laid out by creating and updating some of the
liveview components.
Why:
* The signup page was failing to allow signups due to a change in one of
the domain functions. This happened due to the UI not having tests for
the sign up page. The sign up page has been updated to use the new
domain function signature and has also had some tests added to hopefully
prevent regressions.
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Upsides:
1. We don't need to maintain a separate repo and Dockerfile just for
Elixir image (permissions, runner labels, etc)
2. No need to push intermediate images to the container registry
3. No need to copy-paste alpine/erlang/elixir version and hashes from
`firezone/containers` to `elixir/dockerfile` every time they change
4. No need to cross-compile for local dev environments, better
experience building with slow internet connection
5. One command to test if our code works on our containers but a
different alpine/erlang/elixir version
Downsides:
1. Locally devs will need to compile Erlang at least once per version,
but the whole build takes ~6 minutes on my M1 Max. It also takes only 8
minutes on the free GitHub Actions runner without any cache.
2. Worse experience on slow machines
FYI: there is no performance penalty once we have cache layers, still
takes 30 seconds on CI.
Fixes#2213
This will allow us to fetch the actual Firezone version that's in use
from within the language runtimes themselves without resorting to an
external mechanism to do so. This is useful in connlib for example when
selecting the Portal API to use with `X-Firezone-API-Version`, and
useful in log printing.
Since platforms enforce semantic version, I propose the convention:
`1.20231001.34` where MAJOR is `1` for Firezone 1.0, MINOR is our API
version, and PATCH is the release of that API version that is published
on the repo.
Given this system, publishing a release would consist of:
1. Edit `Makefile` to set the patch and minor versions appropriately
depending on whether there are breaking portal API changes.
2. `make version`
3. `git add .; git commit; git push` -- this opens a PR with the new
version numbers. In this PR we can discuss whether to stop-ship or go.
4. PR merged, release is drafted and deployed to staging with the new
tag and version numbers
5. build artifacts are uploaded to drafted release, everything is tagged
and versioned appropriately without having to introduce another commit
6. If all looks good, publish release
Why:
* The previous Account DNS Settings page was only a static page. This
commit enables the form on the page to actually save and update the DNS
settings for a given account.
Getting some weird behavior with AppLinks. They don't seem to work upon
first use and require a few tries to function correctly.
Edit: Found the issue: Android Studio doesn't like when the Manifest
contains variables for AppLinks. I added a note in the Manifest.
@conectado To test Applinks are working correctly, you can use the App
Link Assistant:
<img width="930" alt="Screenshot 2023-09-28 at 11 15 11 PM"
src="https://github.com/firezone/firezone/assets/167144/e4bd4674-d562-44ec-bdb8-3a5f97250b84">
Then from there you can click "Test App Links":
<img width="683" alt="Screenshot 2023-09-28 at 11 15 30 PM"
src="https://github.com/firezone/firezone/assets/167144/f3dc8e0d-f58a-4a4b-9855-62472096dc9e">
Thanks to @devsnaked for the fix. Opening this to get the changes merged
more quickly.
Supersedes #2072
---------
Signed-off-by: Maximilly Moreira Gonçalves <max.ocw@gmail.com>
Co-authored-by: Maximilly Moreira <max.ocw@gmail.com>
Adds `active_path` to determine whether or not to highlight a sidebar
item.
~~Leaving as draft for now to allow @devsnaked to contribute. Edit: Will
use this PR as the base for @devsnaked's upcoming changes~~
Edit: fixes#2065
Why:
* The current account settings page shows the user profile info and
billing information. The billing system is not currently implemented and
can be hidden for the time being. As for the user profile information,
it was decided that it would probably be better to send the user to the
'Actors' show page for the currently logged in user.
<img width="1148" alt="new-account-settings-page"
src="https://github.com/firezone/firezone/assets/2646332/6aaabad0-038e-4b4c-8cfb-e2d669b54b53">
Why:
* Previously the New/Edit forms for Resources were not able to actually
create or update Resources. This commit enables those forms to create
and update a Resource.
---------
Co-authored-by: Andrew Dryga <andrew@dryga.com>
Renaming it back to clients to reflect service accounts and headless
clients use cases in the terminology. Such a rename will be very painful
on live data so better if we do it early on.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Why:
* The new and edit policy pages had previously only been pulling live
data from the DB, but had not been able to use the forms to create or
update policies. This commit allows the forms to function as intended.
