Remove the rule(s) validation with api names while importing a role#4840
Conversation
… be in sync with the create role permission behavior
|
@blueorangutan package |
|
@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. [S] |
|
Packaging result: ✔️ centos7 ✔️ centos8 ✔️ debian. SL-JID 169 |
|
@blueorangutan test |
|
@sureshanaparti a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests [S] |
Aren't we fixing the wrong thing here? I'd say add the validation on create role. |
@DaanHoogland Agree with api validation part. The intent here, is to have the same behavior for rules added through import role and create role permission (where api names are not validated). Otherwise, create role permission can be extended to include the validation for consistency. Also, note that some cmds are added to the API lookup map only when the respective service/plugin is enabled (eg. cloudian connector, kubernetes service, solid fire APIs). |
|
[S] Trillian test result (tid-168)
|
|
@blueorangutan test |
|
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
shwstppr
left a comment
There was a problem hiding this comment.
LGTM based on changes. Haven't tested
|
@blueorangutan test |
|
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
Ok, @sureshanaparti My preference would be add the checking to the create method, but I won't block for that reason. |
|
Trillian test result (tid-198)
|
|
Trillian test result (tid-233)
|
@DaanHoogland do you approve the changes then? |
|
ping @DaanHoogland are you LGTM with the PR? |
|
Said, I don't block this in favour of timeliness but: I think the validation should be more thorough rather than be removed (I.E. make sure a glob resolves to an API before allowing it) As said, I won't block. I don't have a real world example of a user/use-case to argue we should block this, so merge if you disagree. |
|
@DaanHoogland the justification is that when adding any rule, the rule string is not validated (i.e. check if the API exists in the system/plugins) which is because some APIs get activated via a global setting or on external jar/plugin. Therefore we must relax with the similar logic for the import role feature (that imports a csv with list of role rule strings, i.e. don't fail if an API doesn't exist in the system). |
|
Merging as Daan hasn't blocked, on tests and 2 lgtms. |
Description
This PR removes the rule(s) validation with api names while importing a role. This will be in sync with the current create role permission behavior.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Manually tests: