When TL first creates the log folder, let only the user read the
log files, should the admin override that subsequently we'll
simply warn about it but respect the decision.
Meaning we have private by default, but this can be overriden
This commit adds a new command, /kickban, that is a combination of /kick
and /ban: it kicks the specific user from the channel and then sets the
+b mode to ban the user from the channel.
According to https://modern.ircdocs.horse/#wildcard-expressions
masks should support "*" and "?" wildcards.
Within TL this only impacts the /ignore functionality.
The reasoning for doing this is to ignore say GuestNNNN!*@* with
guest*!*@* and be done with it if someone spams a gateway.
* Extend test coverage to the `search` function.
* Test sort order of messages from `getMessages` and `search`
* Move reversal of `search` results from Vue to messageStorage.
* Remove unnecessary uses of `sqlite.serialize` in tests.
* Return promises from test functions where possible.
Currently styles / plugins were not actually under the CSP
header protection.
There's no real reason to not have them for all requests, so
add them as a root middleware.
Plugins need to be able to store persistant files, say settings or
databases or similar things.
Expose a standard location that gets created when the path is
accessed.
* properly track user modes for context menu
The RPL_ISUPPORT response contains a PREFIX element, which not only tracks the
prefix chars ("@", "+" etc) but also their corresponding mode chars (+O, +v)
This commit changes the context menu to not rely on a hardcoded list but rather
user the one given in the prefix response by the server.
Co-authored-by: Max Leiter <maxwell.leiter@gmail.com>
This will see the maximum allowed of modes that are allowed at once as sent in RPL_ISUPPORT
and will send multiple batches while using /op, /voice, etc.
This also fixes a minor issue where it would try sending an empty voice if it had an extra space on arguments
(such as using '/voice ')
It may not be desirable to host all plugins on npm, allow for local packages to
be installed given a package name with a `file:` prefix.
This is still more restrictive than what yarn would support but allows us to still
verify the thelounge compatibility by reading the package.json file.
`yarn add` messes up with local filepaths and generates a lockfile that is
"outdated" as far as any other yarn commands go, which makes them error out.
For some reason `yarn install` fixes that and hence we run that after an install.
Here's the diff of yarn.lock between the broken state after `yarn add file:$path`
and `yarn install`
--- yarn.lock.2.afterAdd 2021-06-02 00:10:52.365134018 +0200
+++ yarn.lock.3.afterinstall 2021-06-02 00:13:27.122760442 +0200
@@ -2194,7 +2194,7 @@
safe-buffer "^5.1.2"
yallist "^3.0.3"
-thelounge-plugin-shortcuts@/home/reto/sourcecode/thelounge-plugin-shortcuts:
+"thelounge-plugin-shortcuts@file:../../sourcecode/thelounge-plugin-shortcuts":
version "1.0.12"
dependencies:
thelounge "4.2.0"
The only thing it does is switch an absolute path to a relative one for whatever
reason.
Tested on latest Chromium / Firefox. In case of .m4a files they want audio/x-m4a and not audio/m4a, in case of .flac files they want audio/flac and not audio/x-flac. The module we useed to detect the types however detects them only as audio/x-m4a and audio/x-flac as they are not offical IANA supported mime types (not in IANA spec == "x-" prefix): https://www.iana.org/assignments/media-types/media-types.xhtml Though flac is not in the IANA spec many programs such as the file command (https://man7.org/linux/man-pages/man1/file.1.html) and Chromium (flac) / Firefox (x-flac and flac) support audio/flac only or both.
