1048: Refactor admin using webpack r=mergify[bot] a=kaiyou
## What type of PR?
Refactoring
## What does this PR do?
This PR brings some refactoring to the admin container :
- remove the dependency to mailustart and replace it with socrate
- remove static assets from the repo and use Webpack for building them
Co-authored-by: hoellen <dev@hoellen.eu>
Co-authored-by: kaiyou <pierre@jaury.eu>
931: Resolve webmail in admin r=mergify[bot] a=ionutfilip
## What type of PR?
bug-fix
## What does this PR do?
Implement mailustart to resolve webmail in admin
### Related issue(s)
Fix#716
## Prerequistes
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [x] In case of feature or enhancement: documentation updated accordingly
- [x] Unless it's docs or a minor change: place entry in the [changelog](CHANGELOG.md), under the latest un-released version.
Co-authored-by: Ionut Filip <ionut.philip@gmail.com>
962: Open some admin sidebar links in a new browser tab r=kaiyou a=mariooos
## What type of PR?
Enhancement
## What does this PR do?
Add target=_blank attribute to html <a href ...> tag in following admin sidebar links:
- Antispam
- Webmail
- Website
- Help
Co-authored-by: mariooos <48351788+mariooos@users.noreply.github.com>
993: Make aliases case-insensitive (too) r=mergify[bot] a=Nebukadneza
Even though RFC5321 2.4 explains that local-parts are to be case-sensitive,
this does not seem to be how EMail is used today. Thus, instead of reverting
user-emails back to being case sensitive, let’s make aliases case-insensitive
too. Not only more consistent, this also allows users to enjoy receiving EMails
from large airlines or car-rental agencies onto their already existing aliases.
For the rare case of case sensitive aliases existing, let’s query for the
forced-lowercase alias only in the event that the preserved-case one isn’t
found …
closes#867
## What type of PR?
bug-fix
## What does this PR do?
Make aliases optionally case-insensitive: After attempting to resolve an alias in its preserved case, also attempt to match it case-insensitively.
This followed after some more thought from #868 …
### Related issue(s)
closes#867
## Prerequistes
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [x] In case of feature or enhancement: documentation updated accordingly
- [x] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/guide.html#changelog) entry file.
Co-authored-by: Dario Ernst <dario@kanojo.de>
1005: distinguish disabled users in user list view by row color r=kaiyou a=zhuangyy
## What type of PR?
enhancement
## What does this PR do?
distinguish disabled users in user list view by row color
## Prerequistes
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [ ] In case of feature or enhancement: documentation updated accordingly
- [ ] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/guide.html#changelog) entry file.
Co-authored-by: Zhuang Yuyao <jssyan@qq.com>
Even though RFC5321 2.4 explains that local-parts are to be case-sensitive,
this does not seem to be how EMail is used today. Thus, instead of reverting
user-emails back to being case sensitive, let’s make aliases case-insensitive
too. Not only more consistent, this also allows users to enjoy receiving EMails
from large airlines or car-rental agencies onto their already existing aliases.
For the rare case of case sensitive aliases existing, let’s query for the
forced-lowercase alias only in the event that the preserved-case one isn’t
found …
closes#867
934: Pass optional arguments to domain model r=mergify[bot] a=ionutfilip
## What type of PR?
bug-fix
## What does this PR do?
Passing optional args to domain model when using cli.
### Related issue(s)
Fixes#933
## Prerequistes
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [ ] In case of feature or enhancement: documentation updated accordingly
- [ ] Unless it's docs or a minor change: place entry in the [changelog](CHANGELOG.md), under the latest un-released version.
Co-authored-by: Ionut Filip <ionut.philip@gmail.com>
886: Ipv6 support r=mergify[bot] a=muhlemmer
## What type of PR?
(Feature, enhancement, bug-fix, documentation) -> A bit of everything
## What does this PR do?
Document how to use ipv6nat. This, however triggers some kind of flaky behavior with the Docker DNS resolver, resulting in lookup failures between containers. So all resolving needs to be done during container startup/configuration.
In order not to pollute every single start.py file, we've created a small library called [Mailu/MailuStart](https://github.com/Mailu/MailuStart). As an addition, this library also defines the template generation function, including its logging facility.
Note: `docker-compose.yml` downgrade is necessary, as IPv6 settings are not supported by the Docker Compose file format 3 😞
### Related issue(s)
Supersedes PR #844
- Fixes#827
- Hopefully helps with #829 and #834
## No backport yet
This PR directly imports MailuStart from git. This makes it a bit more simple to implement on the short term an do some testing and probably some future improvements. When everything is proved stable, we will create a proper PyPi package with versioning and consider back porting.
## Prerequistes
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [x] In case of feature or enhancement: documentation updated accordingly
- [x] Unless it's docs or a minor change: place entry in the [changelog](CHANGELOG.md), under the latest un-released version.
Co-authored-by: Ionut Filip <ionut.philip@gmail.com>
Co-authored-by: Tim Möhlmann <muhlemmer@gmail.com>