-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow some read-only admin settings when allowAdminChanges = false #4371
Comments
For what it's worth, I'd suggest having read-only Settings section access be restricted to Admins only. Is there any sort of ETA for this? 3.5? 4.0? |
Would need to be 4.0 at the earliest, since plugins are also involved in showing their settings, and currently they don't have to worry about the possibility of a read-only mode. |
Hmm... all those settings are saved in the Project Config, right? What about a stopgap solution where you allow admins to basically view the contents of A very useful enhancement to something like that would be to present that raw ¯\_(ツ)_/¯ |
I don’t think the settings views should look significantly different when admin changes are disabled. Maybe we could introduce a new “Project Config” utility instead, similar to PHP Info. |
That would definitely suffice for me! :) |
Does it also make sense to have the Craft log files viewable via the backend? I could certainly stand to have that functionality on a production site I'm working on right now (GUI DB backup failed, said to check Craft logs for details, but I don't have access to the load-balanced servers...). |
Feature/project config split Resolves #4371
The fact that setting I realise this issue is closed, but would propose to re-open the FR in discussions. |
Fair enough, I’ll reopen. |
Perhaps disabling the Save button throughout the Admin section could be a simple & temporary solution? |
To help add context, we have engineering managers and project managers who would prefer to review the Section, Settings, and Entry Type structures of our CraftCMS for team discussion but we don't want to risk someone could edit these concepts on our staging and production environments. Having While I think the Project Config utility above is a great add, it doesn't quite meet the use case of easy viewability into the structure of our sites. |
I needed to see some email settings today. I don't have the site locally, and simply needed to confirm what production was using. I had to contact a dev - who had to spend time getting the site up to date on their machine to look. What should have taken 1 minute took 20 minutes. Would be far easier to look at these settings in a read only way. |
An alternative, and potentially more useful approach than making things "read-only", would be for admins to be able to manually toggle Apart from solving being able to see config, it would also allow admins to make "emergency" changes, where initiating a deployment might be undesirable, or impossible. |
Got bit by this two times in one day. Needed to look at some Solspace Freeform settings to confirm something for client, only to find that I cannot see those on live site. I don't have local copy of this site, so I have to ask one of our devs. This is a great way for devs to log more billable hours! |
That would sort of solve it, I guess. I still think the ideal solution would be to have the Settings section always available, in a read-only state and without having to expose the project config for changes at all. |
Fair enough, maybe my solution is a separate use case then. |
Craft 5.6.0 is out, which now shows read-only system and plugin settings when |
Description
I'd like to be able to see (as in, read-only) some admin settings, even if allowAdminChanges is false.
For example, I want to check my SMTP details are correct, but I don't want to allow them to be changed since I want them controlled through the yaml.
Currently I'm changing allowAdminChanges to true, having a quick peek to check everything's in order, then setting it to false again, which isn't ideal.
The text was updated successfully, but these errors were encountered: