-
Notifications
You must be signed in to change notification settings - Fork 358
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 the ability to edit options settings for providers #1652
Add the ability to edit options settings for providers #1652
Conversation
1afcc76
to
1ab3b9b
Compare
753aad9
to
9825a92
Compare
I am now having a problem with creating a new provider: the ems type that is chosen is the basic |
@enoodle The provider edit screen is always an angular screen now... So we can't easily re-render any HTML that gets rendered when opening the form. So I think you'll need to move the logic to angular, query a json endpoint to get those options after the provider type is selected, and do all the option-dependent rendering in angular instead of server-side. (A workaround would be to create a component that can recieve HTML from the server and render it, and route it through there, but.. I think it's easier to do it properly on the js side :).) |
4f10baa
to
b3e8136
Compare
@himdel This is now rendering the HTML for the options forms in angular but I am sure that there is a much better way to do it. Can you take a look? |
08e5299
to
69336b8
Compare
6e4febc
to
6385987
Compare
$scope.emsCommonModel.provider_options_description = response; | ||
if ($scope.emsCommonModel.provider_options_description.hasOwnProperty('advanced_settings')) { | ||
var advanced_settings = $scope.emsCommonModel.provider_options_description.advanced_settings.settings | ||
for (section in advanced_settings) { |
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.
Careful about creating global variables here ;) var section
settings_group[section_name] = options_section; | ||
settings_group[section_name].section_name = section_name; | ||
var section = settings_group[section_name].settings; | ||
for (option in section){ |
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.
Another global ;)
} | ||
}; | ||
|
||
$scope.toSnakeCase = function(st) { |
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.
You can probably use _.snakeCase() instead..
@@ -11,6 +11,8 @@ ManageIQ.angular.app.controller('emsCommonFormController', ['$http', '$scope', ' | |||
default_hostname: '', | |||
amqp_hostname: '', | |||
hawkular_hostname: '', | |||
provider_options_values: {}, |
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.
Not quite sure what these are, but looks like they are generic options, not related to the specific instance you're editing, is that so?
If so, you probably want $scope.somethingElse
:) - the idea is that the model
object should be just the data of that particular instance (not necessarily quite 1:1 with the database, but as close as possible, so that you can just post the whole thing to the server, and not have to delete fields when saving.).
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.
I kind of need the same object to hold both the descriptions of the options and the values. This way it is much easier to iterate over the descriptions in the haml file and find the object that should hold the value.
Another option can be to hold it outside of emsCommonModel and only copy the value of the options back to it when the user clicks "save". WDYT?
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.
Ah, got it :).
Well, it will probably work just fine as it is, I'm a bit reluctant to try to force you to make this super-clean when that whole screen is super-dirty already :).
That said, yes I would like that other approach better. If the structure is relatively flat, you could also $watch
it for changes and update the model value on any change.
%p | ||
{{ settings_section.help_text }} | ||
%div{"ng-repeat" => "option in settings_section.settings"} | ||
%div{"ng-show" => "true"} |
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.
ng-show true .. Probably can get rid of it?
%p | ||
{{ emsCommonModel.provider_options_description.proxy_settings.help_text }} | ||
%div{"ng-repeat" => "option in emsCommonModel.proxy_settings.settings"} | ||
%div{"ng-show" => "true"} |
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.
same here..
"placeholder" => "{{ option.global_default }}", | ||
"title" => "{{ option.help_text }}", | ||
"prefix" => "provider_options"} | ||
%span.help-block{"ng-attr-ng-show" => "{{ \"angularForm.provider_options_\" + settings_section.section_name + \"_\" + option.name + \".$error.detectedSpaces\" }}"} |
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.
You should never need to do this... (ng-attr-
with another angular directive)
"ng-show" => 'angularForm["provider_options_" + settings_section.section_name + "_" + option.name].$error.detectedSpaces'
is probably what you want..
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.
(We should really start putting these as sub-objects, and drop the idea of using prefixed fields, but .. I guess that's too big a change for the PR.)
{{ settings_section.help_text }} | ||
%div{"ng-repeat" => "option in settings_section.settings"} | ||
%div{"ng-show" => "true"} | ||
.form-group{"ng-attr-ng-class" => "{{ \"{'has_error': angularForm.provider_options_\" + settings_section.section_name + \"_\" + option.name + \".$invalid}\" }}"} |
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.
"ng-class" => '{ "has_error": angularForm["provider_options_" + settings_section.section_name + "_" + option.name].$invalid }'
@enoodle Looks like you're on the right track.. Maybe since this is a new functionality, you may want to wrap this in a component, but not sure if this is separate enough from the rest to make that practical.. We actually already have a component which takes a definition object with a list of fields, and renders those fields, but not sure if this is close enough so that you could actually reuse it, or if it's more like a place to take inspiration from.. https://github.com/ManageIQ/manageiq-ui-classic/blob/master/app/assets/javascripts/components/ansible-credential-options.js But I have no better idea than what you're already doing, so the component thing is mostly about future tech debt and minimizing the dependency on shared angularForm, etc., it probably wouldn't make anything easier for you.. |
@himdel as you can see I am using two pretty similar "haml" files here. one of them, the _provider_proxy_settings.html.haml, is kind of included in the other one. |
11db7d3
to
220fa90
Compare
2ddafd5
to
3b32e17
Compare
@AparnaKarve @himdel I fixed the CodeClimate error, PTAL |
%ul.nav.nav-tabs | ||
= miq_tab_header('proxy_settings', nil, {'ng-click' => "changeAuthTab('proxy_settings')", | ||
'ng-if' => "emsOptionsModel.provider_options.hasOwnProperty('proxy_settings')"}) do | ||
%i{"error-on-tab" => "hawkular", :style => "color:#cc0000"} |
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.
just wondering, is this file suppose to be generic? if thats the case, why do you have hawkular
here?
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.
Thanks, It was a mistake, I changed it to "proxy_settings" and "advanced_settings" below.
2ea25db
to
1ea094b
Compare
ping @AparnaKarve @himdel @ohadlevy can you take another look? |
@enoodle Thank you for your patience. I did see something with the way the tabs are positioned when Notice the gap between the I think we can treat that as a separate (and unrelated) issue and get this PR merged. @dclarizio IMO, this is GTG. Thanks. |
@enoodle There's a lot of new code here, could you add some tests, at least basic ones? @AparnaKarve can you suggest some tests that can be added? |
@enoodle On the backend side, can you write a spec that will create a On the JS side, I see that you have included a few tests. The I guess some of the basic use cases for this PR would be how the |
1ea094b
to
1f6202e
Compare
This pull request is not mergeable. Please rebase and repush. |
1f6202e
to
2cbee6c
Compare
Reading the details about the provider's options from the api endpiont OPTIONS /api/providers and creating tabs for them.
This section will only be seen if the settings exists for that provider
2cbee6c
to
c94ad9e
Compare
I am not sure where this should be, can you direct me to the spec file?
I added a few tests in similar to other examples in the spec file, PTAL
This PR is for the Options only, I don't want to create Prometheus/Hawkular data that I am not sure about here. I added a test in |
You could add specs for Check out some similar examples in spec/controllers/ems_infra_controller_spec.rb where there are specs written for Create/Update/Validate for |
c94ad9e
to
0340e80
Compare
Checked commits enoodle/manageiq-ui-classic@8c67c49~...0340e80 with ruby 2.3.3, rubocop 0.47.1, and haml-lint 0.20.0 |
@AparnaKarve I added a create test with provider options to spec/controllers/ems_container_controller_spec.rb |
@enoodle Thanks for the specs. @dclarizio This can be merged now. Thanks. |
Per provider options were added in [1][2] to all providers. It is now possible to save values in
ems.options
to use as options.This PR adds the ability to set options from the UI. To tell which options are supported for each provider type an API request is done [3] which expects the provider to implement the
provider_settings
method, for example [3],[4].It will look for two sections in the returned value "proxy_settings" and "advanced_settings" and will display them in their own tab. for each section there are expected to be a "label" and "help_text" fields and a "settings" field with all of its options (or sub sections). The options themselves should also have "label" and "help_text" fields and also a "global_default" field that may exist.
based on:
[1] ManageIQ/manageiq#15398 - merged
[2] ManageIQ/manageiq-schema#23 - merged
[3] ManageIQ/manageiq-providers-kubernetes#45 - merged
[4] ManageIQ/manageiq-providers-openshift#32 - merged
[5] ManageIQ/manageiq#15799 - merged
[6] ManageIQ/manageiq-api#3 - merged
This aims to provide solution to a few RFEs:
https://bugzilla.redhat.com/show_bug.cgi?id=1379185
https://bugzilla.redhat.com/show_bug.cgi?id=1459189 (might be a duplicate of the previous one?)
https://bugzilla.redhat.com/show_bug.cgi?id=1459555
https://bugzilla.redhat.com/show_bug.cgi?id=1462835