Created attachment 113553 [details] Example file containing broken references. There seems to be something wrong with the bibliography reference handling when importing .docx file containing bibliography entries created with Reference Manager software. The references seem to be imported as bookmarks named as _Toc[serial] and the "References" section itself is empty.
Confirmed by looking in the navigator. Win 7 Pro 64-bit, LibO Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: fi_FI Ubuntu 14.10 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
This is a long-standing bug, caused by differences between the way OOXML and ODF model bibliographic entries. Would it be possible to have a tracking bug, so that: a) it's easy for interested users such as myself to see when the support has been implemented. b) it's easy for users who have this problem to find that it's a missing feature. c) for users who do file duplicate bugs, they can be marked as duplicates of the tracker bug. Also, the tracker bug should be exempt from the automatic bot that closes bugs that have not seen activity in a long time. (This is an annoyance with this automatic closing process: bugs about missing functionality are unlikely to be closed simply by the passage of time; by automatically closing such bugs, both users and maintainers are unnecessarily caused a lot of work, either by refiling them over and over again, or by being asked, once a year, to confirm the bug still exists.) For this bug in particular, it's one of the main reasons I still have to use Microsoft Word. I would like not to have to search every year or two to see if it still exists, but simply to find out when the functionality has been implemented. (My understanding is that it's possible to implement with ODF 1.2, it's simply a matter of someone doing the work.)
(In reply to Reuben Thomas from comment #3) > Also, the tracker bug should be exempt from the automatic bot that closes > bugs that have not seen activity in a long time. (This is an annoyance with > this automatic closing process: bugs about missing functionality are > unlikely to be closed simply by the passage of time; by automatically > closing such bugs, both users and maintainers are unnecessarily caused a lot > of work, either by refiling them over and over again, or by being asked, > once a year, to confirm the bug still exists.) There is no such bot. We only mass-close abandoned NEEDINFO bugs. Never confirmed ones.
I'm sorry, you're correct, they won't be closed. However, see for example: https://bugs.documentfoundation.org/show_bug.cgi?id=91903#c2 "LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year." There are plenty of bugs for which this is useful (including perhaps the one I linked to). For bugs which are a clear case of missing functionality, it's not. But this is a side issue. The main question is: can we have a tracker bug for this feature, please?
(In reply to Reuben Thomas from comment #5) > I'm sorry, you're correct, they won't be closed. However, see for example: > https://bugs.documentfoundation.org/show_bug.cgi?id=91903#c2 > > "LibreOffice QA is asking bug reporters and confirmers to retest open, > confirmed bugs which have not been touched for over a year." > > There are plenty of bugs for which this is useful (including perhaps the one > I linked to). For bugs which are a clear case of missing functionality, it's > not. > > But this is a side issue. The main question is: can we have a tracker bug > for this feature, please? Yep, about 20-25% of the pinged reports turn out to be fixed, so it is very valuable. I don't understand your request as this is already a "tracker bug" for this feature/bug fix. META reports are sometimes referred to as tracking bugs, but they are collections of many reports: https://wiki.documentfoundation.org/Tracking_bugs
Tracker bug: I mean a bug whose title is a clear statement of the missing feature (unlike this one, which has a much more specific title), and which other bugs are made duplicates of (unlike this one, which has no duplicates), and which has useful reference links for developers interested in implementing the feature (I once found a very useful discussion of this issue, what is needed, and what is being added in ODF 1.2, which I stupidly didn't bookmark and have been unable to find again). Such a bug should not be pinged (because it will not be fixed by chance!). Pinging has a cost: I have spent several hours over the years repeatedly confirming that bugs I have reported have not been fixed, as they have reasonably been considered by the developers as feature requests. There is little benefit to me or to the developers in my simply confirming, once a year, that three or four features have not magically been added.
(In reply to Reuben Thomas from comment #7) > Such a bug should not be pinged (because it will not be fixed by chance!). > > Pinging has a cost: I have spent several hours over the years repeatedly > confirming that bugs I have reported have not been fixed, as they have > reasonably been considered by the developers as feature requests. There is > little benefit to me or to the developers in my simply confirming, once a > year, that three or four features have not magically been added. Enhancement requests are not pinged. If your reports are not set as enhancements, then you have to correct them (in the severity field). For reference: https://wiki.documentfoundation.org/QA/Bugzilla/Gardening#Task:_Bugs_untouched_for_a_year
Whether a reported issue is considered as an enhancement request or not is up to the maintainers. From my point of view (as in the case of this bug) it may seem to be a bug: here, for example, bibliographies in Word documents do not work correctly when imported and re-saved. From the developers' point of view, this may be an enhancement request, since the reason it does not work is not because of a bug in LibreOffice, but because of missing functionality. In that case, the developers should mark it as an enhancement. How about the improvements to the bug that I suggested?
(In reply to Reuben Thomas from comment #9) > How about the improvements to the bug that I suggested? You are welcome to edit the summary to better reflect the situation and change the severity to enhancement.
I really don't think I'm the best person to do that, but I guess there are too few competent people, so I'll try.
LibreOffice cannot currently handle Word bibliography objects, though this should be possible with a full implementation of ODF 1.2. An out-of-date summary and useful links are here: https://www.openoffice.org/bibliographic/ This description could use some work by someone who actually knows what they're talking about; I'm just an interested user.
Could someone explain what exactly is missing from the example in LO?
If this is the same as bug 129690, that example is better.
Created attachment 160566 [details] destroy bibliography by updating it from bug129690: the attached document contains one bibliography entry with a reference to it. the document contains a screenshot how the entry looks like in microsoft word. when updating the bibliography, it is destroyed. Version: 6.5.0.0.alpha0+ (x64) Build ID: e26d89371f0e4f41476c9a99be01d98dedb76776 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-GB Calc: threaded
*** Bug 129690 has been marked as a duplicate of this bug. ***
*** Bug 135055 has been marked as a duplicate of this bug. ***