similar to: [PATCH server] add collapsable sections to vm form

the vm form is getting cluttered, this patch simply add collapsable sections to the form, making the 'storage' and 'network' sections collapsed by default --- src/app/helpers/application_helper.rb | 9 +++++ src/app/views/vm/_form.rhtml | 55 +++++++++++++++++++++++++-------- src/public/javascripts/ovirt.js | 25 +++++++++++++++

From: Simon Courtois <scourtois at linagora.com> Signed-off-by: Simon Courtois <scourtois at linagora.com> --- src/app/controllers/vm_controller.rb | 19 ++++++++++++++++- src/app/views/vm/_form.rhtml | 25 ++++++++++++++++++++--- src/db/migrate/044_add_virtio_to_vm_and_nic.rb | 11 ++++++++++ src/public/stylesheets/components.css | 5

the vm form is getting cluttered, this patch simply add collapsable sections to the form, making the 'resources' and 'network' sections collapsed by default - icon added - methods added to the js - reorganization / cleanup in rhtml, indentation changes, no functionality or content changes --- src/app/views/vm/_form.rhtml | 109

It can be quite hard to manage a pool of 40-50 VMs without informations about the OS running, the contact (which is the only one to know when the vm can really be destroyed) or an End Of Life date. This patch add those fields, and rework a little the VM list view, in order to show gracefully those new fields. It has been made at the expense of UUID, Total Run Time & Load fields. Since those

- changes to the form/style cleaning it up greatly - changes to the controller fixing allowing nics/ networks to actually be saved (credit to Michel Loiseleur for helping with this) - very small test and indentation fixes --- src/app/controllers/vm_controller.rb | 41 +++- src/app/views/vm/_form.rhtml | 365 ++++++++++++++---------------

--- src/app/models/vm.rb | 2 ++ src/app/views/vm/_form.rhtml | 23 +++++++++++++++++++++++ 2 files changed, 25 insertions(+), 0 deletions(-) diff --git a/src/app/models/vm.rb b/src/app/models/vm.rb index 3e0a6fa..9d326ac 100644 --- a/src/app/models/vm.rb +++ b/src/app/models/vm.rb @@ -464,6 +464,8 @@ class Vm < ActiveRecord::Base

created/edit network information is all specified on one simpler form --- src/app/controllers/network_controller.rb | 27 +++++++++++++++---- src/app/models/bonding.rb | 2 +- src/app/models/network.rb | 2 +- src/app/models/nic.rb | 2 +- src/app/views/network/_form.rhtml | 15

- db, model, service, controller, and view changes - many tests additions - various fixes / cleanup to get things working depends on my last two (still unacked) patches: - add collapsable sections to vm form - provide default vm allocated cpu and memory values ovirt-agent might need to be updated to work with the changes --- src/app/controllers/pool_controller.rb | 2 +-

since the introduction of ovirt-vnc-proxy and the updating of ovirt-viewer to user it the forward vnc functionality is no longer necessary / and incompatable w/ the current system. --- src/app/controllers/vm_controller.rb | 2 - src/app/models/host.rb | 9 - src/app/models/vm.rb | 36 ----

Hi I''ve created a migration called make_customer_type_id_not_null_for_customers. The migration .rb file looks like this: class MakeCustomerTypeIdNotNullForCustomers < ActiveRecord::Migration def self.up change_column(:customers, :customer_type_id, :integer, { :null => false }) end def self.down change_column(:customers, :customer_type_id, :integer, { :null =>

Howdy Y''all, I was thrilled to recently discover migrations, as that framework addresses a common problem in an elegant way. I have, however, gotten tripped up a bit as I''ve worked with them. The first problem I encountered was that, though I was using a BigInt data type in a field in my dev database, my unit tests were failing because when I copied the schema from the dev

Hello, Currently if you have a string column that have only number values (think a year column using string by mistake) and you want to change to integer, you can''t. If you apply this monkey-patch will be possible: https://gist.github.com/1393441 Note: if some value can''t be casted by postgresql (if have a letter for example), the migration will fail as expected. I think

Hi all, I''m working on a financial app, and have set up some columns in my tables as decimals with precision => 8 and scale => 2. My migration looks like: change_column :lineitems, :price, :decimal, :precision => 8, :scale => 2 change_column :payments, :amount, :decimal, :precision => 8, :scale => 2 I''ve run the migration and restarted the server. I

All, It looks like rake db:schema:dump does not dump primary keys. I have some legacy table that don''t follow the convention ie pk = id and none of the primary keys for these tables are getting dumped... Seems strange as this should be readily available from the db. I am using MySQL. Is anybody else seeing that ? Incidentally how does one specify a primary key using

Hi. I get some strange results when using rename_column on a primary key in a migration. It seems like the migration script removes the auto-increment property if you rename a column. This is a minimal example. create_table :foo, :primary_key => :foo_id do |t| t.column "name", :string end # renaming the primary key makes auto-increment disappear. rename_column

This seems pretty brain dead: add_column :types, :notify_on_create, :boolean, {:default=>true, :null=>false} $ rake migrate Error: ERROR: column "notify_on_create" contains null values : ALTER TABLE types ALTER notify_on_create SET NOT NULL Why doesn''t Rails set the new column to true, as it''s supposed to default to? I tried :default=>1 as well (same

Hi, It appears to me that the command: ruby script/generate scaffold whatever money_field:decimal(10,2) will not generate a valid migration. Therefore it appears to me only two ways to achieve the desired result is: 1.1 Omit the the precision/scale on the scaffold command 1.2 Edit the migration file by following the "do |t| ... end" with the command: change_column :whatever

Hi guys, I''m having problems removing the default from a boolean field. I''m using the following statement: change_column :valuations, :too_many_adults, :integer, :null => true but it''s adding DEFAULT ''0'' to the SQL statement. I''m having no luck using change_column_default either. Is this possible? Gareth

This suddenly started happening to my app today. No code changes, so I expect that this has something to do with a server change. I''m using Login Engine and ActiveRecord sessions. LE stores the whole user object in the session, then pulls it out as needed with UserController#current_user. Out of the blue today this starts failing with the infamous "you''re serializing AR

Rails3.1.3 I have db type, startp:integer I need to change it to float. More specifically, 1.2, 45.1, 143.8 ... I have two questions: 1. Is removing and adding the field through migration the only way? in other words, is there a single command to change the type? 2. Is there anyway to limit the decimal place to only one? 56.3, 34.2... are acceptable, but 23.112, 77.34, ... are