cancel
Showing results for 
Search instead for 
Did you mean: 

Javascript custom properties

Tim
10 - ETL
10 - ETL

I wrote javascript that creates a dashboard filter. I want my javascript to mark which filter it created. That way, on the next refresh, it can update or delete it if needed.

I've done that by creating a new property like this: dashboard.filters(choose the one I want).jaql.MyNewProperty = "true".

My question is: It's working for me now, but is this solution robust long-term? Any caveats I should be aware of? Are custom properties on widgets/filters/etc. a good tool for future projects? 

1 ACCEPTED SOLUTION

rapidbisupport
11 - Data Pipeline
11 - Data Pipeline

Hi @Tim ,

We (at RAPID BI) initially struggled to make custom properties 'stick' to items. These were metadata items as well as filter items. I remember this issue when I was extending our internal RAPID BI Hide Filters plugin, that allowed our designers to set and then hide filters on the filter shelf. I'm not sure if this is still the case in 2024.2.

As a rule of thumb, we try to add custom properties to the style or options properties within a widget or dashboard. In the case of the hideFilters, a work around I found for this was to create an array under dashboard.style.hiddenFilters = [filterid1, filterid2, ...] for those hidden that I wanted to reference afterwards.

This coupled with the dashboard.updateDashboard(dashboard, "filters"); or widget.changesMade() ensured the property was saved on either a widget or dashboard level (i think in the background, this does some PUT request against the widget/dashboard and updates the definition in mongo prismDB).

Additionally, I don't think you'd want to store any 'large' data here, but I have seen instances where plugins have hijacked the 'format' object on metadata items (widget.metadata.panels[i].items[j].format) and added lots and lots of per-value formatting definitions (I think this was the community custom bar chart addon that no longer seems to work).

This said, i'd love to hear how others have tackled this situation. It'd be good to hear Sisense input ( @DRay ?) on this also, although I suspect they'd probably bring up the https://sisense.dev/guides/restApi/custom-data.html as a more official way of storing data like this (which we also use, but in other plugins and scenarios).

Would be happy to talk through some of the things we considered on this if you'd like - feel free to take us up on our free 30-minute consult: https://www.rapidbi.com.au/sisense-add-ons/Services/Free-30-Minute-Sisense-Consultation/

Let me know how you go?

Thanks,

Daniel

RAPID BI

[email protected]

RAPID BI - Sisense Professional Services | Implementations | Custom Add-ons

 

View solution in original post

3 REPLIES 3

rapidbisupport
11 - Data Pipeline
11 - Data Pipeline

Hi @Tim ,

We (at RAPID BI) initially struggled to make custom properties 'stick' to items. These were metadata items as well as filter items. I remember this issue when I was extending our internal RAPID BI Hide Filters plugin, that allowed our designers to set and then hide filters on the filter shelf. I'm not sure if this is still the case in 2024.2.

As a rule of thumb, we try to add custom properties to the style or options properties within a widget or dashboard. In the case of the hideFilters, a work around I found for this was to create an array under dashboard.style.hiddenFilters = [filterid1, filterid2, ...] for those hidden that I wanted to reference afterwards.

This coupled with the dashboard.updateDashboard(dashboard, "filters"); or widget.changesMade() ensured the property was saved on either a widget or dashboard level (i think in the background, this does some PUT request against the widget/dashboard and updates the definition in mongo prismDB).

Additionally, I don't think you'd want to store any 'large' data here, but I have seen instances where plugins have hijacked the 'format' object on metadata items (widget.metadata.panels[i].items[j].format) and added lots and lots of per-value formatting definitions (I think this was the community custom bar chart addon that no longer seems to work).

This said, i'd love to hear how others have tackled this situation. It'd be good to hear Sisense input ( @DRay ?) on this also, although I suspect they'd probably bring up the https://sisense.dev/guides/restApi/custom-data.html as a more official way of storing data like this (which we also use, but in other plugins and scenarios).

Would be happy to talk through some of the things we considered on this if you'd like - feel free to take us up on our free 30-minute consult: https://www.rapidbi.com.au/sisense-add-ons/Services/Free-30-Minute-Sisense-Consultation/

Let me know how you go?

Thanks,

Daniel

RAPID BI

[email protected]

RAPID BI - Sisense Professional Services | Implementations | Custom Add-ons

 

DRay
Community Team Member
Community Team Member

Hello @Tim ,

I wanted to follow up to see if the solution offered by @rapidbisupport worked for you.

If so, please click the 'Accept as Solution' button on the appropriate post, that way other users with the same questions can find the answer. If not, please let us know so that we can continue to help.

Thank you.

David Raynor (DRay)

Tim
10 - ETL
10 - ETL

Hi Daniel(s),

Thanks for your reply - it's reassuring seeing someone else working with custom properties like this.

"... add custom properties to the style or options properties ... dashboard.updateDashboard ..." - Thanks for the tip. I guess otherwise there's a chance the custom property gets lost depending on what combination of refresh/user-logout/server-reboot/etc. happens. My Version1 is storing the property within the filter object, which seems stable so far, but I'll shift it to dashboard.options if we find any issues.

"consult" - I'll keep you in mind. Good to know you're available as a resource.