search

JoinColony / colonyCDapp

An iteration of the Colony Dapp sporting both a fully decentralized operating mode, as well as a mode enhanced by a metadata caching layer
5 stars 14 forks source link

[Dashboard] Recent activity table empty state #3061

Open mmioana opened 2 months ago

mmioana commented 2 months ago

Specification

Story

Description

The recent activity table will never be empty. Thus, it should show New colony creation as the first action. This is not an existing action, but there is always a first action for setting the permission that is performed by the colonyNetwork contract, so, this could be interpreted as the colony creation action.

Image

Implementation

This issue is complete when...

Figma link Figma link empty state

Feature branch: feat/enhanced-dashboard

iamsamgibbs commented 1 month ago

I did a little investigation into this and agreed with Arren to postpone this until the block-ingestor multicall refactor is complete as it may unlock new ways to tackle this issue.

Summary of my investigation:

Currently the transaction hash from the ColonyAdded event is used as the ID for the Manage permissions colony action, this is why clicking the transaction in the user hub opens the manage permission action.

A possible solution would be to replace this with a new New colony created action which could show the manage permissions data as well as any other colony creation data, which user created the colony, whether a new token was created, etc.

Alternatively, we could create a second action which could appear in the activity feed, but the user hub transaction wouldn't be able to link to it. It would also need to use the same transaction hash as the Manage permissions action so would need to be altered 0x00...00-colonyAdded or something which would then require changes to the valid hash checks we do on the front end to make this an allowed hash and query the relevant colony action. This feels a bit messy and I think having it be able to be opened via the userhub transactions list too makes more sense.

Part of the block-ingestor multicall refactor will move the transaction hash to it's own field on the ColonyAction model rather than using it as the ID, this will allow multiple actions to use the same transaction hash. This change might open up a better way to tackle this issue.