Reports appearing on another subtab
Hi guys,
I have a canvas dashboard that has 62 reports across 6 subtabs. When I add reports to subtabs 4, 5 or 6, although all looks fine & dandy in the Edit screen, when I publish the dashboard, the reports from those subtabs appear on subtab 1. When I edit the dashboard again, they appear on the correct subtabs.
If I go into code mode I can see the reports in the HTML code of subtab 1. If I delete them from there and publish, they no longer appear on subtab 1 & appear on the correct subtab, however, I get the below in the console...which both makes sense and doesn't as the elements are present on the canvas & in the HTML code mode of their correct subtabs....
There's nothing funky in this dashboard with the exception of a few reports on subtab 1 having display:none; added to the report-output style attribute.
I've reproduced this twice now. This is on 9.3.1 with the manual tomcat upgrade. Log file attached.
Actually, it doesn't matter what subtab I add things to...any subtab from 2 through 6 adds the element to the HTML code of subtab 1
Actually, it doesn't matter what subtab I add things to...any subtab from 2 through 6 adds the element to the HTML code of subtab 1
Hi Lex,
Thanks for reaching out. This is a known defect. The good news is that it has been fixed and will be published in our upcoming 9.5 build, approximate ETA sometime in March.
There is also a workaround in place: If you enter code mode for the sub-tab you are in and then back into edit mode then any widget change or widget being dropped should take place. Alternately, if code is added to the first subtab, you can either delete from first subtab or cut and paste it into the appropriate sub-tab (depending on whether or not the content was added into the desired subtab at all).
I've set the status of this to Defect Logged and I'll let you know as soon as the new build is published.
Regards,
Mike
Hi Lex,
Thanks for reaching out. This is a known defect. The good news is that it has been fixed and will be published in our upcoming 9.5 build, approximate ETA sometime in March.
There is also a workaround in place: If you enter code mode for the sub-tab you are in and then back into edit mode then any widget change or widget being dropped should take place. Alternately, if code is added to the first subtab, you can either delete from first subtab or cut and paste it into the appropriate sub-tab (depending on whether or not the content was added into the desired subtab at all).
I've set the status of this to Defect Logged and I'll let you know as soon as the new build is published.
Regards,
Mike
Nice one. Cheers Mike.
Nice one. Cheers Mike.
Hi Lex,
You're welcome! I'll keep you posted.
Regards,
Mike
Hi Lex,
You're welcome! I'll keep you posted.
Regards,
Mike
Ah-ha! (Alan Partridge style)... I think this might be responsible for why disabling the brushing doesn't work on these subtabs. Don't suppose you or the devs know a little trick to turn off brushing for a particular chart via the API while we wait for 9.5 do you Mike?
Ah-ha! (Alan Partridge style)... I think this might be responsible for why disabling the brushing doesn't work on these subtabs. Don't suppose you or the devs know a little trick to turn off brushing for a particular chart via the API while we wait for 9.5 do you Mike?
Hi Lex,
This does seem to be related behavior to me as well. I think the means of working around this would be much the same as the method previously mentioned.
My recommendation would be to copy and paste what's in your first tabs' code mode, make that change (disabling the brush), head back into the first tabs' Code Mode content and paste the (what should be) updated code mode content to see what's changed. You can use something like the Compare plugin in Notepad++ to make things easier if the content is rather long. After that, take the identified change and manually insert it into the Code Mode of the subtab and save. This should allow you to pick up the changes you intended to make, but was being added to the first sub-tab.
Hopefully this works, but if not, I strongly suspect this will be resolved by the forthcoming 9.5 fix as well.
Regards,
Mike
Hi Lex,
This does seem to be related behavior to me as well. I think the means of working around this would be much the same as the method previously mentioned.
My recommendation would be to copy and paste what's in your first tabs' code mode, make that change (disabling the brush), head back into the first tabs' Code Mode content and paste the (what should be) updated code mode content to see what's changed. You can use something like the Compare plugin in Notepad++ to make things easier if the content is rather long. After that, take the identified change and manually insert it into the Code Mode of the subtab and save. This should allow you to pick up the changes you intended to make, but was being added to the first sub-tab.
Hopefully this works, but if not, I strongly suspect this will be resolved by the forthcoming 9.5 fix as well.
Regards,
Mike
Do you mean in the HTML tab? It's not going to be an attribute that changes chap, I'm hoping there's a value in the API that changes, I can then change that via code mode...I really don't want to be trawling through the API though, especially if I don't know 100% that it's in there.....needle in a stack of needles springs to mind.
HTML comparison just so you know I'm not making things up :)
Just for clarity, it's this bit I'm trying to turn off.
Do you mean in the HTML tab? It's not going to be an attribute that changes chap, I'm hoping there's a value in the API that changes, I can then change that via code mode...I really don't want to be trawling through the API though, especially if I don't know 100% that it's in there.....needle in a stack of needles springs to mind.
HTML comparison just so you know I'm not making things up :)
Just for clarity, it's this bit I'm trying to turn off.
Hi Lex,
Thanks for your response. I was referring to the HTML tab. Thanks for providing that. If you are making the change via the JS API. There are interaction events contained therein, including one for brushing.
The list of interactions that can be toggled are as follows:
A quick example of outputting a report and turning off brushing would look like this:
Hopefully this helps! If not though, please submit a separate ticket for tracking purposes, as this is getting into territory separate from the originally described defective behavior.Regards,
Mike
Hi Lex,
Thanks for your response. I was referring to the HTML tab. Thanks for providing that. If you are making the change via the JS API. There are interaction events contained therein, including one for brushing.
The list of interactions that can be toggled are as follows:
A quick example of outputting a report and turning off brushing would look like this:
Hopefully this helps! If not though, please submit a separate ticket for tracking purposes, as this is getting into territory separate from the originally described defective behavior.Regards,
Mike
Ok, I'll let you know...that looks like it's for embedded content, I need to do this in a canvas dashboard...I'll have a poke around though, might be enough of a direction for me to figure it out. I'll raise another ticket if not.
Ok, I'll let you know...that looks like it's for embedded content, I need to do this in a canvas dashboard...I'll have a poke around though, might be enough of a direction for me to figure it out. I'll raise another ticket if not.
Hi Lex,
Yep, no problem. Hopefully this gives you something to work with!
Regards,
Mike
Hi Lex,
Yep, no problem. Hopefully this gives you something to work with!
Regards,
Mike
Hi Mike,
Just to add to this defect, it appears to adversely affect linked filters. When the reports start appearing on the first subtab, even though it looks like you've successfully linked the filters, the values are not passed to the added report.
Hi Mike,
Just to add to this defect, it appears to adversely affect linked filters. When the reports start appearing on the first subtab, even though it looks like you've successfully linked the filters, the values are not passed to the added report.
Hi Lex,
Thanks for the additional info. I've noted this, but I suspect this too will be resolved by the main task. 9.5 is being released 12th of March, so I'll remind you once published and we can confirm all aspects are then working as it should.
Regards,
Mike
Hi Lex,
Thanks for the additional info. I've noted this, but I suspect this too will be resolved by the main task. 9.5 is being released 12th of March, so I'll remind you once published and we can confirm all aspects are then working as it should.
Regards,
Mike
Hi Lex,
Just writing to let you know the build containing this fix, 9.5 is now published.
Please upgrade when you get the chance and let us know how goes.
Regards,
Mike
Hi Lex,
Just writing to let you know the build containing this fix, 9.5 is now published.
Please upgrade when you get the chance and let us know how goes.
Regards,
Mike
Hi Lex,
I just wanted to let you know we have just put out 9.5.1 to address 2 issues found in 9.5
We have also removed 9.5 from our downloads page and replaced it with 9.5.
You can reference our V9 release notes here.
Apologies for any inconvenience this may have caused, I welcome any feedback or questions you may have on this, or happy to assist with anything else.
Thanks,
Mike
Hi Lex,
I just wanted to let you know we have just put out 9.5.1 to address 2 issues found in 9.5
We have also removed 9.5 from our downloads page and replaced it with 9.5.
You can reference our V9 release notes here.
Apologies for any inconvenience this may have caused, I welcome any feedback or questions you may have on this, or happy to assist with anything else.
Thanks,
Mike
Replies have been locked on this page!