Reports appearing on another subtab

Lex Clay shared this problem 2 months ago
Defect Fixed

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.

/ccba6bf3cdb49061bfcb128f41513880

Comments (14)

photo
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

photo
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

photo
1

Nice one. Cheers Mike.

photo
1

Hi Lex,

You're welcome! I'll keep you posted.

Regards,

Mike

photo
1

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?

photo
1

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

photo
1

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 :)

<!-- HTML with brushing disabled -->

<report-output widget-uuid="8b4b2682-caa4-432c-9b49-3be9a6175e6f" report-uuid="1d0896b3-98cb-420c-b933-b101e5298c7b" height="400" top="135" left="603" name="Email Account Count" hide-widget-name="true" width="400" display-type="CHART" chart-uuid="e164b208-28b1-482a-8ea7-229b5fb50048" on-click="none" style="z-index: 1;"></report-output>
<!-- HTML with brushing enabled -->

<report-output widget-uuid="47367c46-350f-45fb-a66b-c8c4effcdf9e" report-uuid="1d0896b3-98cb-420c-b933-b101e5298c7b" height="400" top="135" left="603" name="Email Account Count" hide-widget-name="true" width="400" display-type="CHART" chart-uuid="e164b208-28b1-482a-8ea7-229b5fb50048" on-click="none" style="z-index: 1;"></report-output>

Just for clarity, it's this bit I'm trying to turn off.

/983109d77b6345c6cd72c5f38b8abbf6

photo
1

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:

  • drillDown
  • drillAnywhere
  • drillThrough
  • drillBreadcrumbs
  • seriesSelection
  • unitSelection
  • brushing
  • timeSlider
  • annotations

A quick example of outputting a report and turning off brushing would look like this:

<!DOCTYPE html>
<script src="http://<YOUR YF URL>/JsAPI/v3"></script>
<div id="report"></div>

<script>
    //drillDown
    window.yellowfin.loadReport({
        reportId: "dcbf46cd-1315-49e7-9b8a-44a854cd46bc" //replace uuid with the one for the report you want to test
    }).then(reportAPI => { 
        document.querySelector('div#report').appendChild(reportAPI.createReportElement({ 
            interactions: {
                brushing: false //this is where you can toggle any interactions relevant to the report
            }
        })); 
    });
</script>
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

photo
1

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.

photo
1

Hi Lex,

Yep, no problem. Hopefully this gives you something to work with!

Regards,

Mike

photo
1

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.

photo
1

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

photo
1

Oh nice...don't suppose there's any chance of getting an early installer is there?

photo
1

Hi Lex,

We only provide interim builds in quite rare scenarios, typically when there's a high visibility defect with a high business impact and no suitable workarounds. I'm not quite sure this case meets that criteria, but if my understanding is incorrect I can reach out to the dev team to determine the possibility of obtaining one.

Regards,

Mike

photo
1

Email me chap... lex@rhinoit.co.uk got some info but not for here

photo
1

Hi Lex,

Sounds good. Will do.

Regards,

Mike

photo
photo
1

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

photo
1

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

  • Can't save configuration settings in a client org
  • JS API CSS loading issues

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

photo
1

Righto..cheers bud. I'll run the update at some point. Those issues in 9.5 aren't affecting us yet, there's plenty that are but not those two :)

I haven't seen the elements appearing on another dashboard yet but I haven't added that many either. You can close this ticket off if you like & I'll just come back to it if it reappears.

photo
1

Hi Lex,

Sounds good. Thanks for letting me know!

Regards,

Mike

photo