Download it now!
Bug 47256 - MAILMERGE: Field "Statistics - Pages" becomes static number in resulting merged document
Summary: MAILMERGE: Field "Statistics - Pages" becomes static number in resulting merg...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Mail-Merge
  Show dependency treegraph
 
Reported: 2012-03-12 18:29 UTC by FDF
Modified: 2018-11-26 14:33 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
The source letter for the merging sample (14.28 KB, application/vnd.oasis.opendocument.text)
2012-03-12 23:25 UTC, FDF
Details
sample of merged result. (14.69 KB, application/vnd.oasis.opendocument.text)
2012-03-12 23:26 UTC, FDF
Details

Note You need to log in before you can comment on or make changes to this bug.
Description FDF 2012-03-12 18:29:27 UTC
Problem description: 
I merge documents with a database to pre-fill some blank forms (actually simple odt document).
In the header, I have a field with the "Number of page" (as well a field "Page number")
After merging in separate files, the field  "Number of page" is no more a field but the number of page at the time of the merging

I was expecting to keep the field as later, when filling the doc the number of page may change…


              
Browser: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Comment 1 Rainer Bielefeld Retired 2012-03-12 22:28:35 UTC
@reporter:
Thank you for your report – unfortunately important information is missing.
May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that  is really sophisticated please as for Help on a user mailing list
Please:
- Write a meaningful Summary describing exactly what the problem is
- Attach a test kit with sample document and merge result (not only screenshot) 
- Attach screenshots with comments if you believe that that might explain the 
  problem better than a text comment. Best way is to insert your screenshots
  into a DRAW document and to add comments that explain what you want to show
- Contribute a step by step instruction containing every key press and every 
  mouse click how to reproduce your problem (due to example in Bug 43431)
– if possible contribute an instruction how to create a sample document 
  from the scratch
- add information 
  -- what EXACTLY is unexpected
  -- and WHY do you believe it's unexpected (cite Help or Documentation!)
  -- concerning your PC 
  -- concerning your OS (Version, Distribution, Language)
  -- concerning your LibO version and localization (UI language, Locale setting)
  –- Libo settings that might be related to your problems 
  -- how you launch LibO and how you opened the sample document
  -- everything else crossing your mind after you read linked texts

Even  if you can not provide all demanded information, every little new information might bring the breakthrough.

I recommend to try with a current version.
Comment 2 FDF 2012-03-12 23:25:10 UTC
Created attachment 58352 [details]
The source letter for the merging sample
Comment 3 FDF 2012-03-12 23:26:19 UTC
Created attachment 58353 [details]
sample of merged result.
Comment 4 FDF 2012-03-12 23:33:05 UTC
The two attached files are an exemple.
The first one is the source letter, before the merging. To ease the test, I have used the Bibliography database as data source.
The second one is one result of the merging using the wizard, with the option :Save as separate files (nota, as my computer is set in French, I don't know the exact name of the option)

The result seems unexpeced as:
- The other fields (as page number for exemple) are kept as a field.
- The choice of using a field for the number of page means the author expect to have different number of page and not only one.
Comment 5 Rainer Bielefeld Retired 2012-03-25 04:32:34 UTC
@FDF:
Reminder:
all Info except source and result documents still are missing, especially why you expect different behavior. Please contribute!
Comment 6 FDF 2012-03-25 18:40:09 UTC
To the question: Why this behavior is unexpected, there are two reasons, but none obvious.
I haven't seen in the documentation that after merging, the files as number of pages… should remain fields, or should be changed to their data.

However, 
it was the case with the previous LibreOffice release. The change appears only since LibreOffice3.
Other fields continue to remain fields after merging. For exemple the "Page number" field remain a "Page number" Field. It is not logical to have this one still flexible as a field and the total number of page no more flexible as merged as data only.
Comment 7 Rainer Bielefeld Retired 2012-03-25 21:37:56 UTC
I don't believe it's a bug. May be different behavior in versions before was a bug that has been fixed? For example, in OOo 3.1.1 "No of pages" showed "118" instead of "2" for 59 biblio-"addresses".

This contents will not change after mailmerge process, so it should become "constant contents, like a date field, the address fields, ... . I am more astonished that the current page filed remains a field 

But indeed, may be that there are inconsistencies and may be incomplete or worrying help texts.

Currently I do not see necessity for quick action. 

@FDF:
I would be great if you could gain more information. If we had a complete list (table) with

Variable ... current behavior ... expected behavior ... because ... Help text (Heading, search string) (as a simple text document attachment here) to get a complete overview? May be we can recognize a pattern.
Comment 8 FDF 2012-03-26 00:09:05 UTC
To Rainer,

My choice in the exemple of biblio database has been unfortunate.
We shouldn't comparde the number of page coming from the database and the number of page of the resulting document.
Having the number of page coming from the database as a static information is normal. It is the purpose of merging docs.
But having the number of page of the resulting document as static is not good as any further change in the pagination of the resulting document won't be taken into account and would lead to mistake. for exemple, if we add a page on the resulting doc, we would have printed "page 3 of 2" whish is a mistake. If this remains dynamic, we would have "page 3 of 3" whish is normal.

I hope to have been clear.
Comment 9 Rainer Bielefeld Retired 2013-04-03 05:45:44 UTC
I already see in OOo 2.0 that Page No keeps field, but number of pages becomes static in merged.odt

And indeed, I think that is a Bug.

Steps to reproduce:
1. Open "Merging_test_main_file.odt"
2. Menu 'Tools -> Mailmerge Wizard - Use Current Document -> <Next> -> Slect
   Document Type "Letter -> <Next>'
3. In 'Select Address List' add biblio Database from
   C:\....\AppData\Roaming\LibreOfficeDev\4\user\database\biblio\biblio.dbf
   or similar
   and select
   <next><next>
   > Mail Merge Document will become created
4. In step 7 "Personalize document": 'Edit individuall document'
   > Document with 40 pages or so will be opened
5. On first page behind text inserg 4 Page breaks with menu 'Insert'
   > Now you have 44 pages or so
6. Check first Document Headings, result:
   Is:               .... page 1/2  ... page 6/2
   Should be:        .... page 1/6  ... page 6/6

Problem: If the resulting document may be edited in Step 7 it can not be excluded that Number or pages will change, and so it's a bug that "Number of Pages" field has become a static number

@Caolán:
Please change  Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf
Comment 10 Alex Thurgood 2015-01-03 17:40:44 UTC Comment hidden (no-value)
Comment 11 QA Administrators 2017-10-23 14:01:51 UTC
** 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!

Warm Regards,
QA Team

MassPing-UntouchedBug