Alias improvments

[G3nna]

Contribution Guidelines

• I've read the contribution guidelines and wholeheartedly agree them

What does this PR include?

Short Description

This PR improves how aliases/spamaliases are handled.

Users will have more options when creating a spam alias. Instead of just being able to create random aliases the users can now control how the local part of the alias is created. Like adding the username to the local part, disable the random part completely and/or provide a known string to it. Furthermore when the user wants to respond from an alias, SoGo visibility can also be enabled. Providing the validity period is now part of the dialog instead of the create then modify flow.

Besides that users can now also see aliases that were created by the admin and assigned to their mailbox. But the user is not allowed to modify such aliases in any way.

Administrators gain the ability to see aliases that are created by users including a filter to limit the visibility in the table. The admin can also edit user created aliases although with some restrictions. Changing the goto address, flagging it as internal or changing the validity is not implemented. Expanding user created aliases over domains is also not allowed. Enabling/disabling and the deletion of user aliases is possible though.

Also this PR adds some fixes to the existing alias handling. For example one could not add public/private comments or specify if sending is allowed directly in the dialog when the alias is created. Instead one had always edit right after the alias was created. Certain flags were also not visible in the admin alias view. Besides that I did notice, that the domain list was probably broken because one item was always encapsulated with a bunch of HTML tags potentially breaking search. Search filters now properly remember the state between page changes.

Find attached some images that show the UI changes.

Affected Containers

• phpfpm
• postfix

Did you run tests?

Sure

What did you test?

I tested if existing spamaliases are migrated over. New aliases can be created by both admin and user. All possible user and admin options. Checked if the clean_spamalias event still cleans user aliases and also removes them from the _sogo_static_view if necessary.

Find attached a document with the test setup and tests.

What were the final results? (Awaited, got)

With the limited knowledge I have about this software it worked as expected.

Additional notes

This merges the spamalias table into the alias table. Everywhere where the spamalias table was used an adapted query on alias is used instead.

This PR does not change the fact, that spamaliases (or user aliases as I call them) are not counted as "real" aliases. No matter how many such user aliases exist it will not affect the alias limit of the domain. Considering that user aliases can be permanent and the local part naming of the aliases can now be free-form this should be though over. For self hosted solutions with a very limited amount of users this is not an issue. In company environments however this can become an issue. A new set of ACL's may be required to further control how a user can create aliases and now many. But that is not the scope for me as I self host.

Attachments

Admin alias edit view
Admin alias view
Domain view
User alias view
User create alias view

Tests.txt