Bug 117531 - Firebird: Migration: Migration function must recognize opening from Beamer OR Mail Merge Wizard and if started automatically save the file after successful run
Summary: Firebird: Migration: Migration function must recognize opening from Beamer OR...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected)
Hardware: All All
: high major
Assignee: Not Assigned
Depends on:
Blocks: Database-Firebird-Migration Database-Firebird-Migration-Dialog
  Show dependency treegraph
Reported: 2018-05-10 03:05 UTC by Drew Jensen
Modified: 2019-08-02 09:06 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

screen shot (429.04 KB, image/png)
2018-05-10 03:06 UTC, Drew Jensen

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2018-05-10 03:05:12 UTC
basically this comes down to how assertive the migration process should be.

If you look at the attached screen shot you see that the migration functionality is started from the Mail Merge Wizard if any hsql based odb is open to DISPLAY the tables in side.

I wanted this database for the mail merge and I said go ahead and migrate it. In fact I really only ever use this file from Mail Merge.
The migration function executed without error and I could run my mailmerge.
I closed the file.
// time passes
I start a new mail merge document, want the same database.
The migration process is triggered.
The migrated ODB was not saved, when I closed out the mail merge process it quietly closed the ODB also.
(NOTE, if the migration function has any error then another bug is triggered and the ODB can not be used for anything until LibO session is ended and restarted)

Steps to Reproduce:
1. Open/Create a writer file.
2. Start the mail merge wizard
3. IF the last registered database used for a mail merge is an HSQL:sdbc file the auto migration prompts happens here
3. OTHERWISE In step three select 'Select Adress List'
4. click on any HSQL:sdbc based databse on the list presented and the migration function prompt displays when the list control prepares to show available tables.
5. However you got here: Select Yes.

Actual Results:  
Changes to ODB from auto migration triggered from beamer window and mail merge ( and possibly other vectors ) offer no way for the user to save the ODB file after success.

Expected Results:
Changes are permanent. 

Reproducible: Always

User Profile Reset: No

Additional Info:
Optionally, could be a RFE 'Be less assertive and check for use cases not to prompt for auo-migration as part of functionality'. 

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36
Comment 1 Drew Jensen 2018-05-10 03:06:25 UTC
Created attachment 142003 [details]
screen shot
Comment 2 Robert Großkopf 2018-05-10 18:12:32 UTC
Could confirm mail-merge wizard doesn't offer any possibility to save the data, which are migrated from internal HSQLDB to internal Firebird database.

Tested with 
Build-ID: ecf50fe71596c3edba8ce437481ab80ae1cd8935
CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-08_00:13:13
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Comment 3 Alex Thurgood 2018-05-11 07:26:15 UTC
Ouch !
Similar to the other Beamer bug already referenced in BZ.
Needs a solution.
Comment 4 Xisco Faulí 2018-06-07 10:46:20 UTC
What about not asking the users to migrate it from Beamer and it can only be done if the database is open in Base?
Comment 5 Drew Jensen 2018-06-07 12:13:00 UTC
Having it only ask if the Base window is open and visible would be a solution.  

When an embedded database is in use the Base file is always opened, by definition, but sometimes not in a visible state. 

The beamer, built in mail merge wizard are two examples of when it is opened but not visible. 

There are at least two published extensions, on the libo and AOO extension services, which do the same.

That old base extension which I put to the nextcloud the other day (and rambled on about on irc) it hides the base window then launches a report, with the migration assistant pop up triggered, and the results of saying yes are just as problematic because the extension code doesn't realize it needs to save the file when it is done.
Comment 6 Drew Jensen 2018-06-07 12:41:47 UTC
Actually I am almost certain that in cases of basic scripts which hide the base window, for whatever reason, it can be more problematic still because of how basic handles event processing. 

The main reason I dug up that old extension was to try it against hsql files and say yes to the migration assistant, particularly hsql files which trigger error messages, and check how that interplay with the basic engine goes. 

I've run a couple of tests and it gets a little odd. I haven't pestered with opening an issue because, to be honest, the assistant isn't even moving data properly, yet, for every data type, and I don't care about the rest so much until at least that is happening. 

With no word (and no code check ins) from Tamas for over almost 2 weeks, and assuming that the data integrity during migration is the prime concern, I figured that meant he was still head down working on that core stuff.