Template import bug / non-transparent template handling
We are evaluating mailman 3 in a debian buster lxc container using the latest releases (mailman 3.3.4, postorius/hyperkitty 1.3.4) from PyPI.
From documentation and from the archive of mailman 3 user list we found that on importing mailman 2.1 lists templates for message/digest footers/headers (being mailing list attributes there) are converted to $template_name.txt files in vardir/templates/lists/
list_id/$language. Domain- and site-wide templates can be placed in vardir/templates/domains/
domain/$language and vardir/templates/site/
language.
Some weird behavior occurs when importing a mailman 2.1 list with msg/digest_footer/header set to a four-line value each. After import of the list the following four template files in vardir/templates/lists/
list_id/$language with naming scheme list:member:(digest|regular):(footer|header).txt are created. The *:header.txt files are containing the imported values for attributes msg/digest_header as expected, but the *:footer.txt files' contents are made up of a mixture of default template list:member:generic:footer.txt and imported msg/digest_footer attribute values. This is done in such a way that the first three lines are taken from the four-line default template. The fourth line of the resulting *:header.txt files is identical to the last line of the imported attribute value.
Retrieval of the imported list's templates via REST API finds the four templates' database entries as expected. We are wondering, however, why these templates do not show up as list-specific templates in postorius. It seems that only templates created via postorius itself show up there. As a means of transparency it would be very helpful for list owners to see which of the templates at the various possible places (storage location (file system or database) and context (default, site, domain, list)) is used for the particular configuration.
Further, when creating a template database entry via REST API in domain or list context, we noticed that it is not recognized by postorius. The same applies when deleting a correspondent template database entry via REST API which was created using postorius. In this case the template still shows up in postorius after deletion although retrieval via REST API says it's not existing any more. Posting a test email to the list address also confirms that the template is no longer active.