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.
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.
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.
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.
(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.
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.
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.
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.
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.
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 ?
(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.
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.
(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/
(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.
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...
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.
(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.
*** Bug 139235 has been marked as a duplicate of this bug. ***
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.
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.
i seem to remember this is fixed? please test and reopen if im wrong