Created attachment 117552 [details]
template directory containing two templates for reproducing the bug
Steps to reproduce:
1. Go to subdirectory "4/user" the user's LibreOffice configuration directory (Linux: ~/.config/libreoffice/4/user)
2. Unzip the attached file creating the user's "template" directory containing two OTT templates and ODT documents of the same name:
3. Open LibreOffice and go to "My templates" in the template manager
There are now two templates "Privatbrief Arial" and "Privatbrief Latin Modern Roman".
There is only one template "Privatbrief Arial"
Delete or rename the ODT file corresponding to the ignored OTT file and restart LibreOffice. Now, both templates appear in "My templates".
Note that for the other OTT template Brief_Arial.ott, the ODT file with the same name did not influence the appearance of the template. I could also reproduce this with a collection of 5 files, 2 did appear, 3 did not, so it does not depend on the number of template files in the directory.
LibreOffice 188.8.131.52 (from Debian Linux) is not affected.
LibreOffice 184.108.40.206 from Ubuntu 14.04 is also affected.
However, here, no template is listed in the templates manager and renaming the ODT file does not help (only deleting).
Ubuntu 15.04 x64
New - confirmed;
Minor - can slow down professional quality work but will not prevent it (just don't save odt files in the template folder....but I guess this can confuse people);
Low - default
Requesting a bibisect for this as user says it's a regression.
@Michael Fiedler - thanks for the report! If you ever have some free time and want to get more involved, feel free to come say hello in our chat: http://webchat.freenode.net/?channels=libreoffice-qa
I can't reproduce this using the instructions in comment 0 on any version including 220.127.116.11.
(If you see no templates at all on 18.104.22.168, possibly it's not using the config directory you think it is? This can easily be checked by importing any single file with some distinguishable name as a template, then looking for it in the directory)
On current master I get an error for two of the files if I attempt to import all four as templates at once from within LO rather than just placing them directly into the templates directory. Immediately afterwards only one of the two templates is visible, but both templates do show up if I restart LO.
This is an issue, but not exactly the same as the original report.
@jmadero: Do you really see only one template? The issue reported isn't that the .odt files aren't visible, but that one of the two templates is missing altogether - if so, there's some other factor preventing this from being reliably reproduced
Nope the problem is as described. I can't see the template if there is a corresponding odt - as soon as I delete the odt (with no other change) the template becomes visible in the template manager.
Migrating Whiteboard tags to Keywords: (bibisectRequest)
Looks like this was introduced around 4.1. Bibisect below:
868359ac2b3f51e2249ca85637f687499c0e1109 is the first bad commit
Author: Bjoern Michaelsen <firstname.lastname@example.org>
Date: Wed Oct 16 02:33:24 2013 +0000
Author: Tor Lillqvist <email@example.com>
AuthorDate: Thu Jan 10 15:13:49 2013 +0200
Commit: Tor Lillqvist <firstname.lastname@example.org>
CommitDate: Thu Jan 10 15:13:49 2013 +0200
:100644 100644 8f49301d82652594c549e4fe479c79e0556c2ac7 4f3627f5907b97ff0ed828eef7528a7fc2ea08ef M autogen.log
:100644 100644 53189d9b41b25f4ff7af9c3988b5c00e0c320fae e92d710bc25bc22f84e55e154f06cb98cee561d1 M ccache.log
:100644 100644 f403c38efd33a5e3ba5f8c40d40de1c5669bedce 6fd8bb4d985c6b4f6bfab365fe328c3482fa74cb M commitmsg
:100644 100644 946187a09d2c1f5780d06494a4f35bcfc1c0f31a c412904f68797da36369e223eea958345eae065d M dev-install.log
:100644 100644 9e29c577fe2b7a591a949771610796e5367e6368 f308744786e2f88dc97507b6b9f2fbb3cd42363d M make.log
:040000 040000 32968362d6b686b80d8816909c00da933f0d6ed1 2225796a4e53ca5ee7abff22ca95345626c46b97 M opt
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327
# bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e
git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02
# good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28
# good: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
git bisect good d65a58c31c8da044ef66ae4517fa2fe74cec0019
# good: [00f5ea8ff23485332a8009f8017ae95cd5f83fa4] source-hash-4ef5ed9d21de767ce1b4c70d73cf15994b38dcdb
git bisect good 00f5ea8ff23485332a8009f8017ae95cd5f83fa4
# good: [b9da5d7ef8baf81aa867fc44cb6d8ebb6036201b] source-hash-ec376c2934e77fd1b56da892cfe2c1393f4c8156
git bisect good b9da5d7ef8baf81aa867fc44cb6d8ebb6036201b
# bad: [2432222b43bc847d69313b670fb66f5481c6510e] source-hash-194ba3a2cacbb5438dfcb8fb35167055e01ca251
git bisect bad 2432222b43bc847d69313b670fb66f5481c6510e
# bad: [868359ac2b3f51e2249ca85637f687499c0e1109] source-hash-f340cbb6af86c7046d34202d2781a68b0d991001
git bisect bad 868359ac2b3f51e2249ca85637f687499c0e1109
# good: [14986294151c475338ee0d34eb77a6a0673bb8d2] source-hash-7e2b1e9218b194ba244dfa23089ec30fd978f3de
git bisect good 14986294151c475338ee0d34eb77a6a0673bb8d2
# first bad commit: [868359ac2b3f51e2249ca85637f687499c0e1109] source-hash-f340cbb6af86c7046d34202d2781a68b0d991001
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=7e2b1e9218b194ba244dfa23089ec30fd978f3de..f340cbb6af86c7046d34202d2781a68b0d991001
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!