-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add "occ config:*" to manage config values #16368
Conversation
* @throws \UnexpectedValueException when the array is invalid | ||
*/ | ||
protected function getArrayFromFile($importFile) { | ||
$helo = file_get_contents($importFile); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to be able to use occ config:import < file.json
instead of reading from the filesystem of the owncloud instance. But I failed to understand if that works and how.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is $helo
?
6bf1c55
to
34913f6
Compare
9edf255
to
0d0e102
Compare
Rebased, ready to review @MorrisJobke @DeepDiver1975 @LukasReschke |
I'd suggest to reverse the default: by default do not output the "private" attributes (like the public mode) and only output them if the admin explicitly asks for them. This would align with the way the LDAP config exporter works, see https://github.com/owncloud/core/blob/master/apps/user_ldap/command/showconfig.php#L56 Also I guess this here could obsolete the LDAP specific config commands ? @blizzz |
|
In the current workflow I'd need to go back and re-edit the left part of the command to add ":get" or ":set" after I saw it. |
|
And now again I types |
While this would be nice, we need special treatment for empty strings. so I figured instead of starting two code paths, we can just always use --value
For the
About building the command, the problem is this merges all stuff into one command, ending up in a huge unmaintainable block of code, so sorry if the :set is annoying to you, but I think it's better to have it explicit.
We don't do such stuff and we really shouldn't. Maybe you want to set the values before enabling the app, etc. there are a lot of usecases for having it arbitrary. |
|
@PVince81 you can not import a single app atm, only the full thing, although that sounds like something we could/should fix |
My comments were all from my own usability testing. Would be good to know what other think to. |
|
||
$this | ||
->setName('config:app:get') | ||
->setDescription('Set an app config value') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
=> "Get"
This wouldn't be an issue. The command only be the entry point and call functions in separate classes for separate functionality. But I understand that you might not want to make bigger changes at this point. |
Apart from #16368 (comment) I'm fine for merging this. |
I love it 👍 |
But needs good documentation. @nickvergessen @carlaschroder |
The LDAP config commands are slightly more sophisticated. In first line because there the configkey contains the config ID for the configuration plus the actual config name. So the commands split it up and let the user just specify the which config they want to see, change or delete. Another thing: in LDAP we accept multiline values in few cases and output them differently in occ (;-separated) and accept them ;-seperated which is dealt with in the app's set method. This could be resolved in a generic way, though. Also the --public (yes, better make it --private, #16368 (comment)) switch is not effective for apps. So, it could obsolete them, but would cost convenience. Would not do it at this stage. |
I feel not most comfortable with circumventing apps' set methods in general (or disable/enable as @PVince81 pointed out already), while I acknowledge the convenience and helpfulness of this command. Yes, you could change stuff in the DB directly, nevertheless this really lowers the hurdle to do so. For the greater benefit: 👍 |
@nickvergessen can you plase rebase this before you leave? THX |
Rebased, fixed the docs typo, inverted the "public" to "private" and made it possible to import |
0d0e102
to
85f0125
Compare
A new inspection was created. |
👍 |
Add "occ config:*" to manage config values
Holy cow that's a lot of work! I can hear occ breathing. |
@carlaschroder I will do that for you |
@nickvergessen I meant that's a lot of work on occ. It looks great. |
When we are able to set/import configs via a console command, this can be added to scripts. So in the end, people don't need to use a second.config.php to publish configs when setting up the same owncloud on multiple servers. In the end this makes it possible, to start getting rid of the writable config.php file, which causes problems from time to time since ever. Ideally only a minimum set of configuration values is in the config.php. Especially any values that are/can be changed via the web UI should not be written to the file.
TODO
Can either be a file on the system we are importing, or
./occ config:import < admin-mashine-file