Bug 138209 - FORMS: Changing a form created with LO 7.0.3.1 with an older version leads to lost of the form
Summary: FORMS: Changing a form created with LO 7.0.3.1 with an older version leads to...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.0.3.1 release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:7.2.0 target:7.1.4
Keywords: bibisected, bisected, dataLoss, regression
: 139235 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-11-14 08:44 UTC by Robert Großkopf
Modified: 2021-05-18 13:25 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Try to edit a form in LO 6.4.6.2 (or older) version. Save and try to reopen the form. (20.33 KB, application/vnd.oasis.opendocument.database)
2020-11-14 08:44 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2020-11-14 08:44:47 UTC
Created attachment 167297 [details]
Try to edit a form in LO 6.4.6.2 (or older) version. Save and try to reopen the form.

Open the attached database with LO 7.0.3.1
Open a form for editing (the second form is only a copy - could be you need it ...)
Save the form.
Try to open the form (for input data or editing) → works.

Open the same database in an older version of LO. I tried this with LO 6.4.6.2 on OpenSUSE 15.1. Do the same as described above.

The form couldn't be loaded after I edited and saved the form.

So it is impossible to send other people with older LO-versions a database with forms created in LO 7.0.3.1.
Comment 1 Robert Großkopf 2020-11-14 10:00:16 UTC
Note: Bug 134582 shows the same behavior, when editing forms of an older version with LO 7.0. This is fixed. But changing a form of LO 7.0 with an older version leads to lost of the whole form.
Comment 2 Robert Großkopf 2020-11-26 11:18:15 UTC
Nobody there who is interested in this bug? Edited again a form, which has been created by LO 7.0.3.1., which is posted in a forum. The whole form is lost when saving this in LO 6.4.6.2. So I have to start again in LO 7.0.3.1.

This is a big problem for persons, who will support other people with different LO-versions.
Comment 3 Alex Thurgood 2020-11-26 15:13:25 UTC
Hi Robert,

Unfortunately, no repro for me when testing with 

Version : 6.4.6.1
Build ID : 985dd72ca280d5c6da2e9f90f7ff9286cafe7ff8
Threads CPU : 8; OS : Mac OS X 10.15.7; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

after having modified the form and saved the ODB file in LO7031.

I opened the Form in design mode, changed the name of one of the labels, then moved the grouped control of label and field, saved the Form, then saved the ODB file, and shut down LO.

