Skip to content
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

Fixed links to point to correct provider controller based upon type. #4760

Merged

Conversation

h-kataria
Copy link
Contributor

@martinpovolny
Copy link
Member

martinpovolny commented Oct 12, 2018

@h-kataria , I am concerned that similar functionality already exists in app/controllers/restful_redirect_controller.rb.

Furthermore the code in the RestfulRedirectController shows, that there are situations where the information used in this PR does not suffice for the decision.

Therefor I suggest investigating if a fix for the BZ can be implemented using the existing code rather that adding similar logic on the Javascript side.

var action = '/';
var descriptors = providerType.split('::');

switch (descriptors.pop()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this client-side specification because it has to be in sync with the controllers all the time. What do you think about using the restful_redirect_controller instead? This way the switch could be completely removed and the redirect decision logic could live in that controller.

@skateman
Copy link
Member

Oh, I see @martinpovolny had the exact same idea 🤣

@h-kataria h-kataria force-pushed the fixed_provider_links_on_alerts_list branch 3 times, most recently from eddc392 to 932e0b1 Compare October 15, 2018 13:47
Copy link
Member

@skateman skateman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if you try to use singular_route_key, you could probably make the code just a few lines and move it under the ˙index˙ route.

action = '/'
descriptors = params['provider_type'].split('::')

case descriptors.last
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about

provider_type.constantize.model_name.singular_route_key

?

config/routes.rb Outdated
@@ -2830,6 +2830,7 @@
:restful_redirect => {
:get => %w(
index
provider_url
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really like the new route thing, any reason why this isn't under index?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skateman i kept it separate from index method because that method expects different params and is being used to redirect to a page based upon model that's passed in. provider_url sets a link that is being used by list of Alerts, not sure if it's a good idea to mix the both methods.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And what about passing them the same params? Like ˙ExtManagementSystemasmodeland theid`. And use the method I wrote above to determine the URL.

@h-kataria h-kataria force-pushed the fixed_provider_links_on_alerts_list branch from 932e0b1 to e83b2c1 Compare October 16, 2018 20:16
@h-kataria
Copy link
Contributor Author

@skateman please review/test. Thanks for the help!

@@ -488,6 +488,15 @@ function alertsCenterService(API, $q, $timeout, $document, $uibModal, $http) {
}
}

var providerLink = function(providerType, providerId, newAlert) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You no longer need the providerType argument

Suggested change
var providerLink = function(providerType, providerId, newAlert) {
var providerLink = function(providerId, newAlert) {

@@ -532,7 +540,7 @@ function alertsCenterService(API, $q, $timeout, $document, $uibModal, $http) {
}

updateAlertStatus(newAlert);

providerLink(objectClassifiedType, alertData.ems_id, newAlert);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
providerLink(objectClassifiedType, alertData.ems_id, newAlert);
providerLink(alertData.ems_id, newAlert);

@@ -488,6 +488,15 @@ function alertsCenterService(API, $q, $timeout, $document, $uibModal, $http) {
}
}

var providerLink = function(providerType, providerId, newAlert) {
$http.get('/restful_redirect/index?model=ExtManagementSystem&id=' + providerId)
.then(updateNewAlert);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.then(updateNewAlert);
.then(function(response) {
newAlert.objectLink = response.data.data;
});

@h-kataria h-kataria force-pushed the fixed_provider_links_on_alerts_list branch 2 times, most recently from 020b8b9 to 0bae925 Compare October 17, 2018 13:56
@@ -532,7 +538,7 @@ function alertsCenterService(API, $q, $timeout, $document, $uibModal, $http) {
}

updateAlertStatus(newAlert);

providerLink(alertData.ems_id, newAlert);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about having the link straight to '/restful_redirect/index?model=ExtManagementSystem&id=' + providerId and just use redirect_to so it is consistent?

@h-kataria h-kataria force-pushed the fixed_provider_links_on_alerts_list branch 2 times, most recently from c1fea76 to e571eb4 Compare October 18, 2018 13:51
@skateman
Copy link
Member

skateman commented Oct 18, 2018

I know that Real Programmers aren't afraid to use GOTO's, but I am not a fan of that style and this looks almost like that. So what about creating a private handle_error (I'm sure you can come up with a better name) method that does the error handling, call it when something goes wrong and also in the else branch of the case?

case xy
when a
  handle_error unless record
  blah
when b
  ...
else
  handle_error
end

@h-kataria h-kataria force-pushed the fixed_provider_links_on_alerts_list branch from e571eb4 to 6e5928b Compare October 18, 2018 16:11
unless record
handle_error
return
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
end
return handle_error unless

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe

Suggested change
end
record ? redirect_to() : handle_error

handle_error
return
end
redirect_to(polymorphic_path(record))
when 'ServiceTemplateTransformationPlanRequest'
req = ServiceTemplateTransformationPlanRequest.select(:source_id).find(params[:id])
redirect_to(:controller => 'migration', :action => 'index', :anchor => "plan/#{req.source_id}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you might have to add the error handling here as well...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you if in a separate commit or here

end
end

def handle_error
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I seriously thought you can come up with a better name than I, but it's okay 🤣

Added a method in restful_redirect_controller that can be called from JS service to determine provider link. Moved fallback code to redirect to dashboard show with flash message out of switch.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1637609
@h-kataria h-kataria force-pushed the fixed_provider_links_on_alerts_list branch from 6e5928b to efa4d7a Compare October 18, 2018 20:48
end
end

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private

@h-kataria h-kataria force-pushed the fixed_provider_links_on_alerts_list branch from 293f8f0 to c186097 Compare October 19, 2018 18:17
@miq-bot
Copy link
Member

miq-bot commented Oct 19, 2018

Checked commits h-kataria/manageiq-ui-classic@efa4d7a~...c186097 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
2 files checked, 0 offenses detected
Everything looks fine. ⭐

Copy link
Member

@skateman skateman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Seal of Approval

@mzazrivec mzazrivec added this to the Sprint 97 Ending Oct 22, 2018 milestone Oct 22, 2018
@mzazrivec mzazrivec merged commit 5a0d67d into ManageIQ:master Oct 22, 2018
simaishi pushed a commit that referenced this pull request Oct 22, 2018
…s_list

Fixed links to point to correct provider controller based upon type.

(cherry picked from commit 5a0d67d)

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1637609
@simaishi
Copy link
Contributor

Hammer backport details:

$ git log -1
commit 74bee4611f3f701727228a28df158d69e5a69cc4
Author: Milan Zázrivec <mzazrivec@redhat.com>
Date:   Mon Oct 22 17:14:47 2018 +0200

    Merge pull request #4760 from h-kataria/fixed_provider_links_on_alerts_list
    
    Fixed links to point to correct provider controller based upon type.
    
    (cherry picked from commit 5a0d67dfaa4c729ceb5defa30147767b18e6a9ea)
    
    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1637609

@h-kataria h-kataria deleted the fixed_provider_links_on_alerts_list branch October 24, 2018 22:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants