Since we upgraded confluence server to 6.9.0, when a table (with table head) is put inside an expand, the first data row (so the row after the table head) becomes unselectable and acts as a sorter when clicked on (like an actual head). All our tables inside expands act like this since the upgrade. The editor confirms those rows really shouldn't be table headers though.
Working workaround is adding a row above that row (which then gets that behaviour), but it is still very annoying and for documents that need to be exported from time to time this workaround isn't really possible as this extra row also shows up in the pdf.
Is there any other way to solve this?
I have a similar issue with Page Properties Report inside Expand macro. Also the first row after the table header repeats when navigating between report pages.
Found it on Confluence 6.8 and 6.9.
Same issue. Page Properties Report macro inside an Expand macro causes the first data row after header to become fixed (or header row 2) instead of treated as a data row. Screenshots attached show that sorting by Report Page Name column doesn't actually sort the first row, and that all the items are blue as you would expect in a header row.
Interestingly, the Preview pane of the Page Properties Report editor displays the rows and sorts as expected.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Haakon,
Thank you for providing those screenshots.
I believe you are running into this issue:
When using the Page Property Report inside an Expand Macro, the macro is no longer sortable when using multiple columns inside the report.
Could you please have a look there and confirm if you agree it is the same? If so, voting on the issue will help raise its priority, according to our Bug Fixing Policy.
Thank you for your understanding!
Regards,
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Shannon,
That looks like the same bug, although impact is worded differently (unable to sort vs fixed/un-selectable 1st data row). However, in the comments of the bug, they mentioned the fixed row behavior I experienced.
Thanks for linking the policy and ticket; it underscored for me that this is unlikely to be fixed and deployed in a meaningful timeline given that the ticket was submitted in March of 2018, acknowledge with no workaround, and is still in 'gathering impact' status. This, while frustrating, is good to know so I can set expectations with our users to plan for bugs not being fixed, and instead consider alternative or workaround methods to be the actual permanent solution.
Thanks,
-Haakon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Haakon,
Thank you for taking the time to read through our policy. Since the combination of the two macros together causes this error, the likelihood of a user running into this issue is less than say, an issue with expand macro on its own. For this reason, it is accurate that it may not be addressed as soon as other bugs that are open. I would still recommend keeping an eye on it and comment with your usage case and findings. The more traffic and votes an issue gets, the priority increases.
Take care, and have a pleasant weekend.
Regards,
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Mikel,
Could you show us an example of the behavior you're experiencing? You can create a test page in your instance with example data, and illustrate using a screen recorder such as Screencast-o-Matic. That way we can replicate it and confirm the behavior.
Thank you!
Regards,
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Shannon S I provided some screenshots below of the behavior, is there any update on this over the past 6 months?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for providing those details, Haakon.
I believe it to be an open bug case, which I replied to your other answer.
Could you please confirm there?
Regards,
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.