Plans about the future of this module?

[Taitava]

Hi @unclecheese

I understand you might be busy with other projects :). As there are quite many old, open issues and a few pull request (i.e. one created by me a year ago and another quite nice one), I'd like to know if you have any plans on continuing the development of this module? :)

If you do not have time for this module, would you like to have some helpful hands? I think in this case we would need to have a clear roadmap about what needs to be focused on: a glance at the currently open issues and short comments on each issue: which are feasible to do, and which are obsolete or too mysterious to solve. And of course your ideas: what the future of this module should be? :)

Thanks and happy new year! :)

[unclecheese]

Wow, awesome work. Sorry I missed it. There was a two or three month period that I wasn't getting emails from Github, and I missed a lot of this type of stuff. Glad you reached out!

The PR has been merged, and I've started a new 4.x and 3.x release line. I've taken it on good faith that you have this running in production, as I don't have time for a full review, and the net benefit to the community is too great to block it. Hope you're right. :-)

Would love to be able to use this in SS4 projects, myself!

Can I add you as a contributor to this module?

[Taitava]

Thanks! And no problem :).

I have it in production on just one project, so I have to admit that the testing has not been very throughout. Which brings in my mind that both ui testing and unit testing are areas where I should improve my skills :).

And one thing to note about the SS4 compatibility is that when I created my pull request, I removed all the default dashboards for these reasons: 1. Finish the upgrading work more quicker, 2. I didn't know how to test all of the default dashboards, and 3. I don't know whether all panels should be upgraded to SS4 or if some of them are obsolete?

Thanks, sure you can add me as a contributor :). Or did you mean a collaborator? Sorry, these terms are not familiar to me. It's actually the first time I've been added to an other person's project as a collaborator. So I'm not aware of for example the release process/policy (how to test everything widely enough; should I create releases or just do merging and let you create all releases?).

Maybe I could write some tests for this module (can't promise anything though). I've written very simple unit tests for SilverStripe in other projects, but I need to study on fixtures and user interface testing, both of them are new things to me. I tried to do some fixture testing in SilverStripe some time ago, but needed to give up back then due to some mysterious errors when trying to load the fixtures.

So, to sum it up:

• Which default dashboards should be upgraded to SS4?
• What would be my role as a contributor/collaborator?

:)

[Taitava]

One thing that came to my mind: should the default panels be actually separate modules? It might be a hit or miss: on one hand, separate modules would allow to not include code that's not needed (i.e. WeatherPanel is not needed in every project), but on the second hand there would be quite a lot of really small modules, so it could clutter up your GitHub account, and also composer.json in a project that uses many of the default dashboards.

Or do a tradeoff and make just a few new modules, and each can contain multiple panels that might be related to each other in some way. For example:

• DataObject management: GridFieldPanel, ModelAdminPanel
• Helpers: QuickLinksPanel, RecentEditsPanel, RecentFilesPanel
• CMS related: SectionEditorPanel
• Extras, not related to each other: GoogleAnalyticsPanel, RSSFeedPanel, WeatherPanel
  These are just quick examples of one way to arrange the dashboards. Other ideas? :)

[unclecheese]

+1 moving those to a separate module. My preference would be to think about this like GridFieldExtensions. Implementations of the core API to provide the 80% cases to devs with a good set of defaults.

You can probably get rid of half those panels. I can't remember the last time I consumed an RSS feed or wanted to know what the weather was doing outside my window. ;-)

Probably a good case for GA in the CMS.. but I'm surprised that isn't a solved problem by now in a proper module rather than a component of another one.

GridFieldPanel -- if you're doing this, you probably need to rethink the way you've designed your admin, and make more use of things like grouped-cms-menus and ModelAdmin.

All the others are pretty compelling. I think they're pretty project agnostic and serve a wide audience.

[Taitava]

Ok, I'm not so familiar with GridFieldExtensions, although I've seen it being installed many times by other modules I use. :)

Maybe GA could be written as a standalone module that does not require the dashboard module. It would have a separate admin page that would show the graph and maybe some database table that store information about what pages the admin section graphs should cover etc., just like the features that are currently available when configuring the current GA dashboard panel. And then it would of course have a file like this:

if (class_exists(Dashboard::class)) {
    class GoogleAnalyticsDashboard extends Dashboard
    {
        // ...
    }
}

So it would offer a dashboard panel if the dashboard module is installed.

So based on your comment, I would toss these:

• GridFieldPanel: I've never used it, and don't remember that I would even have tried it, so I don't even know what it looks like or how to use it.
• WeatherPanel
• RSSFeedPanel
• How about ModelAdminPanel? I've never tried that too, but is it something that could be used to admin what ever dataobjects there are currently configured? If so, it could be nice as a full page feature (offered by a separate module), maybe not so nice in a tiny dashboard panel?

Need to shut down my computer now as I do not permit myself to use computer or phone after 8 PM.

[mlewis-everley]

Hey all,

Just thought i would chime in on this conversation, I am wondering if maybe the WeatherPanel and RSSFeedPanel are better examples than actual panels available in an extra module? You could add the code to an area in the docs (something like how to create your own panels). That may be enough to help dev's create there own panels, but also not require you to setup another module that needs maintenance?

Also, I was wondering if someone (maybe @unclecheese) could have a look at PR #93 ? Looks like the update to SS4 missed some of the naming updates for DashboardChart.

[Taitava]

I am wondering if maybe the WeatherPanel and RSSFeedPanel are better examples than actual panels available in an extra module? You could add the code to an area in the docs (something like how to create your own panels).

Good idea! :)

Personally I don't have time right now to work on the things discussed in this conversation, so if someone else has time, it would be nice :).