Fix stack access with advanced permissions #7029
Conversation
| { | ||
| return $this->validate('approve_area_versions'); | ||
| } | ||
| public function canDeleteArea() |
There was a problem hiding this comment.
@mlocati @aembler Would it be possible to add a release number to new methods? That would make it easier for package developers to use these methods, without risking backward compatibility issues. Similarly to e.g. https://github.com/WordPress/wordpress-develop/blob/811eef33a31aab13d38a13522d4a58419566225b/src/wp-includes/user.php#L25
There was a problem hiding this comment.
I think it's a great idea. Sure, we have https://documentation.concrete5.org/api , but it's annoying to look at those pages every time we use a method.
There was a problem hiding this comment.
That is a handy feature - just wondering how would that work for things that haven't been released yet? A -dev tag that would need to be updated?
Also, 8.4.2 isn't included in the API docs :(
There was a problem hiding this comment.
Also, 8.4.2 isn't included in the API docs :(
I guess that the core team didn't implement what I suggested at concretecms/api#5 and they prefer updating the API docs manually...
|
@aembler If you think this is the right approach, I'll finish this. |
|
I tested this PR (and everything seems to work) with the following cases:
|
|
Just to show what this pull request fixes, let's assume we have these permissions for a stack:
Before this pull request, the user can't edit the stack:
With this pull request, everything works fine:
|
|
I'm closing this because it has a wrong approach. |
concrete5 can handle permissions at the stack level.
BTW concrete5 doesn't handle these permissions correctly.
Let's fix this.
Fix #7006
PS: this PR is still a work in progress. I'll finish this ASAP.