Removing the __init__.py makes it impossible for Pylint to get the sources
to lint from the root folder. We manually set all the paths pylint will lint.
That's not a big deal, as we'll remove Pylint any soon to rely only on ruff.
I took inspiration from marsha or magnify project.
I removed the now useless bash script to run Pylint command. It saves us
wrapper! Plus, having a lint command running with different option locally
and in the CI was quite a pain.
Locally linter was running on diff files; Fixed! CI and make command has now
the same behavior.
Recent updates in dependencies broke the tests.
I am in a rush, I found a stack overflow discussion mentionning we should
NOT consider the root folder of a Django project as a Python package.
My issue was:
Model class app.core.models.User doesn't declare an explicit app_label
and isn't in an application in INSTALLED_APPS.
Removing the __ini__.py file at the root folder fixed the regression.
Recent updates of dev/ruff and dev/pylint dependencies led
to new linting warnings.
Pylint 3.2.0 introduced a new check `possibly-used-before-assignment`,
which ensures variables are defined regardless of conditional statements.
Some if/else branches were missing defaults. These have been fixed.
Previously each route rendered its whole layout from a to z.
Now each route updates a single common wrapper when the layout changes
between pages.
Also the Loading, Error, UserFetched, QueryAware code is more explicit
and understandable.
This introduces valtio as dependency, allowing us to deal with global
state easily in a svelte/vue way (reactive mutable state). This limits
the boilerplaty-ness of immutable state lib approaches, while keeping
rendering optimization better than homemade react contexts.
we query user at load and keep info for a while, way less than user
session anyway. will need to check if we could get de-sync (like loading
the frontend with backend user session ending in 30 minutes while we
don't check user state until an hour)
at the cost of a not-changeable username, logged in users who create
rooms now skip the join page. I think it's good to have this to test
this way, even if the username choice is not there yet.
it was a bit cumbersome to navigate by paths accross the app as if one
path changes a tiny bit we have to make sure we updated everything
everywhere and it's kind of error-prone and cumbersome to build paths by
hand.
now we have a routes file that describes everything: what is the path to
each route, and how to navigate to them.
We use a new navigateTo helper that helps us. It could be better typed
but i'm a newbie.
the issue was we return the fetchUser promise to react query too early
(before the browser reloaded the page). now we make sure react query
doesn't get the info
This commit is totally work in progress.
@manuhabitela the floor is yours.
If the user is logged-out, try silently log-in her every hour,
to avoid any manual login on her side.
The one hour value has been discussed with @manuhabitela, but there
is no real logic behind it. Could definitely be shorter or longer.
It needs at least to be longer than the average silent login flow
to avoid locking the user-agent in an infinite redirection loop.
Enhanced the authentication URL generation to support 'silent'
and 'returnTo' query parameters.
This allows initiating a silent login and specifying a custom
return URL after auth.
Silent login attempts to re-authenticate the user without interaction,
provided they have an active session, improving UX by reducing manual auth.
It's an essential feature to really feel the SSO in La Suite.
A new query parameter, 'silent', allows the client to initiate a silent login.
In this flow, an extra parameter, 'prompt=none', is passed to the OIDC provider.
The requested flow is persisted in session data to adapt the authentication
callback behavior.
In a silent login flow, an authentication failure should not be considered as a
real failure. Instead, users should be redirected back to the originating view.
A silent login fails when user has no active session.
Why return the 'success_url'? The 'success_url' will redirect the user agent to
the 'returnTo' parameter provided when requesting authentication.
It's necessary to enable a silent login on any URL.
Minimal test coverage has been added for these two custom views to ensure
correct behavior.
mozilla-django-oidc now supports a 'returnTo' parameter for redirecting
to a specificURL upon successful login. if not provided,
it defaults to the settings-defined URL.
This allows initiating the login flow from any views,
enhancing UX by returning users to their previous page.
The 'returnTo' naming can be discussed.
Based on @rouja instructions, try to document the Tilt stack,
to enhance the DX of any newcomers, discovering Meet and trying
to run it on K8s.
Having a shared/common onboarding documentation on Tilt with
Impress, Regie, and Meet would be amazing.
Especially, to document how to install Tilt and its dependencies.
Important: The frontend is not deployed locally using the production
target, and I feel important to document it.
Closes#50.
Adopted LiveKit demo app approach for passing
configurations to LiveKitRoom.
Introduced roomOptions for future customizations (e.g.,
video quality, e2e, codec).
DeviceId is persisted in local storage despite boolean flag.
checkout@v2 uses node12 which will be deprecated soon.
I've aligned CI configurations to use a more recent action,
already in-use in the 'meet.yml' flow.
now clicking on the header homepage link asks for confirmation when on
the route page.
this is quick and dirty, using browser confirm ui, and not making a
difference between join page and conference page, but it'll do for now
- show the header on homepage. Not sure we want any header on this app
actually but I guess he's right since we have one it feels more
consistent to have it everywhere
- show logged in email in header. ditched it because i didn't quite get
the value of showing it all the time in this app but i guess it's better
than nothing
- remove user info from settings. Since they are back in the header, no
need
- use the default react-aria DialogTrigger when we want to build buttons
triggering dialogs
- use custom Dialog component as a wrapper to Dialog content
this better permits us to have a Dialog content component somewhere else
than its trigger button. Mainly did this so that the dialog title is
localized with its content.
they are not really helpful, i'd rather stick to the react-aria wording,
easier to understand when looking at react aria examples, converting
code, etc. Not a great value adding this api in our tiny heads
