So far the bind config only impacted the IRC connections.
However, nothing in our doc comment says that this is intentional.
bind
Set the local IP to bind to for outgoing connections.
This commit fixes the leak and uses it for all outgoing requests
as described by the docstring.
So far the bind config only impacted the IRC connections.
However, nothing in our doc comment says that this is intentional.
> ### bind
> Set the local IP to bind to for outgoing connections.
This commit fixes the leak and uses it for all outgoing requests
as described by the docstring.
We keep repeating ourselves, let's move that into a helper instead.
In order to get a sane host, we fix the listener to 127.0.0.1
else we get the unspecified :: ipv6 addr (on suitable hosts),
which isn't useful.
We keep repeating ourselves, let's move that into a helper instead.
In order to get a sane host, we fix the listener to 127.0.0.1
else we get the unspecified :: ipv6 addr (on suitable hosts),
which isn't useful.
Add the ability to migrate our db in the upwards direction.
Use the facility to add primary keys to our messages table.
This should allow work like jumping to messages and the likes.
This also introduces the framework for rollback, without actually
hooking it up.
This should be easy enough to do when the need arises.
The TS rewrite dropped the form that was expected to be passed
as props.
That lead to the password change being borked, as the fields
were always set to "null".
We don't need a form, can just use refs here.
https://github.com/thelounge/thelounge/pull/4649 broke existing
themes by removing the colored-nicks class from chat.
Considering that we don't bump the major version, keep backwards
compatibility for now
This enables db migrations to be undone, or "down migrated".
The down migration shouldn't be done automatically
as it could lead to severe data loss if that were done.
Hence, we still hard fail if we encounter a version lower than what
we have in the DB.
A CLI will be added in a later commit that allows users to explicitly
do that.
We can't really import easily from our build without it being
brittle. TL isn't meant to be used as a library.
Instead, just inline the logger as it is trivial enough.
Keep happy path on the left and try to return as early
as we can to help the reader understand the logic better
The function is too large to be able to quickly scan an if / else
chain and see the function return at the end
We should not mess with irc-framework internals.
Technically we shouldn't even access the connection object,
it's not part of the documented API surface
We want primary keys to never get re-used to so that we
can implement jump to messages / context fetching etc
in the future.
This isn't hooked up yet at all to the rest of the code, only
the schema is changed
This sets up the testing infrastructure to test migrations we are
doing.
It's done on a in memory database directly, we are only interested
in the statements themselves and it's easier than to try and
inject a prepared db into the store.
We do add some dummy data though to make sure we actually execute
the things as we expect.
This just repeats the hard coded values from the code, which
is not helping.
We need to touch that test whenever we modify the sql which is
undesired and it doesn't test any useful functionality.
Any error that may ensue would hopefully be tracked by the other
test.
Prior to this, the search is still racy but one tends to notice
this only when the DB is large or network is involved.
The user can initiate a search, get bored, navigate to another chan
issue a different search.
Now however, the results of the first search come back in and
hilarity ensues as we are now confused with the state.
To avoid this, keep track of the last search done and any result
that comes in that isn't equal to the active query is garbage and
can be dropped.
The only reason we accepted a client was that so we have access
to the next message id when we need it.
So let's accept an id provider function instead.
The interface should not contain things that aren't the API of the
storage interface.
Further, rename ISqliteMessageStorage to SearchableMessageStorage,
as that's also an implementation detail.
We'll never have a second sqlite backend, so the name seems
strange.
This means we also apply the collapsing to normal queries,
which might also collapse other things like joins / quits
which may be undesired by some
Fixes: https://github.com/thelounge/thelounge/issues/4583
TL is stupid and doesn't wait for message{Provider,Storage} to
settle before it starts using the store.
While this should be fixed globally, we can hack around the problem
by pushing everything onto the call stack and hope that we'll eventually
finish the setup before we blow the stack.
The only thing that cares about user colors is the user component.
Putting a class value on the chat component seems to be the wrong
place.
This also allows us to remove various css selectors so that we
don't need to be that specific.
After all whatever has that class needs to be colored, we don't
care where it is.
Reto Brunner