-
Bug
-
Resolution: Won't Fix
-
Low
-
None
-
5.1.4
Create two different Page Properties macros with the same label. Place one different table in each macro:
| Industry/Market | Market |
| Title of Project | Testing |
| Client | All |
| Main Install Locations | Honeywell |
| Home Office Pole | Asia |
| Home Office Country | India |
| Sales Contact | Honeywell |
| Lead Engineer | Engineer1 |
Then, create Page Properties Report macro with that label, and the data appears in two separate lines, rather than one single line. This is despite sharing a label.
[CONFSERVER-30881] Data from shared label in page properties macro appears on two lines in page properties report macro
Marcin Mikołajczak
added a comment - I believe there are 3 scenarios to consider here:
1. Separate Page Properties macros with different labels
2. Separate Page Properties macros with the same labels (or none)
3. One Page Properties macro with multiple tables
In my opinion (1) should be solved as described in CONF-28776.
How (3) works at the moment is that only the first table in the macro is processed. This should really be fixed to process all tables in the macro. Why would anyone want to split the table into multiple parts? It would be very useful for layout purposes, i.e. would enable doing 2-column layouts, or adding headings and hints to groups of properties to make filling them out easier for users.
As far as I am concerned (2) could behave in either way, i.e:
a) merge properties into 1 entry because they share labels and the parent document,
b) produce separate entries because the macros are separate.
Both solutions seem reasonable.
Marcin Mikołajczak
added a comment - I believe there are 3 scenarios to consider here:
1. Separate Page Properties macros with different labels
2. Separate Page Properties macros with the same labels (or none)
3. One Page Properties macro with multiple tables
In my opinion (1) should be solved as described in CONF-28776 .
How (3) works at the moment is that only the first table in the macro is processed. This should really be fixed to process all tables in the macro. Why would anyone want to split the table into multiple parts? It would be very useful for layout purposes, i.e. would enable doing 2-column layouts, or adding headings and hints to groups of properties to make filling them out easier for users.
As far as I am concerned (2) could behave in either way, i.e:
a) merge properties into 1 entry because they share labels and the parent document,
b) produce separate entries because the macros are separate.
Both solutions seem reasonable.
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on bugs with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If demand for this picks up, we will reopen the issue.