frontend: KubeObject: Set missing attributes in attrs

[skoeva]

Previously, the apiVersion was not being provided in the jsonData object in the resource table, and apiVersion is necessary for authenticating and displaying valid row actions. This change ensures that resource, group, and version are always provided to ensure that valid row actions for the given KubeObject are visible.

Fixes: #2633

Testing

• Apply the YAML for the deployment, SA, and RBAC given in Headlamp does not show restart/edit/scale buttons on resources with sufficient permissions #2633
• Generate a new kubeconfig from this and apply it in the Headlamp app
• Open the new context and navigate to the "Deployments" page
• Ensure that the row actions in the table and actions on the deployment page match the permissions

[joaquimrocha]

@skoeva Do we always need to set the group + version + resource when checking for permissions? I think the original logic was "check if we are checking permissions with e.g. the resource, if so, use this API version's one instead", in these changes it does: "even if we were not testing permissions using the resource, will just set it".

Are we sure this is the right approach? We ought to test variants of these calls.

[skoeva]

@skoeva Do we always need to set the group + version + resource when checking for permissions? I think the original logic was "check if we are checking permissions with e.g. the resource, if so, use this API version's one instead", in these changes it does: "even if we were not testing permissions using the resource, will just set it".

Are we sure this is the right approach? We ought to test variants of these calls.

@joaquimrocha I think it would be fitting to have a complete resource to evaluate permissions for, no? The issue before was that the object was incomplete and therefore we were unable to check for its permissions. In what case would we prefer an incomplete object?

[joaquimrocha]

@joaquimrocha I think it would be fitting to have a complete resource to evaluate permissions for, no? The issue before was that the object was incomplete and therefore we were unable to check for its permissions. In what case would we prefer an incomplete object?

I just saying the nature of how we were checking things was more of if we use a resource name -> now try the resource name from this other version, and right now we're saying if a resource name is not set -> try the resource name from this version. So I believe this is incorrect to what is the point of that logic. It may be that the logic is wrong in some cases, but if we are missing fields, we should verify why that is instead of adding them from a new version, or by not replacing them with the current testing version, which is what these changes also do.

[skoeva]

I just saying the nature of how we were checking things was more of if we use a resource name -> now try the resource name from this other version, and right now we're saying if a resource name is not set -> try the resource name from this version. So I believe this is incorrect to what is the point of that logic. It may be that the logic is wrong in some cases, but if we are missing fields, we should verify why that is instead of adding them from a new version, or by not replacing them with the current testing version, which is what these changes also do.

@joaquimrocha The code comments suggest that the changes made in this PR are more in line with the intended logic here:

Not sure if the original logic makes much sense in this case

[joaquimrocha]

I think you may have a point, now that look at this with fresher eyes. I think if that's the case, then the previous logic is indeed wrong, but seems like we're possibly mixing things (mixing the group from an API version with version from another), so maybe what we need to do is to use the full apiName + apiVersion here instead.
In either case, I'd kindly ask you to test this function and understand what happens when e.g. you add newer+fictitious apiVersion to a resource, and test this function (and the instances' getAuthorization), to simulate falling back to a working version.