Insert->Envelope is an alternative way of Mail Merge. In Envelope dialog, on Envelope tab, there are two selectors - Database and Table - that are used to fill the list of available fields in the third selector - Database field. There is a usability issue here: when a user wants to create/insert an envelope, and add addresses from, say, a spreadsheet, the user will open the dialog, only to discover that there's no way to select the spreadsheet in the dialog. The Database selector only lists registered databases; and one needs to create a new registered database beforehand, and only then start creating the envelope. Furthermore, the help [1] doesn't mention this information, so users are at lost here [2]. There is another issue here, too. Since version 5.1 [3], there is mail merge database embedding into ODT, so that there's no separate ODB to think about - or to register when you moved the mail merge document to another system. But this is only available when you use Mail Merge Wizard with its Select Address List dialog, and not when you register a database using File->New->Database. So the proposal is to replace the Database and Table selectors in the Envelope dialog with the "Select Address List" button used on step 3 of Mail Merge Wizard, and use the Select Address List dialog with its Add button to open a data source - including creating and embedding of new data source if required. Additionally, this increases consistency across different methods. There is a drawback here: currently it's possible to add fields from different registered databases/tables in the Envelope dialog; the new method would possibly make this impossible. However, I highly doubt that this possibility is really useful enough to keep it and not do the change. Also keeping the possibility might be possible by selecting the address list several times (like now selecting Database and Table several times), and then using Database field selector to insert fields to the target box. [1] https://help.libreoffice.org/6.4/en-US/text/swriter/01/04070100.html [2] https://ask.libreoffice.org/en/question/223694 [3] https://vmiklos.hu/blog/mail-merge-embedding.html
The benefit of this proposal is clear. Drawback is the nested dialog- always an ugly solution. In particular you cannot quickly switch from one to another table or database. Acceptable, in my opinion. We need a static label, the button, and could, if space is left, make the database field dropdown a list (big advantage to collect the several fields). Database: <Foo> Table: <Bar> [Select Address List] Fields: [AAAA] [BBBB] (Ideally, the right list aligns with the left list. Meaning Database & Table go somewhere else.) We could improve the dialog with common dual list interactions but loose the ability to configure directly (eg. insert comma, breaks etc.) (In reply to Mike Kaganski from comment #0) > There is a drawback here: currently it's possible to add fields from > different registered databases/tables... However, I highly doubt that this > possibility is really useful enough to keep it... Fully agree.
(In reply to Mike Kaganski from comment #0) > There is a drawback here: currently it's possible to add fields from > different registered databases/tables in the Envelope dialog; the new method > would possibly make this impossible. However, I highly doubt that this > possibility is really useful enough to keep it and not do the change. Also > keeping the possibility might be possible by selecting the address list > several times (like now selecting Database and Table several times), and > then using Database field selector to insert fields to the target box. This possibility corresponds to actual use cases, e.g.: - selecting recipient names from a name table and then a corresponding address from a second table ; - creating invoices by pulling name data from one table, and invoice data from another table ; - creating automatic bank draft / debit order forms etc, etc. If the UI changes do get implemented, please keep these possibilities available.
(In reply to Alex Thurgood from comment #2) > This possibility corresponds to actual use cases, e.g.: I am unsure how that could be implemented, when there's no queries in Writer, only (independent) table references... could you please provide a step-by-step - so that the functionality could be tested and kept when someone implements this?
To simplify the user experience I would suggest the following: 1. Stop presenting address books as data sources. 2. Deprecate the Envelope mechanism in favour of a master document that has a page definition for the envelope. The Envelope mechanism is of little benefit to the user today. 3. Use a database connector (ODBC/JDBC etc) to present address books, spreadsheets and indeed databases and LDAP as data sources. Item 3 presents a much more flexible approach and a consistent presentation of the available fields regardless of the data source type. Admittedly the current user experience regarding the selection of data sources has much to be desired. But that is another story.