I am using Spree 3.0.0, Spree Print Invoice gem and I have set it up in my gemfile using the branch: '3-0-stable'.
I have installed it with the command
bundle && exec rails g spree_print_invoice:install
I have a simple config/initializers/print_invoice.rb
Spree::PrintInvoice::Config.set(page_layout: :portrait,page_size: 'A4')
Spree::PrintInvoice::Config.set(print_buttons: 'invoice')
Spree::PrintInvoice::Config.set(store_pdf: true) # Default: tmp/order_prints
I have now in my admin configuration a Print Invoice Settings section as well as a print invoice button with each orders.
Here is the log when creating invoice:
Started GET "/admin/orders/R123456789.pdf?template=invoice" for ::1 at 2015-07-22 17:10:00 -0500
Processing by Spree::Admin::OrdersController#show as PDF
Parameters: {"template"=>"invoice", "id"=>"R123456789"}
Spree::Preference Load (0.3ms) SELECT "spree_preferences".* FROM "spree_preferences" WHERE "spree_preferences"."key" = $1 LIMIT 1 [["key", "spree/backend_configuration/locale"]]
Spree::User Load (0.5ms) SELECT "spree_users".* FROM "spree_users" WHERE "spree_users"."deleted_at" IS NULL AND "spree_users"."id" = $1 ORDER BY "spree_users"."id" ASC LIMIT 1 [["id", 6]]
(0.4ms) SELECT COUNT(*) FROM "spree_roles" INNER JOIN "spree_roles_users" ON "spree_roles"."id" = "spree_roles_users"."role_id" WHERE "spree_roles_users"."user_id" = $1 AND "spree_roles"."name" = $2 [["user_id", 6], ["name", "admin"]]
Spree::Order Load (0.6ms) SELECT "spree_orders".* FROM "spree_orders" WHERE "spree_orders"."number" = $1 ORDER BY "spree_orders"."id" ASC LIMIT 1 [["number", "R123456789"]]
Spree::Adjustment Load (0.5ms) SELECT "spree_adjustments".* FROM "spree_adjustments" WHERE "spree_adjustments"."adjustable_type" = 'Spree::Order' AND "spree_adjustments"."adjustable_id" IN (1) ORDER BY spree_adjustments.created_at ASC
Rendered text template (0.0ms)
Sent data (2.7ms)
Completed 200 OK in 18ms (Views: 2.5ms | ActiveRecord: 2.3ms)
The invoices are created into tmp/order_prints but they all are completely blanks. The pdf viewer of my browser is blocked on loading.
Anything I need to do in order to make it work?
Related
Today I was attempting to set up caching using ActiveModelSerializers. I was having a lot of problems (my connection kept timing out). So I attempted to revert all my changes, including deleting the branch I was working on.
However, ever since I tried to set up caching, the model I was working with has exhibited strange behavior. It looks like it's still loading the cache elements. This is causing a huge performance hit when trying to access the endpoint for that model.
Started GET "/api/v1/entities" for ::1 at 2016-11-17 16:50:44 -0700
ActiveRecord::SchemaMigration Load (0.3ms) SELECT "schema_migrations".* FROM "schema_migrations"
Processing by Api::V1::EntitiesController#index as JSON
Entity Load (0.4ms) SELECT "entities".* FROM "entities" ORDER BY "entities"."name" ASC
Group Load (0.3ms) SELECT "groups".* FROM "groups" WHERE "groups"."id" IN (2, 3, 1) ORDER BY "groups"."name" ASC
Platform Load (0.4ms) SELECT "platforms".* FROM "platforms" WHERE "platforms"."id" IN (3, 8) ORDER BY "platforms"."name" ASC
HardwareType Load (19.3ms) SELECT "hardware_types".* FROM "hardware_types" WHERE "hardware_types"."id" IN (1, 3, 19, 8)
EntityType Load (0.2ms) SELECT "entity_types".* FROM "entity_types" WHERE "entity_types"."id" IN (1)
EntityOperationalState Load (0.4ms) SELECT "entity_operational_states".* FROM "entity_operational_states" WHERE "entity_operational_states"."entity_id" IN (1, 2, 3, 4)
OperationalState Load (0.2ms) SELECT "operational_states".* FROM "operational_states" WHERE "operational_states"."id" IN (1) ORDER BY "operational_states"."name" ASC
EntityLifecycleState Load (0.4ms) SELECT "entity_lifecycle_states".* FROM "entity_lifecycle_states" WHERE "entity_lifecycle_states"."entity_id" IN (1, 2, 3, 4)
LifecycleState Load (0.3ms) SELECT "lifecycle_states".* FROM "lifecycle_states" WHERE "lifecycle_states"."id" IN (2) ORDER BY "lifecycle_states"."name" ASC
IpAddress Load (0.3ms) SELECT "ip_addresses".* FROM "ip_addresses" WHERE "ip_addresses"."entity_id" IN (1, 2, 3, 4)
IpType Load (0.2ms) SELECT "ip_types".* FROM "ip_types" WHERE "ip_types"."id" IN (1)
IpUse Load (0.4ms) SELECT "ip_uses".* FROM "ip_uses" WHERE "ip_uses"."id" IN (1, 2)
[active_model_serializers] Entity Load (0.3ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 1]]
[active_model_serializers] CACHE (0.0ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 1]]
[active_model_serializers] Entity Load (0.2ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 2]]
[active_model_serializers] CACHE (0.0ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 2]]
[active_model_serializers] Entity Load (0.2ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 3]]
[active_model_serializers] CACHE (0.0ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 3]]
[active_model_serializers] Rendered ActiveModel::Serializer::CollectionSerializer with ActiveModelSerializers::Adapter::Json (71.13ms)
Completed 200 OK in 617ms (Views: 474.3ms | ActiveRecord: 27.8ms)
The [active_model_serializers] Load and CACHE are the new things that lead me to believe the serializer still attempting to load from cache.
My other models, which I didn't touch load with just one [active_model_serializers] statement, which is the behavior I expected.
Started GET "/api/v1/groups" for ::1 at 2016-11-17 16:56:15 -0700
Processing by Api::V1::GroupsController#index as JSON
Group Load (0.2ms) SELECT "groups".* FROM "groups" ORDER BY "groups"."name" ASC
Platform Load (0.3ms) SELECT "platforms".* FROM "platforms" WHERE "platforms"."id" IN (8, 3) ORDER BY "platforms"."name" ASC
GroupOperationalState Load (0.2ms) SELECT "group_operational_states".* FROM "group_operational_states" WHERE "group_operational_states"."group_id" IN (1, 2, 3)
OperationalState Load (0.2ms) SELECT "operational_states".* FROM "operational_states" WHERE "operational_states"."id" IN (1) ORDER BY "operational_states"."name" ASC
GroupLifecycleState Load (0.4ms) SELECT "group_lifecycle_states".* FROM "group_lifecycle_states" WHERE "group_lifecycle_states"."group_id" IN (1, 2, 3)
LifecycleState Load (0.2ms) SELECT "lifecycle_states".* FROM "lifecycle_states" WHERE "lifecycle_states"."id" IN (2) ORDER BY "lifecycle_states"."name" ASC
GroupConfigurationProfile Load (0.3ms) SELECT "group_configuration_profiles".* FROM "group_configuration_profiles" WHERE "group_configuration_profiles"."group_id" IN (1, 2, 3)
ConfigurationProfile Load (0.3ms) SELECT "configuration_profiles".* FROM "configuration_profiles" WHERE "configuration_profiles"."id" IN (1, 2, 3) ORDER BY "configuration_profiles"."name" ASC
[active_model_serializers] Rendered ActiveModel::Serializer::CollectionSerializer with ActiveModelSerializers::Adapter::Json (1.4ms)
Completed 200 OK in 51ms (Views: 36.3ms | ActiveRecord: 2.1ms)
Started GET "/api/v1/ip_addresses" for ::1 at 2016-11-17 16:58:34 -0700
Processing by Api::V1::IpAddressesController#index as JSON
IpAddress Load (0.2ms) SELECT "ip_addresses".* FROM "ip_addresses"
Entity Load (0.3ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" IN (1, 2, 3) ORDER BY "entities"."name" ASC
IpUse Load (0.2ms) SELECT "ip_uses".* FROM "ip_uses" WHERE "ip_uses"."id" IN (1, 2)
IpType Load (0.1ms) SELECT "ip_types".* FROM "ip_types" WHERE "ip_types"."id" IN (1)
[active_model_serializers] Rendered ActiveModel::Serializer::CollectionSerializer with ActiveModelSerializers::Adapter::Json (2.85ms)
Completed 200 OK in 28ms (Views: 14.8ms | ActiveRecord: 0.9ms)
Those extra trips to the db are slowing down my load times, as you can see. These models all have around 3 objects right now, but when I was testing with many more records, this becomes a huge problem.
How can I force ActiveModelSerializer to either ignore the cached items?
A better option would be to figure out where those fragments were cached, so I can clear them out. I tried Rails.cache.clear, but this has no effect. I also tried, rebooting the computer, and also shutting down my Redis instance.
Never mind. Apparently this has nothing to do with the caching work I was doing.
I had a circular reference to the entity name in my has_many relationship
I'm trying to do what I think should be simple: do a simple edit on a single text string field with the default update action. But it just doesn't seem to work, despite many attempts and alterations.
There are no errors and the flash message responds successfully, but information isn't saved to the database at all:
routes.rb
resources :interviews do
resources :invitations do
put :accept
end
end
views/invitations/edit.html.haml
= simple_form_for [#interview, #invitation] do |f|
= f.error_notification
= f.input :testing
= f.submit 'Edit Invitstion', :class => 'button small'
controllers/invitations_controller.rb
def update
#invitation = Invitation.find(params[:id])
#interview = Interview.find(params[:interview_id])
#invitation.update_attributes(invitation_params)
if #invitation.update_attributes(invitation_params)
redirect_to edit_interview_invitation_path(#interview, #invitation), notice: "Your profile has been successfully updated."
else
render action: "edit"
end
end
private
def invitation_params
params.permit(:user_id, :interview_id, :invitation_id, :session_time, :workflow_state, :testing)
end
And here's the log:
Started PATCH "/interviews/3/invitations/7" for ::1 at 2016-05-15 19:01:52 +0800
Processing by InvitationsController#update as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"o0U5t0yPN0aE2er+DWK0uxqRGyp4ywfdSrEfvwiSQ3UUaOnr3Fd0raFs1IUqVzizKoqxRU0DDpmvysntB9fdhQ==", "invitation"=>{"interview_id"=>"3", "workflow_state"=>"invited", "session_time"=>"", "testing"=>"testtesttest"}, "commit"=>"Edit Invitstion", "interview_id"=>"3", "id"=>"7"}
User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT 1 [["id", 7]]
Invitation Load (0.2ms) SELECT "invitations".* FROM "invitations" WHERE "invitations"."id" = $1 LIMIT 1 [["id", 7]]
Role Load (0.2ms) SELECT "roles".* FROM "roles" WHERE "roles"."id" = $1 LIMIT 1 [["id", 3]]
Interview Load (0.2ms) SELECT "interviews".* FROM "interviews" WHERE "interviews"."id" = $1 ORDER BY created_at DESC LIMIT 1 [["id", 3]]
CACHE (0.0ms) SELECT "invitations".* FROM "invitations" WHERE "invitations"."id" = $1 LIMIT 1 [["id", "7"]]
CACHE (0.0ms) SELECT "interviews".* FROM "interviews" WHERE "interviews"."id" = $1 ORDER BY created_at DESC LIMIT 1 [["id", "3"]]
Unpermitted parameters: utf8, _method, authenticity_token, invitation, commit, id
(0.1ms) BEGIN
Invitation Exists (0.4ms) SELECT 1 AS one FROM "invitations" WHERE ("invitations"."user_id" = 3 AND "invitations"."id" != 7 AND "invitations"."interview_id" = 3) LIMIT 1
(0.1ms) COMMIT
Redirected to http://localhost:3000/interviews/3/invitations/7/edit
Completed 302 Found in 12ms (ActiveRecord: 1.6ms)
Started GET "/interviews/3/invitations/7/edit" for ::1 at 2016-05-15 19:01:52 +0800
Processing by InvitationsController#edit as HTML
Parameters: {"interview_id"=>"3", "id"=>"7"}
User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT 1 [["id", 7]]
Invitation Load (0.3ms) SELECT "invitations".* FROM "invitations" WHERE "invitations"."id" = $1 LIMIT 1 [["id", 7]]
Role Load (0.2ms) SELECT "roles".* FROM "roles" WHERE "roles"."id" = $1 LIMIT 1 [["id", 3]]
Interview Load (0.2ms) SELECT "interviews".* FROM "interviews" WHERE "interviews"."id" = $1 ORDER BY created_at DESC LIMIT 1 [["id", 3]]
Rendered invitations/edit.html.haml within layouts/application (6.1ms)
Completed 200 OK in 48ms (Views: 39.1ms | ActiveRecord: 1.6ms)
Check the format of your params object in your logs. Your invitation params are being passed within the params["invitation"] key, yet you're whitelisting and updating your object based on the params in the root params hash.
Also note that your logs are reporting that you're trying to update your invitation with unpermitted params:
Unpermitted parameters: utf8, _method, authenticity_token, invitation, commit, id
You can fix this by simply updating your invitation_params to use params[:invitation] rather than params like so:
def invitation_params
params.require(:invitation).permit(:user_id, :interview_id, :invitation_id, :session_time, :workflow_state, :testing)
end
Also, you might want to consider raising an error if you're trying to update a parameter that's not whitelisted to prevent these sorts of issues in the future.
In your rails config:
config.action_controller.action_on_unpermitted_parameters = :raise
I have a rails app and I'd like to extract 2 different ids from this url:
http://localhost:3000/shopping/suppliers/2/products/1
Looking at the development.log it seems like both values are there.
I'm wondering how I can expose these params to the controller, is it just params[:supplier_id] and params[:id]?
Started GET "/shopping/suppliers/2/products/1" for 127.0.0.1 at 2016-04-22 18:28:19 +1000
Processing by Shopping::ProductsController#show as HTML
Parameters: {"supplier_id"=>"2", "id"=>"1"}
Product Load (30.1ms) SELECT "products".* FROM "products" WHERE "products"."permalink" = $1 ORDER BY "products"."id" ASC LIMIT 1 [["permalink", "1"]]
Product Load (0.8ms) SELECT "products".* FROM "products" WHERE "products"."id" = $1 LIMIT 1 [["id", 1]]
User Load (19.6ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT 1 [["id", 1]]
CACHE (0.0ms) SELECT "products".* FROM "products" WHERE "products"."permalink" = $1 ORDER BY "products"."id" ASC LIMIT 1 [["permalink", "1"]]
CACHE (0.0ms) SELECT "products".* FROM "products" WHERE "products"."id" = $1 LIMIT 1 [["id", "1"]]
Rendered shopping/products/show.html.haml within layouts/mdl (0.3ms)
Rendered shared/_meta_data.html.haml (0.8ms)
Rendered shared/_top_cart.html.haml (0.1ms)
Rendered shared/_compact_menu.html.haml (4.5ms)
Completed 200 OK in 109ms (Views: 46.2ms | ActiveRecord: 50.8ms)
Yes, you should be able to access your values with those keys:
params[:supplier_id]
params[:id]
It is wierd why you have not tried your own suggestion before posting your question. :)
I have a table subscription with a column status. In my subscriptions controller I have a method accept_player that is supposed to update the subscription.status to "confirmed!"
def accept_player
#subscription = Subscription.find(params[:subscription_id_accept_player])
#subscription.status = "confirmed!"
#subscription.save
authorize #subscription
redirect_to tournament_subscriptions_path(#subscription.tournament)
end
unfortunately every time I try to trigger that method, a rollback seem to take place:
Started POST "/accept_player/39" for ::1 at 2015-07-08 22:01:21 +0100
ActiveRecord::SchemaMigration Load (12.4ms) SELECT "schema_migrations".* FROM "schema_migrations"
/Users/davidgeismar/code/davidgeismar/tennis-match/app/controllers/subscriptions_controller.rb:141: warning: duplicated key at line 155 ignored: "CardType"
Processing by SubscriptionsController#accept_player as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"aas8OPHBpvPwNbbmx/SVipsRM+eKo63nuVilMroxKcU9HRVonjSqEuH7aLY91gFi9PHMUsUqRqk7qhnv2m4L/A==", "subscription_id_accept_player"=>"39", "commit"=>"Confirmer ce Joueur", "subscription_id"=>"39"}
User Load (13.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT 1 [["id", 2]]
Subscription Load (11.6ms) SELECT "subscriptions".* FROM "subscriptions" WHERE "subscriptions"."id" = $1 LIMIT 1 [["id", 39]]
(5.7ms) BEGIN
Subscription Exists (0.8ms) SELECT 1 AS one FROM "subscriptions" WHERE ("subscriptions"."user_id" = 20 AND "subscriptions"."id" != 39 AND "subscriptions"."tournament_id" = 9) LIMIT 1
(12.6ms) ROLLBACK
Tournament Load (2.4ms) SELECT "tournaments".* FROM "tournaments" WHERE "tournaments"."id" = $1 LIMIT 1 [["id", 9]]
User Load (0.4ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 2]]
Redirected to http://localhost:3000/tournaments/9/subscriptions
Completed 302 Found in 246ms (ActiveRecord: 79.7ms)
Any ideas about what might be going wrong here ?
This code:
authorize #subscription
is probably causing the rollback. If you're in dev mode, just comment it out, reload!, and try to manually add a record and see if that's the cause.
In all of my years of Rails dev, I have never encountered an issue like this.
If I run an Update action, i.e. Node#Update, it seems to successfully run, this is the log:
Started PATCH "/nodes/35" for 127.0.0.1 at 2015-02-06 19:25:45 -0500
Processing by NodesController#update as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"F1HGLwIjDG3VaIYlnsu7NbROEiWBO8xqJtjh5MreI9E=", "node"=>{"name"=>"Testy", "parents"=>"37", "family_tree_id"=>"2"}, "commit"=>"Update Node", "id"=>"35"}
Node Load (1.1ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 35]]
(0.9ms) BEGIN
Node Load (0.9ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 37]]
(1.0ms) COMMIT
Redirected to http://localhost:3000/nodes/35
Completed 302 Found in 13ms (ActiveRecord: 3.9ms)
But then if I go back to the Node#Edit, I get this error:
Started GET "/nodes/35/edit" for 127.0.0.1 at 2015-02-06 19:32:39 -0500
Processing by NodesController#edit as HTML
Parameters: {"id"=>"35"}
Node Load (1.1ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 35]]
FamilyTree Load (1.9ms) SELECT "family_trees".* FROM "family_trees" WHERE "family_trees"."id" = $1 LIMIT 1 [["id", 2]]
Node Load (1.4ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."family_tree_id" = $1 [["family_tree_id", 2]]
Rendered nodes/_form.html.erb (13.0ms)
Rendered nodes/edit.html.erb within layouts/application (14.0ms)
Completed 500 Internal Server Error in 19ms
TypeError - no implicit conversion of nil into Array:
That is on this line in the _form.html.erb partial:
<%= f.input :parents, collection: (#node.family_tree.nodes - #node.parents - [#node]).uniq, label: "Parent 1" %>
I have Better Errors installed, so when I dig into it, what is happening is #node.parents is being returned as nil. Likewise, so does #node.parent, #node.parent_ids, #node.parent_id. None of which should be returning as nil.
The weird thing is that if I fire up the console at this point and check those values I don't get nil, I get the legit values:
[1] pry(main)> n = Node.find(35)
Node Load (0.7ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 35]]
=> #<Node id: 35, family_tree_id: 2, created_at: "2015-01-28 23:17:36", updated_at: "2015-01-28 23:17:36", name: "Testy", ancestry: "13", ancestry_depth: 0, max_tree_depth: 0>
[2] pry(main)> n.parents
Node Load (0.4ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 13]]
=> [#<Node id: 13, family_tree_id: 2, created_at: "2015-01-17 23:18:46", updated_at: "2015-01-17 23:18:46", name: "Jack", ancestry: nil, ancestry_depth: 0, max_tree_depth: 0>]
Once I restart the server, and change nothing in the DB, it all works:
Started POST "/__better_errors/7243596af02cef24/eval" for 127.0.0.1 at 2015-02-06 19:33:01 -0500
^CStopping ...
Exiting
MGs-Puter:ancestry_app $ rails s
Please require the stackprof gem falling back to fast_stack
=> Booting Thin
=> Rails 4.1.6 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Notice: server is listening on all interfaces (0.0.0.0). Consider using 127.0.0.1 (--binding option)
=> Ctrl-C to shutdown server
Thin web server (v1.6.3 codename Protein Powder)
Maximum connections set to 1024
Listening on 0.0.0.0:3000, CTRL+C to stop
Started GET "/nodes/35/edit" for 127.0.0.1 at 2015-02-06 20:01:59 -0500
ActiveRecord::SchemaMigration Load (1.8ms) SELECT "schema_migrations".* FROM "schema_migrations"
Processing by NodesController#edit as HTML
Parameters: {"id"=>"35"}
Node Load (1.1ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 35]]
FamilyTree Load (5.7ms) SELECT "family_trees".* FROM "family_trees" WHERE "family_trees"."id" = $1 LIMIT 1 [["id", 2]]
Node Load (1.4ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 13]]
Node Load (1.3ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."family_tree_id" = $1 [["family_tree_id", 2]]
CACHE (0.0ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 13]]
CACHE (0.0ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 13]]
CACHE (0.4ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 13]]
CACHE (0.0ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 13]]
CACHE (0.0ms) SELECT "nodes".* FROM "nodes" WHERE "nodes"."id" = $1 LIMIT 1 [["id", 13]]
FamilyTree Load (37.4ms) SELECT "family_trees".* FROM "family_trees"
Rendered nodes/_form.html.erb (220.5ms)
Rendered nodes/edit.html.erb within layouts/application (264.4ms)
User Load (8.9ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 ORDER BY "users"."id" ASC LIMIT 1
Completed 200 OK in 790ms (Views: 680.5ms | ActiveRecord: 80.0ms)
This is my NodesController#Update:
def update
#node.update(node_params)
respond_with(#node)
end
private
def set_node
#node = Node.find(params[:id])
end
def node_params
params.require(:node).permit(:user_id, :family_tree_id, :name, :description, :parent_id, :parent, :parents)
end
What could be causing this weird behavior? Not sure if it matters, but I am using a local forked version of the ancestry gem - that I am modifying - to set & check the parents value.
Edit 1
This is my NodeController#Edit:
def edit
end
Edit 2
Before action at the top of my NodesController:
before_action :set_node, only: [:show, :edit, :update, :destroy]