Codecov Report

Attention: Patch coverage is 62.50000% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 67.60%. Comparing base (a2df434) to head (c033049).
Report is 4 commits behind head on master.

@@           Coverage Diff           @@
##           master    #7130   +/-   ##
=======================================
  Coverage   67.59%   67.60%           
=======================================
  Files         561      561           
  Lines       68760    68761    +1     
  Branches     5840     5841    +1     
=======================================
+ Hits        46477    46483    +6     
+ Misses      22283    22278    -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I do not understand the explanation of the issue. Even with the array [SETTINGS, SETACCESSES] it should work as SETACCESSES is a child of SETTINGS so if you have it you also have the parent?

as userCapabilities is an array of capabilities split on the "_" (line 37), the condition userCapabilities.includes(SETTINGS_SET_ACCESSES) was never true.

as userCapabilities is an array of capabilities split on the "_" (line 37), the condition userCapabilities.includes(SETTINGS_SET_ACCESSES) was never true.

Ah, yes ok. Still feels strange we need to add a new constant to resolve the issue. Do we not have a function somewhere that already checks capabilities instead of calling directly userCapabilities.includes?

Use isUserHasCapability instead?

the use of isUserHasCapability requires a more global rework on the capa check. i created a technical issue #7184 because while investigating with @labo-flg we found 2 other places where the check was badly done (in notes and opinions). So for now the bug is fixed, the check is done on a string hardcoded, I've put a TODO for the next step.

Use isUserHasCapability instead?

the use of isUserHasCapability requires a more global rework on the capa check. i created a technical issue #7184 because while investigating with @labo-flg we found 2 other places where the check was badly done (in notes and opinions). So for now the bug is fixed, the check is done on a string hardcoded, I've put a TODO for the next step.

Even if we are not taking care of the global rework in this PR we can still at least use the function correctly for the 2 lines triggering the bug instead of adding hard coded strings no?