feat: Add Community Modules Table in Modules view #3917
Conversation
| setSelectedEntry={setSelectedEntry} | ||
| /> | ||
| )} | ||
| {kymaResource && ( |
There was a problem hiding this comment.
Community modules should be independent from kymaResource
| @@ -86,6 +88,14 @@ export function KymaModuleContextProvider({ | |||
| skip: !kymaResource?.metadata?.name, | |||
| }); | |||
|
|
|||
| const { | |||
| installed: installedCommunityModules, | |||
There was a problem hiding this comment.
Those are not installedCommunityModules, but installedCommunityModules and installed unmanaged modules. To get installedCommunityModules you should pass communityModuleTemplates instead of moduleTemplates .
There was a problem hiding this comment.
There for we have template operator is displayed on the list even if it hac manageg-by label
| loading: communityModulesLoading, | ||
| } = useGetInstalledModules( | ||
| moduleTemplates, | ||
| !kymaResource?.metadata?.name || !!!moduleTemplates, |
There was a problem hiding this comment.
Also community modules are independent of !kymaResource?.metadata?.name. If there is no kymaResource then all installed modules are community modules.
KymaModuleProvider was written for managed/unmanaged modules only, thats why we skip in !kymaResource?.metadata?.name. If we adopt this provider to community modules as well we need to adjust some some skips due to !kymaResource?.metadata?.name
| ) => { | ||
| if (!moduleTemplates?.items) return { managed: [], unmanaged: [] }; | ||
|
|
||
| const managed: ModuleTemplateListType = { items: [] }; |
There was a problem hiding this comment.
I would rename it to community templates and kyma templates... cause kyma modules after installation are either managed and unmanaged, so it can get confusing.
Description
Changes proposed in this pull request:
Related issue(s)
Closes #3815
Definition of done
backlog#4567