avo icon indicating copy to clipboard operation
avo copied to clipboard

Resource cards

Open adrianthedev opened this issue 2 years ago • 1 comments

Add the ability to add cards to the resource, similarly to how we do it on a dashboard.

adrianthedev avatar Jul 19 '22 20:07 adrianthedev

This issue has been marked as stale because there was no activity for the past 15 days.

github-actions[bot] avatar Aug 11 '22 03:08 github-actions[bot]

This issue has been marked as stale because there was no activity for the past 15 days.

github-actions[bot] avatar Aug 27 '22 03:08 github-actions[bot]

Closing this because there was no activity for the past 15 days. Feel free to reopen if new information pops up ✌️

github-actions[bot] avatar Sep 11 '22 03:09 github-actions[bot]

@adrianthedev I made this PR as a POC feature: dashboards on resources.

It does not respect the request since it's allowing to add dashboards to the resource instead cards. When I started to implement it, I started with cards as the original request, however I realized that we already have the whole system done with the dashboards and we can keep it stupid simple by reusing that system.

This PR allow to declare dashboards on any resources by using the following syntax:

  def dashboards
    dashboard Avo::Dashboards::Dashy
  end

All the dashboards declared on the resource will be rendered on top of the main panel on each view. Each dashboard is initialized with the resource attribute configured, that means the developers can to access the resource on the cards method or even on the self.name or self.description. The resource is already hydrated with the view, record, params etc... making it enough customizable by default for each case.

It will force the developer to build a new dashboard if the intention is to show 1 or 2 cards on a resource, but in my opinion that's the right path. Keeping the cards / dashboards logic separated from the resource but at the same time allowing to render a dashboard on the resource.

I don't want to invest more time in this approach without your approval since this is not the original request. Anyway, again, I think this path is the right to follow, if we have the whole system build for dashboards why would we separate the cards into two different ways to maintain it?

We can make it more complex by allowing the developer to chose where to render it and even more customization. Let me know what do you think about this approach, I tried to apply the KISS principle and make usage of an already build system. One of the advantages of this approach is that any improvement to dashboards will apply automatically to the dashboards on the resources without extra work for managing cards on 2 distinct places, we don't even need to care about columns and other customizations because they're already there.

Paul-Bob avatar Sep 04 '23 08:09 Paul-Bob

Re-implement as the original request

Paul-Bob avatar Sep 06 '23 12:09 Paul-Bob

This issue has been marked as stale because there was no activity for the past 15 days.

github-actions[bot] avatar Sep 22 '23 01:09 github-actions[bot]

This issue has been marked as stale because there was no activity for the past 15 days.

github-actions[bot] avatar Oct 08 '23 01:10 github-actions[bot]

Closing this because there was no activity for the past 15 days. Feel free to reopen if new information pops up ✌️

github-actions[bot] avatar Oct 24 '23 01:10 github-actions[bot]