Feature/253 introduce community add ons

[Tguntenaar]

Resolves #253

The following structs have been added:

• [x] Add structs
• [x] Implement migration
• [x] Test migration manually
• [x] Add basic CRUD operations
• [x] Permissions, only community admins and moderators can create, update, delete add-ons to communities
• [x] Only moderators can create, update, delete add-ons to available add-ons
• [x] Write tests for operations
• [x] Edit test for migration

Acceptence Criteria (not all AC apply to the smart contract side)

• [x] By default, any newly created communities will not display any of the available add-ons. So only the main feed and teams tab will be enabled.
• [x] Admins have a consistent framework for adding, configuring, and deleting add-ons all through the community settings page.
• [x] Adding: Admins can add add-ons through a "Add add-on" button and select from a dropdown menu of available add-ons. An admin can add multiple instances of the same add-on. By default, the naming of each tab will be the add-on name.
• [x] Configuring: Once a new add-on is added, admins can click edit to customize the add-on’s tab names and specific fields, and click save to apply their changes.
• [x] Previewing: Admins should have a way to quickly preview their tab in the settings page. Perhaps we add a toggle here similar to GitHub's "Write/Preview" interface to avoid crowding the interface for more complex plugin configurations?
• [x] Deletion: Admins can delete add-ons by accessing the edit option and selecting delete, removing the respective tab. Migration: Existing add-on configurations are preserved, and communities can manually migrate at their convenience without breaking functionality.

I tested the migration with the following transactions: From V7 to V8 V8 to 'done'

[Tguntenaar]

@ailisp , I discussed with elliot that the function to delete available addons were out of scope. Removing an addon from a community tab is possible. Let me know what you think!

[Tguntenaar]

Hi @frol, since @ailisp is OOO. Could you review this PR? It's vital to continue the Community Plugins MVP milestone.

[petersalomonsen]

would it be better to use a LookupMap for the community plugin configuration data? That way it would be possible to look up the config for the plugin in view, and also not make the community config object potentially very large.

[elliotBraem]

@petersalomonsen

Can you demonstrate? Is this is to replace parameters JSON string?

[petersalomonsen]

yeah I was thinking that pub addon_list: Vec<CommunityAddOnConfig> could just be a list of strings, an those strings represent the keys in a LookupMap<String,CommunityAddonConfig> so that each config has a separate entry in the NEAR key/value storage. I believe this will scale better with multiple addons, or addons with larger config objects.

[Tguntenaar]

I updated the contract to use a LookupMap instead. Thanks @petersalomonsen for the review. New contract deployed here: https://explorer.testnet.near.org/transactions/DEu1TwCZM2fBbpqWZxZBL62ik6et7bCC9DeRbaMD4sdh

[Tguntenaar]

@ailisp could you review these contract changes?

[elliotBraem]

@frol, @petersalomonsen, Based on the comments + discussion above, here's a diagram of the contract changes that @Tguntenaar and I have decided on implementing, and the way it is reflected on the UI:

Changes

1. We've renamed "name" to "display_name".
2. Community Struct now holds "addons" and "configs". @frol
   • Addons is a Vector and largely dictates the tabs themselves (the order, enable/disable, display_name... these can be configured from the Community page since it dictates its interaction with it. It holds a reference to a CommunityConfig via config_id.
   • Configs is a LookupMap<(CommunityHandle, CommunityConfigId), CommunityConfig>, which is accessed when a tab is selected via community.configs[config_id] @petersalomonsen
3. We pass the addon_id and the config to the "Addon" that renders, which can either be of TemplateType "viewer" or "configurator". The addon only has accessed to the parameters and any information that the Addon itself provides. @ori-near , see diagram for how the order, tab name, icon, etc. of an addon can be modified via Community, but the parameters for something like the Kanban board, would be configured within the tab itself through the Addon's configurator view.

The goal was to keep it as modular as possible and with a separation of duties; This way, I think we could also implement permissions control for individual addon configs? And maybe more, I think this pattern could be generalized and used for more structures similar to communities. @carina-akaia @ailisp @jaswinder6991

Here you can test a dummy example :

Check out the Screams and Whispers of Vlad's Haunted Hack House!

[petersalomonsen]

I think this looks great!

Just wondering when referencing community.configs[addon_id]. Is then addon_id unique for the community? We don't want other communities to get the same config if using the same addon as another community. Or have I missed something?

[elliotBraem]

Lol sorry, there are a lot of moving parts and it's hard to keep the naming straight! You are correct, in the diagram, this should not be addon_id, but rather "config_id", where config_id is unique to the community via the Tuple: LookupMap<(CommunityHandle, CommunityAddOnConfigId), CommunityAddOnConfig> as suggested by @frol

I have updated the original post

[Tguntenaar]

Thank you everyone for the comments and review points. I deployed the latest version on thomaselliot.testnet

[Tguntenaar]

@frol one more try! :)