adrian Posted November 22, 2017 Posted November 22, 2017 @horst - this is the issue that led to that change: https://github.com/processwire/processwire-issues/issues/371 I actually don't like the result - I think it's a reasonable scenario to add additional permissions to the superuser role and do an actual check for these. I use the same technique in Tracy, which I guess is also broken now. 1
Robin S Posted November 22, 2017 Posted November 22, 2017 1 hour ago, adrian said: I actually don't like the result - I think it's a reasonable scenario to add additional permissions to the superuser role and do an actual check for these. I think it does make sense to say that the superuser role is a role without any restrictions and that therefore permissions are not something that can be granted or not granted to a superuser. The comment (from Ryan in the GitHub issue) that I don't agree with is: Quote Regarding field and template editors, those are Process modules that are really intended only for superuser. Adjustments there can be destructive to the entire site, which is superuser-only territory. Why should there be the presumption that there is never any scenario where a non-superuser could be trusted to add or edit a field or template? Depending on the user and the project there could be quite valid cases for this. I think it ought to be possible to elevate a role right up to the point where they are virtually a superuser. One way this could perhaps be implemented is by adding a permission for each core Process module.
adrian Posted November 22, 2017 Posted November 22, 2017 @Robin S - I don't want to hijack @horst's thread here much more, but I think we are basically in agreement. My desire for custom permissions for superusers wouldn't be needed if we could assign some currently superuser only permissions to other roles. I think basically there is a level of control here that is currently missing and there are different ways of tackling it - the problem is that the one option we had (adding permissions to the superuser role) is now gone. I guess the workaround is to change these custom "permissions" to "roles". So for ALIF, horst could require a user has the "alif-user-account-switcher" role. 3
horst Posted November 22, 2017 Author Posted November 22, 2017 Hi, and thanks for notifying about the change. For alif it was thought as an additional security step. But using a special role for this is appropriate too. 1
gornycreative Posted February 23, 2019 Posted February 23, 2019 I get a namespace error when trying to warm up the OPCache - was the PW3 namespace issue not resolved?
Guy Verville Posted October 28, 2019 Posted October 28, 2019 Hi @horst I don't know if you are aware, but the module will generate a warning with PHP7.3.
horst Posted October 30, 2019 Author Posted October 30, 2019 On 10/28/2019 at 6:01 PM, Guy Verville said: I don't know if you are aware, but the module will generate a warning with PHP7.3. Thanks for reporting! I'm using PHP 7.2 and currently don't have a PHP 7.3 server running. I will update my dev setup when I find time and fix this.
MoritzLost Posted July 8, 2021 Posted July 8, 2021 @horst I think I've found a small bug in the module, could you take a look if you've got time? Thanks! https://github.com/horst-n/AdminLinksInFrontend/issues/2 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now