Then started LO6461, loaded ODB file, the form was still there, and the changes I had made were visible.
Comment 4 Robert Großkopf 2020-11-26 15:43:18 UTC
(In reply to Alex Thurgood from comment #3)
> 
> Then started LO6461, loaded ODB file, the form was still there, and the
> changes I had made were visible.

Hi Alex,

you haven't edited the form in LO 6.4.*. Try to edit the form now in LO 6.4.6.1. Save this editing. Close the form and retry to open.

Every for, which has been created in LO 7.0.3.1, couldn't be edited in 6.4.6.2 without loosing the whole form.
Comment 5 Alex Thurgood 2020-11-26 17:27:13 UTC
Hi Robert,

Oh, yes, you are correct, I can confirm. When I edit the form in LO646 like you indicate, then save, and try to reopen, I get the following error message :

SfxBaseModel::loadFromStorage: 0xf26

Confirming.
Comment 6 Alex Thurgood 2020-11-26 17:30:10 UTC
If I subsequently try and load the form that I changed in LO646.x in LO703.x, I see the same error, so once this dataloss occurs, it can't even be resolved by re-opening in LO7.
Comment 7 Stang 2020-11-27 00:27:27 UTC
Hello,

There are a number of things which are modified in the process.

However, in the 'content.xml' file for the form, 'office:version="1.3"' gets changed to 'office:version="1.2"' when modifying the form.  Changing it back to 1.3 gets the form working again.

Don't know what the ultimate solution is but hope this is of some help.
Comment 8 Stang 2020-11-27 00:36:32 UTC
Also note, the problem does return when another change is made.  It is only a temporary fix so as to not lose the form totally.
Comment 9 Xisco Faulí 2020-12-03 12:20:45 UTC
The problem happens with every version not including

author	Michael Stahl <Michael.Stahl@cib.de>	2020-04-28 18:04:14 +0200
committer	Michael Stahl <michael.stahl@cib.de>	2020-05-18 18:19:03 +0200
commit	a541cd91951eca15e40764244b34c72b347f9f26 (patch)
tree	4bc8d4dae54b42a65bd65239dc5283bcb667b23b
parent	101594c272a53727566b3533fd083178769a4b49 (diff)
officecfg,unotools,cui: add ODF 1.2 Extended / ODF 1.3 versions

s it fails in previous versions because the document uses ODF 1.3 version.
Anyway, LibreOffice 6.4 has already reached the end of life. My take would be to close this as RESOLVED WONTFIX

@Michael Stahl, what's your opinion ?
Comment 10 Julien Nabet 2020-12-13 11:05:33 UTC
(In reply to Xisco Faulí from comment #9)
> The problem happens with every version not including
> 
> author	Michael Stahl <Michael.Stahl@cib.de>	2020-04-28 18:04:14 +0200
> committer	Michael Stahl <michael.stahl@cib.de>	2020-05-18 18:19:03 +0200
> commit	a541cd91951eca15e40764244b34c72b347f9f26 (patch)
> tree	4bc8d4dae54b42a65bd65239dc5283bcb667b23b
> parent	101594c272a53727566b3533fd083178769a4b49 (diff)
> officecfg,unotools,cui: add ODF 1.2 Extended / ODF 1.3 versions
> 
> s it fails in previous versions because the document uses ODF 1.3 version.
> Anyway, LibreOffice 6.4 has already reached the end of life. My take would
> be to close this as RESOLVED WONTFIX
> 
> @Michael Stahl, what's your opinion ?

I'm quite interested in the response here.
Indeed, there are quite of stuck stuff because we absolutely want to maintain compatibility, see https://wiki.documentfoundation.org/Development/stuck_stuff.
My opinion is if the buggy version is EOL, it should be WONTFIX. It's not as if you had to pay to get LO, it's free and you can upgrade. Of course, there are constraints but if we advertise the changes in release notes, there should be no pb (after all, nobody forces upgrades).
Of course, I already know it doesn't correspond to the main stream considering the number of stuck stuff.
Comment 11 Stang 2020-12-13 17:03:07 UTC
I'll be brief.  This is like many other problems in Base.  Another area in LO gets changed, something in Base no longer works properly.  Bug sits and sits and sits.  I need too many patches now to work around these problems.

EOL is not valid in my opinion.  Have seen many who refuse to upgrade because of extent of problems in newer versions.

So now a new problem.  I give help with a new form on the forum.  They can't modify it because it won't work then.  Getting it transferred to fit there needs is a hassle however you look at it.

WONTFIX appears to be deeper than just a tag.
Comment 12 Robert Großkopf 2020-12-13 19:14:25 UTC
(In reply to Stang from comment #11)
> 
> So now a new problem.  I give help with a new form on the forum.  They can't
> modify it because it won't work then.  Getting it transferred to fit there
> needs is a hassle however you look at it.

That is the main problem. If it's for my own I could work with the newest version of LO (including all the new bugs in form fields) and wouldn't have a problem to open an save forms. But there are many people asking for help for Base and sending databases to a forum or per private mails. So I have to switch to content.xml of the Base file and see if it is office.version=1.3 or 1.2 and then I know with which version I have to open the form and edit the forms inside the Base files.

So I have decided to warn all people to use LO 7 to edit forms with Base. There is a big warning on my website, which is a special website for Base: https://www.familiegrosskopf.de/robert/
Comment 13 Robert Großkopf 2020-12-14 06:30:01 UTC
(In reply to Julien Nabet from comment #10)
> My opinion is if the buggy version is EOL, it should be WONTFIX.

I don't think the buggy version is EOL. The buggy version, which produces this shit, is LO 7.0. It is possible to open and edit a Writer document in LO 6.4 and LO 7.0 without any problem. But ist isn't possible to do the same with a form in a *.odb-file. This is the bug.

Solution could be: 
1) Save all forms in ODF-version 1.2. There is nothing in 1.3, which could extend the possibilities in a Base form.
2) Create a dialog where people are warned: "Form will be saved in ODF-version 1.3. It couldn't be opened again in ODF-version 1.2". This dialog should appear if the content.xml shows version 1.2 and one will save a form in LO 7.0.

I would prefer the first solution.
Comment 14 Michael Stahl (allotropia) 2020-12-19 22:13:22 UTC
the problem is that manifest.xml contains:

 <manifest:file-entry manifest:full-path="forms/Obj11/" manifest:version="1.3" manifest:media-type="application/vnd.oasis.opendocument.text"/>

but forms/Obj11/*.xml contain:

 office:version="1.2"

somehow the version of the form wasn't reset.

... if i try the same thing with a Writer document and embedded spreadsheet, saving in 6.4 results in a consistent manifest.xml and content.xml versions.

on storing the file with embedded object it's set here:

#1  OStorage::setPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&) (this=0x7fddc70, aPropertyName="Version", aValue=uno::Any("string": "1.2")) at libreoffice-6-4/package/source/xstor/xstorage.cxx:4381
#2  0x00007f9a89cf8518 in SfxObjectShell::SetupStorage(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, int, bool) const () at libreoffice-6-4/instdir/program/libsfxlo.so
#3  0x00007f9a89d37686 in SfxBaseModel::storeToStorage(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () at libreoffice-6-4/instdir/program/libsfxlo.so
#4  0x00007f9a681d29d9 in OCommonEmbeddedObject::StoreDocToStorage_Impl(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, int, rtl::OUString const&, bool) () at libreoffice-6-4/instdir/program/../program/libembobj.so
#5  0x00007f9a681d55d0 in OCommonEmbeddedObject::storeAsEntry(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () at instdir/program/../program/libembobj.so
#6  0x00007f9a8a653498 in comphelper::EmbeddedObjectContainer::StoreAsChildren(bool, bool, com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&) () at libreoffice-6-4/instdir/program/libcomphelper.so
#7  0x00007f9a89cfa39c in SfxObjectShell::SaveAsChildren(SfxMedium&) () at /home/ms/lo/libreoffice-6-4/instdir/program/libsfxlo.so
#8  0x00007f9a69abecaa in SwDocShell::SaveAs(SfxMedium&) (this=0x688af50, rMedium=...) at sw/source/uibase/app/docsh.cxx:516
#9  0x00007f9a89cfa680 in SfxObjectShell::SaveAsOwnFormat(SfxMedium&) () at /home/ms/lo/libreoffice-6-4/instdir/program/libsfxlo.so
#10 0x00007f9a89cfc9dc in SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet const*) () at libreoffice-6-4/instdir/program/libsfxlo.so
#11 0x00007f9a89cfdf3e in SfxObjectShell::DoSave_Impl(SfxItemSet const*) () at libreoffice-6-4/instdir/program/libsfxlo.so
#12 0x00007f9a89d30396 in SfxBaseModel::storeSelf(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () at instdir/program/libsfxlo.so

oh, it works on master because of:

commit 519d96fd8b83ef4c61576d87b58f97b7e6e6e3c6
Author:     Michael Stahl <Michael.Stahl@cib.de>
AuthorDate: Fri Jul 10 14:30:34 2020 +0200

    tdf#134582 sfx2: when storing, set Version on embedded object storage
    
    This previously wasn't needed because there was only one version for
    which it was checked (1.2) but since commit
    a541cd91951eca15e40764244b34c72b347f9f26 there's a second version so
    when loading an existing embedded object in one version and storing it
    in another, the Version must be updated so the attribute in
    META-INF/manifest.xml matches the one in content.xml.
 

... sorry, i didn't notice that this would be needed in 6.4 as well, so it's only in 7.1/7.0.
(because 6.4 doesn't support version 1.3 anyway, but the Storage's version is a string,
not some integer constant, so it can round-trip whatever is in the file...)

yep, a backport of this would fix it, but i guess it's too late now...
Comment 15 Michael Stahl (allotropia) 2020-12-19 22:20:02 UTC
oh, as a workaround, i guess you can set the version to "ODF 1.2 extended" in Tools->Options->Load/Save->General->ODF format version

... it can save everything that the newer version can, just more of it in non-standard namespaces.
Comment 16 Julien Nabet 2020-12-23 08:15:04 UTC
(In reply to Robert Großkopf from comment #13)
> (In reply to Julien Nabet from comment #10)
> > My opinion is if the buggy version is EOL, it should be WONTFIX.
> 
> I don't think the buggy version is EOL. The buggy version, which produces
> this shit, is LO 7.0. It is possible to open and edit a Writer document in
> LO 6.4 and LO 7.0 without any problem. But ist isn't possible to do the same
> with a form in a *.odb-file. This is the bug.
According to https://wiki.documentfoundation.org/ReleasePlan/6.4, 6.4 branch is EOL


> 
> Solution could be: 
> 1) Save all forms in ODF-version 1.2. There is nothing in 1.3, which could
> extend the possibilities in a Base form.
> 2) Create a dialog where people are warned: "Form will be saved in
> ODF-version 1.3. It couldn't be opened again in ODF-version 1.2". This
> dialog should appear if the content.xml shows version 1.2 and one will save
> a form in LO 7.0.
> 
> I would prefer the first solution.

Just my personal opinion (and I'm pretty sure I must be the only one considering stuck stuff page + situation for complete TB AB removing :-)) Since LO is free and open, I don't see the pb to tell people to migrate instead of adding ourself extra constraints.
After all nobody forces to use LO and there are other Office suites.
Anyway, if Michael has a solution, great!

=> uncc myself since I can't help here.
Comment 17 Robert Großkopf 2020-12-28 07:52:15 UTC
*** Bug 139235 has been marked as a duplicate of this bug. ***
Comment 18 Commit Notification 2021-05-10 19:08:51 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/16de54a5c47fbc4691ee099c1f7bb559a8fe11ac

tdf#138209 ODF export: work around forms problem in LO < 7.0

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2021-05-18 13:25:53 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/ad5ebd2bcf6d80d46b59849fb85aa3ee226b52a3

tdf#138209 ODF export: work around forms problem in LO < 7.0

It will be available in 7.1.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.