As Gareth noted years ago the CHT has some significant limitations to its customization/functionality. Without a plugin architecture, developers seeking to make deep customizations to the CHT can only fork the repo and modify the core source code. This works, but is a lot of effort for the partners to maintain.
A better approach would be to support a plugin architecture with clearly defined features/interfaces. This would reduce the effort for creating custom experiences in the CHT and make it much easier/safer to maintain those experiences when upgrading to new versions of the CHT.
@Anro has recently re-started the conversation in a serious way both in this GitHub issue and by providing a working Proof of Concept PR! Building on this momentum, I think the time has come to form a formal squad to pursue this feature! (See the docs for details about squads.)
The term “plugin” is very broad (see the examples in the link above). As a squad, we will have to narrow the scope down to a specific MVP that we can pursue first. This MVP should be as tightly scoped as possible, but should still address a real-world need. (Thanks again to @Anro for already providing some initial ideas/examples of both in his PR.)
Please reply here on this thread if you are interested in participating in the squad!
Awesome! Thank you to everyone for expressing interest! I am looking forward to some great collaboration here.
To get things moving, I am going to schedule a Kickoff Meeting. Please indicate your availability for any/all of these times next week! I will send an invite for the slot that works for the most folks. (The Tues/Thurs time slots do overlap with existing community meetings, so if you can make Friday work that would be best! But, if Tues/Thrus is better for more folks, then I would rather go for the overlap…)
Tues Nov 4th - 13:00 UTC
Thurs Nov 6th - 13:00 UTC
Fri Nov 7th - 13:00 UTC
0voters
Additionally, I have started drafting a Requirements and Design doc. If you have some specific problems that you think could be addressed via a CHT plugin, please add it to this section. If you have any examples of plugins in other software frameworks that would be a useful reference, please add them to this section.
Thanks for the responses to the poll! Lets lock in the kickoff meeting for this Friday, November 7th at 13:00 UTC.
Google Meet joining info
Video call link: https://meet.google.com/xsz-wuns-qhh
Or dial: <U+202A>(US) +1 601-840-3051<U+202C> PIN: <U+202A>407 228 208<U+202C>#
More phone numbers: https://tel.meet/xsz-wuns-qhh?pin=1642201141004
Thank you everyone for an awesome kickoff on Friday! Checkout some basic notes from the meeting here and also the design doc here.
We decided to pursue a plugin solution that would allow for adding custom UI content to the CHT webapp. Exactly what that means is still TBD.
Now I would like to schedule a recurring (weekly) squad meeting to help keep things coordinated and moving forwards. Let me know which times would typically work for you.
Thank you everyone for your patience here as we get this all together! Based on the the responses to the poll, I have booked a recurring meeting for Thursdays at 14:00 UTC, starting next Thrusday, Nov 27th. Everyone on this thread should have gotten an email invite to the meeting (let me know if you did not). Also you can see the meeting on the CHT Community Calendar.
CHT Plugins Squad
Thursday, November 27 · 14:00 – 15:00 UTC
Google Meet joining info
Video call link: https://meet.google.com/bzu-okav-mjd
Or dial: <U+202A>(US) +1 530-395-0819<U+202C> PIN: <U+202A>970 874 731<U+202C>#
More phone numbers: https://tel.meet/bzu-okav-mjd?pin=6724029925222
Looking forward to diving in deep on our ideas for how to implement custom UI plugins!
I wanted to document our current (very rough) approach to “embedding” an external Power Bi report into the app. Unfortunately, context switching did me no favours and I ended up conflating two semi-different ideas and hope to clear that up as well.
Thanks again @diana for raising the point about allowing the Power Bi endpoint in the contentSecurityPolicy. I neglected to mention we did update the api/src/routing.js file’s helmet my adding:
Furthermore, we added the PowerBi embed token generation methods. Linked the example code to not unnecessarily lengthen this post.
Then we exposed a new API route for use by our webapp:
/api/v1/powerbi/report/:reportId
What also escaped me in the call was the detail about eventually passing along the role info about the logged in user to PowerBi to determine access or row-level detail visibility. In addition to that, we also wanted to explore if it was possible to tap into the environment variables exposed in our Azure container app (containing our api & webapp). If this is possible, we can use that info to authenticate via service principle.
Over in the webapp, we created a lightweight wrapping component for the powerbi-client library. All it does is:
define the placeholder inline template html
create a reference to that placeholder div
after view init, we try to reach out to our new endpoint with the id of the report we’re interested in. The returned “embed config” is then passed into the lib’s powerbiService.embed method, along with the placeholder reference
Using some of the code in the PR we introduced the wrapping component an additional tab that, when clicked, displays a full-page interactive report to the user.
Of course, this has not been “pluginized”. Not the same config driven “embed” I showcased in the PR, sorry again.
If memory serves, we hope to use this functionality to display a “coverage map” (among other things). Similar to what was discussed in the earlier meeting. The development of that report is outside of my purview, so I lack some of the details.
Building on this momentum, I think the time has come to form a formal squad to pursue this feature! (See the docs for details about squads.)
…
But, if Tues/Thrus is better for more folks, then I would rather go for the overlap…)
Lets lock in the kickoff meeting for this Friday, November 7th at 13:00 UTC.