Link_to путь для объекта в другой модели

Ресурс tracker вложен не в goal, а в contacts. Путь goal_tracker_path (eg: /goals/1/trackers/1) не существует. Существует только contact_tracker_path. Вы можете увидеть это, если побежите rails routes.

Есть несколько способов сделать это.

• Откажитесь от гнездования. Но у этого не будет вложенной структуры URL. Путь будет /trackers/id. Ссылка на будет выглядеть примерно так

link_to 'Title', tracker

• Ресурс трекера Nest также подходит к цели. В этом случае и goal_tracker_path, и contact_tracker_path будут доступны, хотя оба будут использовать один и тот же TrackersController. Вы всегда можете написать другой контроллер и указать его в маршрутах, если это необходимо. Маршруты будут выглядеть примерно так

resources :contacts do
    resources :trackers do
      resources :emails
    end
  end
  resources :goals do
      resources :trackers
      resources :stages do
        resources :templates
      end
  end

• Или вы можете просто переместить ресурс трекера в ресурс целей, если вам также не понадобится contact_tracker_path.

Лучше всегда смотреть на rails routes, чтобы убедиться, что путь существует.

Трекеры вложены ниже контрактов. Поэтому нужно передать контракт, к которому принадлежит трекер, тоже в метод link_to:

<% @goal.trackers.each do |tracker| %>
  <hr />
  <%= link_to [tracker.contact, tracker] do %>            
    <p><%= tracker.title %> | <%= tracker.contact.first_name %></p>
  <% end %>
<% end %>

Или вы можете подумать о том, чтобы не использовать вложенность в своих маршрутах так часто. Официальные руководства Rails предлагают Shallow Nesting вместо вложенных маршрутов.

Основная проблема в том, что вы на самом деле не вкладываете ресурс trackers в goals.

Для этого вам понадобится:

resources :contacts do
  resources :trackers
  # ...
end

resources :goals do
  resources :trackers
  # ...
end

Здесь и /contacts/1/trackers, и /goals/1/trackers перейдут к методу TrackersContoller#index. Один из распространенных способов справиться с этим - это то, что я называю "методом прослушивания параметров":

class TrackersContoller
  # GET /contacts/1/trackers
  # GET /goals/1/trackers
  # GET /trackers
  def index
    if params[:contact_id].present?
      @trackers = Contact.find(params[:contact_id]).trackers
    elsif params[:goal_id].present?
      @trackers = Goal.find(params[:contact_id]).trackers
    else
      @trackers = Tracker.all
    end
  end
 
  # ...
end

Что чертовски вонюче с точки зрения принципа единой ответственности, поскольку контроллер теперь обрабатывает три разных варианта ресурса RESTful.

Обычно я предпочитаю направлять вложенные представления ресурса на их собственный контроллер:

resources :trackers # TrackerController

resources :contacts do
  # routes to Contacts::TrackerContoller
  resources :trackers, only: [:new, :create, :index], 
                       module: :contacts
  # ...
end

resources :goals do
  # routes to Goals::TrackerContoller
  resources :trackers, only: [:new, :create, :index], 
                       module: :contacts
  # ...
end

module Contacts
  # Creates and lists trackers belonging to a Contact
  class TrackersContoller < ApplicationController
    # GET /contacts/1/trackers
    def index
      Contact.find(params[:contact_id]).trackers
    end
  end
end

module Goals
  # Creates and lists trackers belonging to a Goal
  class TrackersContoller < ApplicationController
    # GET /goals/1/trackers
    def index
      Goal.find(params[:goal_id]).trackers
    end
  end
end

Кроме того, прежде чем вы сойдете с ума, создавая схему русской куклы, вам, вероятно, следует прочитать классический пост Джеймиса Бака о том, почему глубокая вложенность — это плохо:

Эмпирическое правило: ресурсы никогда не должны быть вложены более чем на 1 уровень. глубокий. Коллекция может нуждаться в том, чтобы ее область действия была определена ее родителем, но конкретная член всегда может быть доступен непосредственно по идентификатору и не должен нуждаться область видимости (если только идентификатор по какой-то причине не уникален).

Кодекс может быть сильно устаревшим, но основные принципы так же актуальны, как и 15 лет назад. Это также рекомендуется руководствами Rails.