[Community Management] Implement nb of members graph (backend)

[jrainville]

Description

This task is to implement one of the graphs in the Owner's Commnity Overview view.

You have to do ONE of the three graphs. Choose the simplest one.

There is:

• Nb of Members over time
  

• Messages per month
  

• Control node uptime
  

Design https://www.figma.com/file/17fc13UBFvInrLgNUKJJg5/Kuba%E2%8E%9CDesktop?type=design&node-id=29648-618516&t=iOq5Q8V0ftXMj4qM-0

Again, choose only one of the three, the simplest one. The graph component should already exist, ask the Wallet team where it is, how it works and what type of data it supports. If we only support line graphs for example, then we'd better do the number of members.

We currently do not store any historical data, so you'll need to implement that in status-go. The Owner, TokenMaster admins and Admins all have access to this information.
The best way to do it would be for the Control to aggregate the data and share it with the admins.
Of course, no personal data needs to be saved, only numbers and dates.

Also, ignore the bottom of the graph, it is not part of the scope. (the part where you can select the time frame to choose)

If doing the top part (time selector for 1H, 1D, 7D, etc) is also harder and/or not supported by the current component, do not do it.

The goal of this task is to populate the Overview screen so it's not as empty, while keeping it as simple as possible

Acceptance Criteria

• The owner's Overview page in the Management panel now has one of the graphs from the list above.
• The graph contains local info about the community and evolves over time

[jrainville]

@John-44 in the description I wrote "Only the owner node needs to aggregate that data", but I want to confirm if that's correct.

Should Admins also show the graph? If so, they'll have to aggregate the data too (simpler than sharing the data over the network IMO)

[John-44]

@jrainville this graph should be visible to all Admins and TokenMasters of the community (they all have access to the community's admin area), in addition to the Owner.

I suppose the way to do this would be for the Control Node to aggregate the data, but this data would also then need to be sent to Admins and TokenMasters so that they can access the data when the Control Node is offline.

It's fine in the data only extends to the last date the Control Node was online e.g. if the Control Node has been offline for 7 days, the Admins and TokenMasters should only see the data up until the point he Control Node went off line (in this scenario the data the Admins and TokenMasters would see would end 7 days in the past)

[alexjba]

@jrainville Is it planned for messenger team to implement it end-to-end?
If so, we could split it. The UI team could implement the UI with mocked data and messenger team the backend. WDYT?

[jrainville]

As discussed with @alexandraB99 , as was planning for our team to do it end to end, but since it seems you're already doing part of the Overview page and are willing to help, then yes, I'll agree to the help.

If you can first start by finding which types of graphs are available in the component for now, it will help decide which of the three graphs we'll do.

Then, you can create a new issue to do a mocked UI.

Thanks.

[alexjba]

@jrainville We have out of the box support for Nb of Members over time and Messages per month (bar and line chart). Implementing Control node uptime seems to require a custom solution.

Here's the supported chart types: https://www.chartjs.org/docs/2.9.4/charts/

[jrainville]

We decided to go with the Messages per month graph, since we already have all the data available. We'll just need a query to get it

[alexjba]

UI task: #11440