[PATCH] Fix for UI inconsistencies around the catalog dropdown buttons
by Tomas Sedovic
There are some visual glitches around the catalog dropdown buttons.
For instance, the one on pools#show is positioned a bit below the other
buttons in the same row.
This is my attempt at fixing it, but my work with CSS is usually more struggle
than programming.
I would appreciate a review from someone who actually understands CSS and
visual design.
12 years, 5 months
[PATCH conductor 1/2] Fixed some missing strings for i18n
by jzigmund@redhat.com
From: Jozef Zigmund <jzigmund(a)redhat.com>
---
src/app/controllers/deployments_controller.rb | 8 ++++----
src/app/helpers/instances_helper.rb | 10 +++++-----
src/app/views/deployments/_launch_new.html.haml | 4 ++--
src/app/views/pools/_header_index.html.haml | 2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/app/controllers/deployments_controller.rb b/src/app/controllers/deployments_controller.rb
index c1a5efb..e101386 100644
--- a/src/app/controllers/deployments_controller.rb
+++ b/src/app/controllers/deployments_controller.rb
@@ -166,10 +166,10 @@ class DeploymentsController < ApplicationController
@view = 'pretty_view_show'
end
#TODO add links to real data for history, permissions, services
- @tabs = [{:name => 'Instances', :view => @view, :id => 'instances', :count => @deployment.instances.count},
+ @tabs = [{:name => t('instances.instances'), :view => @view, :id => 'instances', :count => @deployment.instances.count},
#{:name => 'Services', :view => @view, :id => 'services'},
#{:name => 'History', :view => 'history', :id => 'history'},
- {:name => 'Properties', :view => 'properties', :id => 'properties'}
+ {:name => t('properties'), :view => 'properties', :id => 'properties'}
#{:name => 'Permissions', :view => 'permissions', :id => 'permissions'}
]
add_permissions_tab(@deployment)
@@ -276,13 +276,13 @@ class DeploymentsController < ApplicationController
begin
require_privilege(Privilege::USE,instance)
unless instance.valid_action?('stop')
- raise ActionError.new("stop is an invalid action.")
+ raise ActionError.new(t('deployments.errors.stop_invalid_action'))
end
#permissons check here
@task = instance.queue_action(current_user, 'stop')
unless @task
- raise ActionError.new("stop cannot be performed on this instance.")
+ raise ActionError.new(t('deployments.errors.cannot_stop'))
end
Taskomatic.stop_instance(@task)
notices << "#{t('deployments.deployment')}: #{instance.deployment.name}, #{t('instances.instance')}: #{instance.name}: #{t('deployments.flash.notice.stop')}"
diff --git a/src/app/helpers/instances_helper.rb b/src/app/helpers/instances_helper.rb
index 882d9ad..cfc18e6 100644
--- a/src/app/helpers/instances_helper.rb
+++ b/src/app/helpers/instances_helper.rb
@@ -24,11 +24,11 @@ module InstancesHelper
[
{:name => 'checkbox', :class => 'checkbox', :sortable => false },
{:name => '', :class => 'alert', :sortable => false },
- {:name => 'Name', :sortable => false },
- {:name => 'Public Address', :sortable => false },
- {:name => 'State', :sortable => false },
- {:name => 'Provider', :sortable => false },
- {:name => 'Owner', :sortable => false }
+ {:name => t('instances.list.table.name'), :sortable => false },
+ {:name => t('instances.list.table.public_address'), :sortable => false },
+ {:name => t('instances.list.table.state'), :sortable => false },
+ {:name => t('instances.list.table.provider'), :sortable => false },
+ {:name => t('instances.list.table.owner'), :sortable => false }
]
end
end
diff --git a/src/app/views/deployments/_launch_new.html.haml b/src/app/views/deployments/_launch_new.html.haml
index e81990d..4d9e232 100644
--- a/src/app/views/deployments/_launch_new.html.haml
+++ b/src/app/views/deployments/_launch_new.html.haml
@@ -31,7 +31,7 @@
%p
%label{:for => 'catalog_entry_id'}
= t('catalog_entries.index.catalog_entry')
- = select_tag :catalog_entry_id, options_for_select([['Load definition from URL', 'other']] + @catalog_entries.map {|d| [d.name, d.id]}, params[:catalog_entry_id])
+ = select_tag :catalog_entry_id, options_for_select([[t('deployments.launch_new.load_definition'), t('deployments.launch_new.other')]] + @catalog_entries.map {|d| [d.name, d.id]}, params[:catalog_entry_id])
%p#deployable-url-section
%label{:for => 'deployable_url'}
= t('deployables.index.deployable_url')
@@ -46,7 +46,7 @@
= select :deployment, :frontend_realm_id, @realms.map{|r| [r.name, r.id]}, :include_blank => true
%fieldset.options
- = submit_tag 'Next', :class => 'button', :id => "next_button"
+ = submit_tag t('deployments.launch_new.next'), :class => 'button', :id => "next_button"
:javascript
diff --git a/src/app/views/pools/_header_index.html.haml b/src/app/views/pools/_header_index.html.haml
index cb50c16..ef03505 100644
--- a/src/app/views/pools/_header_index.html.haml
+++ b/src/app/views/pools/_header_index.html.haml
@@ -3,7 +3,7 @@
#obj_actions.button-container
.button-group
= pretty_filter_toggle(pools_path(:view => 'pretty'), pools_path(:view => 'filter'))
- = link_to t('pools.index.new_pool'), new_pool_path, { :class => 'button primary', :id => 'new_pool_button' }
+ = link_to t('pools.new_pool'), new_pool_path, { :class => 'button primary', :id => 'new_pool_button' }
.corner
= render :partial => 'scoreboard_index'
--
1.7.6.4
12 years, 5 months
[PATCH conductor 0/1] Rake tasks for developers
by Matt Wagner
Hi all,
This adds some rake tasks I've cobbled together to automate things I do a lot. (Okay, some more often than others.)
I was on the fence about whether or not this needs an ACK, but I wouldn't mind a set of eyes just since I haven't done much with rake tasks so I could be doing something foolish and not realize it. Hopefully others will find it useful, and maybe contribute others.
-- Matt
12 years, 5 months
[PATCH conductor 0/1] Security fix - secret_token
by Matt Wagner
Hi all,
I just discovered that we are not, by default, modifying the secret_token that Rails uses to sign its cookies. (For some reason, the Rails security guide makes no mention of this.) It is my understanding that, if an attacker knows the secret token a Rails installation is using, they can modify session cookies however they wish (e.g., becoming an administrator) and then use the token to sign the cookie so Rails accepts it.
This patch adds a rake task to generate a new token and replace the one in the config/initializers/secret_token.rb file. It also invokes this task in the %post section of the RPM spec file, so that it will be re-generated when installing. (I don't think invoking it from aeolus-configure (in puppet) would be adequate, as it would leave people vulnerable until they ran aeolus-configure the first time.)
I'm not super-experienced with RPM specs, so someone should review the RPM spec and make sure I'm not doing anything absurd. Since the rake task is part of the app, it has to run in %post, since it won't exist in %install. Note that the added "Requires: rubygem(rake)" isn't really a new dependency. Rails requires it, but it was suggested that, since we're using it in the spec, we should explicitly require it.
One small side-effect of this patch is that a user who updates to a new RPM will have their token regenerated. This would invalidate existing cookies, which will cause users to be logged out. I think this is perfectly-acceptable and possibly desirable, but if you disagree, we could change the rake task to look for the specific default token and only replace that.
We may want to backport this change as I believe this vulnerability has existed from the beginning.
-- Matt
12 years, 5 months
[PATCH conductor] Remove the <li> bullets from deployments#show
by Tomas Sedovic
From: Tomas Sedovic <tsedovic(a)redhat.com>
---
src/app/stylesheets/custom.scss | 19 +++++++++++++++++++
.../views/deployments/_pretty_view_show.html.haml | 11 ++++++-----
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/src/app/stylesheets/custom.scss b/src/app/stylesheets/custom.scss
index 4059954..7d2c7d0 100644
--- a/src/app/stylesheets/custom.scss
+++ b/src/app/stylesheets/custom.scss
@@ -216,3 +216,22 @@ form.generic section.services {
font-weight: normal;
}
}
+
+.instances_list {
+ li {
+ list-style-type: none;
+ }
+
+ .state {
+ font-weight: bold;
+ }
+
+ li.instance {
+ margin-top: 1em;
+ font-weight: bold;
+
+ ul {
+ font-weight: normal;
+ }
+ }
+}
diff --git a/src/app/views/deployments/_pretty_view_show.html.haml b/src/app/views/deployments/_pretty_view_show.html.haml
index 76ba477..df12258 100644
--- a/src/app/views/deployments/_pretty_view_show.html.haml
+++ b/src/app/views/deployments/_pretty_view_show.html.haml
@@ -2,7 +2,7 @@
%h2=t 'instances.instances'
%ul.instances_list
- @deployment.instances.each do |instance|
- %li
+ %li.instance
= instance.name
%ul
%li
@@ -10,7 +10,7 @@
= instance.public_addresses
%li
= t 'deployments.pretty_view_show.state'
- = instance.state
+ %span.state= instance.state
- if instance.instance_key
%li
= link_to t('deployments.pretty_view_show.download_key'), key_instance_path(instance)
@@ -22,10 +22,11 @@
%script#instanceTemplate{ :type => 'text/x-jquery-tmpl' }
:plain
- <li>${name}
+ <li class="instance">${name}
<ul>
- <li>#{t('deployments.pretty_view_show.ip_address')}: ${public_addresses}</li>
- <li>#{t('deployments.pretty_view_show.state')}: ${state}</li>
+ <li>#{t('deployments.pretty_view_show.ip_address')} ${public_addresses}</li>
+ <li>#{t('deployments.pretty_view_show.state')}
+ <span class="state">${state}</span></li>
{{if has_key}}
<li><a href="#{key_instance_path('replace_id').sub('replace_id', '${id}')}">#{t('deployments.pretty_view_show.download_key')}</a></li>
{{/if}}
--
1.7.6.4
12 years, 5 months
[PATCH conductor] Redirect to proper page on submitting new permissions.
by Scott Seago
This was possibly lost in rebasing/merging the original patch before pushing, but the redirect on submit was going to the wrong place for prodiver permissions, since the provider tabs are on the edit action instead of show.
---
src/app/views/permissions/_permissions.html.haml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/app/views/permissions/_permissions.html.haml b/src/app/views/permissions/_permissions.html.haml
index 5a6e342..55c6d9e 100644
--- a/src/app/views/permissions/_permissions.html.haml
+++ b/src/app/views/permissions/_permissions.html.haml
@@ -1,6 +1,6 @@
- content_for :form_header do
- if check_privilege(Privilege::PERM_SET)
- %li= link_to t('permissions.form.grant_access'), new_permission_path(:permission_object_type => @permission_object.class.name, :permission_object_id => @permission_object.id), { :class => 'button primary', :id => 'new_permission_button'}
+ %li= link_to t('permissions.form.grant_access'), new_permission_path(:permission_object_type => @permission_object.class.name, :permission_object_id => @permission_object.id, :path_prefix => @path_prefix), { :class => 'button primary', :id => 'new_permission_button'}
%li= restful_submit_tag t('permissions.revoke_access'), "destroy", multi_destroy_permissions_path, 'DELETE', :id => 'revoke_button', :class => 'button danger'
%li= restful_submit_tag t('edit'), "multi_update", multi_update_permissions_path, 'POST', :id => 'edit_button', :class => 'hidden'
= hidden_field_tag :permission_object_type, @permission_object.class.name
--
1.7.6.4
12 years, 5 months
[PATCH Audrey] Fix the config server spec to require mod_ssl
by Greg Blomquist
Currently, the aeolus-configserver-proxy spec does not require mod_ssl.
Strangely, up until now mod_ssl was automagically getting installed when httpd
(or aeolus-configserver-proxy) was installed.
After testing on a sparkling new ec2 instance, it's clear that whatever black
magic was in play before is now gone.
Now, aeolus-configserver-proxy explicitly requires mod_ssl.
(pushing to the master branch)
12 years, 5 months