Gating forms micro adjustments

[mzparacha]

Some micro adjustments were not done in #5045, this ticket is a followup to do that.

• 1- In edit group mode, the "required requirements" value is undefined -- API also doesn't use this value
• 2- Some chain ids in the chain selector requirement have null ids -- Update them to be defined
• 3- Topics are not editable -- Update them to be editable
• 4- For Cosmos chain requirement the chain dropdown should only include cosmos base chains and vice versa for eth.
• 5- Remove near + solana from the gating form
• 6- Fix gating form style issue on Frack

[mzparacha]

for 1

1- In edit group mode, the "required requirements" value is undefined -- API also doesn't use this value

I mentioned this in the gating form pr review

but somehow this question still got missed there.

@zakhap can you please confirm what would be the expected behaviour here?

[mzparacha]

2 is nearly done, i just need to find the ethChainid for polkadot. Confirming from team

2- Some chain ids in the chain selector requirement have null ids -- Update them to be defined

We don't need polkadot for gating as per @zakhap -- Thanks.

[mzparacha]

I am currently blocked on 1

1- In edit group mode, the "required requirements" value is undefined -- API also doesn't use this value

and working on 6 (6 is not blocked) 6 is also done

6- Fix gating form style issue on Frack

[zakhap]

for 1

CC: @jnaviask @rbennettcw

For this section, the "required requirements" has two options (as seen in the designs):

1. ALL requirements must be satisfied for the community member to be in the Group
2. X of N many requirements must be satisfied for the community member to be in the Group (this functions "SOME" logic)

Is there anything else here that needs to be defined for the backend + front-end to align here?

[rbennettcw]

@mzparacha required_requirements is part of the metadata JSON object. It doesn't exist by default and must be explicitly set.

With the current code on master, you can implement required_requirements in the UI without blockage.

Additionally, here's a PR which applies the required_requirements value to the actual gating logic: #5460 (not a blocker for the UI though)

[mzparacha]

Thanks for the responses.

With the current code on master, you can implement required_requirements in the UI without blockage.

This is already done, but atm the API doesn't wasn't returning it so I just wanted to know if it was something similar to what we did with the requirement condition (hardcoded -> 'more than' in frontend etc).

Additionally, here's a PR which applies the required_requirements value to the actual gating logic: #5460 (not a blocker for the UI though)

didn't knew about this. Thanks.

So for me I will take #5460 diff locally to make the matching frontend changes for required_requirements.

cc: @rbennettcw @zakhap

[rbennettcw]

There are no frontend changes required for #5460– it's entirely just a backend update.

Regarding required_requirements, what isn't being returned? The required_requirements value is returned when a group is created and when groups are queried:

[rbennettcw]

Yeah by default, the required_requirements value is not returned unless it's set when the group is created. A default value of 0 can be used to represent "all requirements must be set"

[mzparacha]

hm, i didnt knew that, Thanks

[CowMuon]

@mzparacha #1 on list here can be marked done?

[mzparacha]

yes @CowMuon. I marked it done and pr is ready for review.