Correction, deselecting the report builder during installation is no workaround. If the internal report builder is not installed, the reports cannot be opened, no matter if the Oracle Report Builder 1.2.1 extension has been added manually or not.

See also https://issues.apache.org/ooo/show_bug.cgi?id=96013.

I can confirm with LO 4.3.5, win7

The LibreOffice 4.4 freeze is covered with this ticket: https://bugs.documentfoundation.org/show_bug.cgi?id=88824

(In reply to schaber from comment #0)
> Problem description: 


> Depending on the "Save URLs relative to file system", the relative path
> should be stored, quite like OpenOffice 4.1.1 does it with Oracle Report
> Builder 1.2.1. Well, one can deselect the report builder during the
> LibreOffice installation, and install the Oracle Report Builder as extension
> as workaround, but this is not maintained anymore.


Unfortunately, even this process isn't possible on Mac OSX without breaking the digital signature of the packet, and removing the extension from the app bundle by hand.

Is there any workaround (other than using OpenOffice)?

I know that time estimations are not always possible, but in which time frame do you think can this be resolved, or is there any way to use the Oracle Report builder extension instead? Or can anyone point me in the right direction in the source code?

(In reply to schaber from comment #7)
> (...) can anyone point me in the right direction in the source code?

Sure. At some level, the problem seems to be that in file reportdesign/source/core/api/ReportDefinition.cxx in function OReportDefinition::storeToStorage around line 1394, the "aDescriptor.getUnpackedValueOrDefault(utl::MediaDescriptor::PROP_DOCUMENTBASEURL(),OUString())"
returns empty string, because aDescriptor contains empty string for "DocumentBaseURL.

If I change that to the full URL of the current .odb, then the absolute filepath is still SHOWN, but the relative path is STORED. So this seems to be what we need to concentrate on.

This itself comes from argument _aMediaDescriptor (line 1359)
which comes from file embeddedobj/source/commonembedding/persistence.cxx function OCommonEmbeddedObject::StoreDocToStorage_Impl line 787:

xDoc->storeToStorage( xStorage, aArgs );

aArgs is constructed just above:

780             aArgs[2].Name = "DocumentBaseURL";
781             aArgs[2].Value <<= aBaseURL;

which comes from a bit above:

765         OUString aBaseURL = GetBaseURLFrom_Impl(rMediaArgs, rObjArgs);

rMediaArgs and rObjArgs are empty sequences and are arguments. So we go up on the call stack:

OCommonEmbeddedObject::storeOwn in embeddedobj/source/commonembedding/persistence.cxx line 1631

1631            StoreDocToStorage_Impl( m_xObjectStorage, aEmpty, aEmpty, nStorageFormat, m_aEntryName, true );


So that's where we need to replace one, or both, of the "aEmpty" by something that makes sense...

Indeed, looking at the output of

git log --grep=96013 -p

to see what change fixed this in OO.org back in 2009, I see in particular:

--- a/reportdesign/source/core/api/ReportDefinition.cxx
+++ b/reportdesign/source/core/api/ReportDefinition.cxx
@@ -1396,14 +1395,25 @@ void SAL_CALL OReportDefinition::storeToStorage( const uno::Reference< embed::XS
     /** property map for export info set */
     comphelper::PropertyMapEntry aExportInfoMap[] =
     {
-        { MAP_LEN( "UsePrettyPrinting" ), 0, &::getCppuType((sal_Bool*)0), beans::PropertyAttribute::MAYBEVOID, 0},
-        { MAP_LEN( "StreamName"), 0,&::getCppuType( (::rtl::OUString *)0 ),beans::PropertyAttribute::MAYBEVOID, 0 },
+        { MAP_LEN( "UsePrettyPrinting" ), 0, &::getCppuType((sal_Bool*)0),          beans::PropertyAttribute::MAYBEVOID, 0 }
+        { MAP_LEN( "StreamName")        , 0,&::getCppuType( (::rtl::OUString *)0 ), beans::PropertyAttribute::MAYBEVOID, 0 }
+        { MAP_LEN( "StreamRelPath")     , 0,&::getCppuType( (::rtl::OUString *)0 ), beans::PropertyAttribute::MAYBEVOID, 0 }
+        { MAP_LEN( "BaseURI")           , 0,&::getCppuType( (::rtl::OUString *)0 ), beans::PropertyAttribute::MAYBEVOID, 0 }
         { NULL, 0, 0, NULL, 0, 0 }
     };
     uno::Reference< beans::XPropertySet > xInfoSet( comphelper::GenericPropertySet_CreateInstance( new comphelper::PropertyS
 
     SvtSaveOptions aSaveOpt;
     xInfoSet->setPropertyValue(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("UsePrettyPrinting")), uno::makeAny(aSaveOpt.IsPret
+    if ( aSaveOpt.IsSaveRelFSys() )
+    {
+        const ::rtl::OUString sVal( aDescriptor.getUnpackedValueOrDefault(aDescriptor.PROP_DOCUMENTBASEURL(),::rtl::OUString
+        xInfoSet->setPropertyValue(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("BaseURI")), uno::makeAny(sVal));
+    } // if ( aSaveOpt.IsSaveRelFSys() )
+    const ::rtl::OUString sHierarchicalDocumentName( aDescriptor.getUnpackedValueOrDefault(rtl::OUString(RTL_CONSTASCII_USTR
+    xInfoSet->setPropertyValue(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("StreamRelPath")), uno::makeAny(sHierarchicalDocume
+
+



Which is exactly the code I started from in my previous comment. So this means (probably) that back in the time, aDescriptor (and thus _aMediaDescriptor) did contain a sensible value (the full path to the .odb file) for "Document Base URL". Need to find why/how this disappeared.

Apparently changed to empty with changeset
2014-06-19 fdo#71076, fdo#71767: Preserve number formats when charts are copied.
Change-Id: If5ae8852152012483237e7602e56a0c46ea8748a

Hi Kohei,

any idea why
  StoreDocToStorage_Impl( m_xObjectStorage, nStorageFormat, GetBaseURL_Impl(), 
was changed to
  StoreDocToStorage_Impl( m_xObjectStorage, aEmpty, aEmpty, nStorageFormat, m_aEntryName, true );

http://cgit.freedesktop.org/libreoffice/core/tree/embeddedobj/source/commonembedding/persistence.cxx?id=1d38cb365543924f9c50014e6b2227e77de1d0c9
@@ -1599,7 +1628,8 @@ void SAL_CALL OCommonEmbeddedObject::storeOwn()

Created attachment 113268 [details]
tentative patch

This patch seems to work... Kohei? Any comment? Is this the right approach, or do you think it would be better to add back "aBaseURL" to the signature (argument list) of StoreDocToStorage_Impl, so that each caller can decide like they did before?

Should m_aEntryName also be set as in the original implementation?

I am asking myself, whether the previous change from GetBaseURL_Impl(), m_aEntryName to aEmpty, aEmpty has an effect on other parts of the software.

(In reply to schaber from comment #13)
> Should m_aEntryName also be set as in the original implementation?

m_aEntryName is still passed exactly as before.

Right. I was confused by the other aEmpty.

Lionel, your patch looks reasonable to me.  If someone can verify that that change doesn't break tdf#71767 and tdf#71076, then it should be okay.

My memory is a bit hazy, but I believe the MediaArg is for the parent document, whereas the ObjectArg is for the embedded document.

(In reply to Kohei Yoshida (inactive) from comment #16)
> Lionel, your patch looks reasonable to me.  If someone can verify that that
> change doesn't break tdf#71767 and tdf#71076, then it should be okay.

If does not break 71767, but I'm not sure I understood the reproduction instructions of bug 71076; it says to paste-as-GDI the *data* but then to look at the chart for the bug, this does not make sense to me.

I'm pushing my patch.

Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b81128f77426b7105530a99b1eba2c580a8fa37

tdf#88624 set DocumentBaseURL when saving report

It will be available in 4.5.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Many thanks. I can confirm that the current issue is resolved with 4.5.

The bots didn't pick up on it, but the fix was committed to 4.4 and 4.3 branch:

https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=208f09646fbeec2940b61d5dd7cce7779ced6f9c
https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=4ea953b468995675f2bcac02e1d512228aa7bb6e

About the fix for 71767 (Copy-Paste problem from Calc to Impress when there are dates in charts) that caused this issue. I can reproduce 71767 with 4.2.5.1, but neither with 4.2.8, nor with 4.5.0 from 2015-02-15 00:50:33 (Win-x86@62-TDF). So, the original fix still seems to work.