Bug 129583 - INSERT INDEX ENTRY DIALOG: Insert button ignores "Entry" field when multiple entries made
Summary: INSERT INDEX ENTRY DIALOG: Insert button ignores "Entry" field when multiple ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: TableofContents-Indexes-Dialog
  Show dependency treegraph
 
Reported: 2019-12-23 13:58 UTC by R. Green
Modified: 2020-04-06 09:38 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Dummy text plus alphabetical index (28.77 KB, application/vnd.oasis.opendocument.text)
2019-12-23 13:58 UTC, R. Green
Details

Note You need to log in before you can comment on or make changes to this bug.
Description R. Green 2019-12-23 13:58:40 UTC
Created attachment 156756 [details]
Dummy text plus alphabetical index

Please open the attached writer file, which consists of some dummy text with an alphabetical index (blank) at the end.

1. Make sure the "Insert Index entry" dialogue is open (Insert > Table of Contents and Index > Index entry …).

2. Select the word "quiet" in the first sentence, say. Click on the "Update entry in selection" in the "Insert index entry" (IIE) dialogue; then press "Insert."

3. Now select a different word on the second page. In the IIE dialogue press "Insert."

4. Now update the alphabetical index by right-clicking on it and selecting "Update index."

EXPECTED RESULT: In step 4, since the word "quiet" is still visible in the "Entry" field, the new word should also be entered as "quiet." The correct result should therefore be two entries, for different pages, under the SAME word, "quiet." 

ACTUAL RESULT: In step 4, the "Insert" command ignores the word in the "Entry" field and enters the selected word instead. This results in the INCORRECT addition of a second entry as a different term.
Comment 1 R. Green 2019-12-23 14:02:11 UTC
Erratum: Under "EXPECTED RESULT", should read, "In step 3 …".
Comment 2 Dieter 2019-12-29 09:38:47 UTC
I can't confirm it with

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

and also not with

Version: 6.3.4.2 (x64)
Build-ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

Which version of LO do you use? Please paste informations from Help => About LibreOffice

If it is not the actual version, please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
Comment 3 R. Green 2019-12-29 13:54:35 UTC
I have repeated the procedure and the bug is definately present with

Version: 6.3.4.2 (x64)
Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-GB
Calc: threaded

E.g. If (using the above procedure) "quiet", on p. 1, is the first word added, and "waiting", on p. 2, is the second word added, the index should look like this:

quiet ......................................... 1, 2

and NOT:

quiet ............................................. 1
waiting ........................................... 2
Comment 4 R. Green 2019-12-29 14:38:30 UTC
Bug also confirmed in:

Version: 6.4.0.0.alpha1 (x64)
Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-GB
Calc: threaded
Comment 5 Dieter 2019-12-29 19:23:46 UTC
Not clear to me, if you have enabled "Apply to all similar texts" and "Match Case" in Insert Entry Dialog.
Comment 6 R. Green 2020-01-01 13:11:43 UTC
DP commented: "Not clear to me, if you have enabled "Apply to all similar texts" and "Match Case" in Insert Entry Dialog."

The answer is NO, I haven't enabled them.


BTW, this issue only occurs when the "Entry" field is exactly the same as the first word selected. If for example you repeat the procedure but this time add the word "steps" to "quiet" in step 1 (to give "quiet steps"), the bug does not occur. Instead you get

quiet steps........................................... 1p.

which is correct.
Comment 7 Dieter 2020-04-03 17:04:28 UTC
I've just had a look again to this bug, and now I understand it better and can confirm it with

Version: 7.0.0.0.alpha0+ (x64)
Build ID: 1c9ced04189c9d23ffea05d5570960b54b05ef28
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: CL

I'm not an expert with Alphabetical Index in Writer, but behaviour is not in line with LO help [1] and so I would consider this as a bug.

cc: Design-Team to decide, if it is a bug in Writer or a wrong documentation
Comment 8 Dieter 2020-04-03 17:08:14 UTC
(In reply to Dieter from comment #7)
> I'm not an expert with Alphabetical Index in Writer, but behaviour is not in
> line with LO help [1] and so I would consider this as a bug.
> 
> cc: Design-Team to decide, if it is a bug in Writer or a wrong documentation

[1] https://help.libreoffice.org/7.0/en-GB/text/swriter/01/04120100.html?System=WIN&DbPAR=WRITER&HID=modules/swriter/ui/indexentry/dialog-action_area1#bm_@@nowidget@@
Comment 9 Heiko Tietze 2020-04-06 09:38:11 UTC
(In reply to Dieter from comment #7)
> ... behaviour is not in
> line with LO help [1] and so I would consider this as a bug.

Me too. IIE dialog always take what is selected while the "Entry" field show the last updated term. It's not only unclear what term is used but also not possible to put another index term on the selected word (like "silent" for "quiet", to use the example). Clearly a bug, and I would raise the severity.