{"id":13631829,"url":"https://github.com/activeadmin/inherited_resources","last_synced_at":"2025-05-13T20:06:28.862Z","repository":{"id":495214,"uuid":"121828","full_name":"activeadmin/inherited_resources","owner":"activeadmin","description":null,"archived":false,"fork":false,"pushed_at":"2025-04-29T07:53:24.000Z","size":1355,"stargazers_count":2703,"open_issues_count":1,"forks_count":387,"subscribers_count":46,"default_branch":"master","last_synced_at":"2025-04-29T15:05:35.692Z","etag":null,"topics":["rails"],"latest_commit_sha":null,"homepage":"","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/activeadmin.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":".github/FUNDING.yml","license":"MIT-LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null},"funding":{"tidelift":"rubygems/inherited_resources"}},"created_at":"2009-02-04T21:11:19.000Z","updated_at":"2025-04-29T07:53:28.000Z","dependencies_parsed_at":"2023-10-14T23:10:16.721Z","dependency_job_id":"3922eb66-834f-4097-829a-7b7a21dea3c7","html_url":"https://github.com/activeadmin/inherited_resources","commit_stats":{"total_commits":943,"total_committers":117,"mean_commits":8.05982905982906,"dds":0.7635206786850477,"last_synced_commit":"bce170cf6dbaf29f409631ebe54a3c5f8e877204"},"previous_names":["josevalim/inherited_resources"],"tags_count":35,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/activeadmin%2Finherited_resources","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/activeadmin%2Finherited_resources/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/activeadmin%2Finherited_resources/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/activeadmin%2Finherited_resources/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/activeadmin","download_url":"https://codeload.github.com/activeadmin/inherited_resources/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":251663340,"owners_count":21623882,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["rails"],"created_at":"2024-08-01T22:02:39.955Z","updated_at":"2025-05-06T01:56:30.948Z","avatar_url":"https://github.com/activeadmin.png","language":"Ruby","readme":"## Notice\n\nInherited Resources is no longer actively maintained by the original author and\nhas been transferred to the ActiveAdmin organization for maintenance.  New feature\nrequests are not encouraged.\n\nIf you are not already using Inherited Resources we suggest instead using Rails'\n`respond_with` feature alongside the [responders gem](https://github.com/heartcombo/responders).\n\n## Inherited Resources\n\n[![Version         ][rubygems_badge]][rubygems]\n[![Github Actions  ][actions_badge]][actions]\n[![Tidelift        ][tidelift_badge]][tidelift]\n\nInherited Resources speeds up development by making your controllers inherit\nall restful actions so you just have to focus on what is important. It makes\nyour controllers more powerful and cleaner at the same time.\n\nIn addition to making your controllers follow a pattern, it helps you to write better\ncode by following fat models and skinny controllers convention. There are\ntwo screencasts available besides this README:\n\n* http://railscasts.com/episodes/230-inherited-resources\n* https://www.akitaonrails.com/2009/09/01/screencast-real-thin-restful-controllers-with-inherited-resources\n\n## Installation\n\nYou can let bundler install Inherited Resources by adding this line to your application's Gemfile:\n\n```ruby\ngem 'inherited_resources'\n```\n\nAnd then execute:\n\n```sh\n$ bundle install\n```\n\nOr install it yourself with:\n\n```sh\n$ gem install inherited_resources\n```\n\n## HasScope\n\nSince Inherited Resources 1.0, has_scope is not part of its core anymore but\na gem dependency. Be sure to check the documentation to see how you can use it:\n\n- \u003chttps://github.com/heartcombo/has_scope\u003e\n\nAnd it can be installed as:\n\n```sh\n$ gem install has_scope\n```\n\n## Responders\n\nSince Inherited Resources 1.0, responders are not part of its core anymore,\nbut is set as Inherited Resources dependency and it's used by default by\nInheritedResources controllers. Be sure to check the documentation to see\nhow it will change your application:\n\n- \u003chttps://github.com/heartcombo/responders\u003e\n\nAnd it can be installed with:\n\n```sh\n$ gem install responders\n```\n\nUsing responders will set the flash message to :notice and :alert. You can change\nthat through the following configuration value:\n\n```ruby\nInheritedResources.flash_keys = [ :success, :failure ]\n```\n\nNotice the CollectionResponder won't work with InheritedResources, as\nInheritedResources hardcodes the redirect path based on the current scope (like\nbelongs to, polymorphic associations, etc).\n\n## Basic Usage\n\nTo use Inherited Resources you just have to inherit (duh) it:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\nend\n```\n\nAnd all actions are defined and working, check it! Your projects collection\n(in the index action) is still available in the instance variable `@projects`\nand your project resource (all other actions) is available as `@project`.\n\nThe next step is to define which mime types this controller provides:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  respond_to :html, :xml, :json\nend\n```\n\nYou can also specify them per action:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  respond_to :html, :xml, :json\n  respond_to :js, :only =\u003e :create\n  respond_to :iphone, :except =\u003e [ :edit, :update ]\nend\n```\n\nFor each request, it first checks if the \"controller/action.format\" file is\navailable (for example \"projects/create.xml\") and if it's not, it checks if\nthe resource respond to :to_format (in this case, `:to_xml`). Otherwise returns 404.\n\nAnother option is to specify which actions the controller will inherit from\nthe `InheritedResources::Base`:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  actions :index, :show, :new, :create\nend\n```\n\nOr:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  actions :all, :except =\u003e [ :edit, :update, :destroy ]\nend\n```\n\nIn your views, you will get the following helpers:\n\n```ruby\nresource        #=\u003e @project\ncollection      #=\u003e @projects\nresource_class  #=\u003e Project\n```\n\nAs you might expect, collection (`@projects` instance variable) is only available\non index actions.\n\nIf for some reason you cannot inherit from `InheritedResources::Base`, you can\ncall inherit_resources in your controller class scope:\n\n```ruby\nclass AccountsController \u003c ApplicationController\n  inherit_resources\nend\n```\n\nOne reason to use the `inherit_resources` macro would be to ensure that your controller\nnever responds with the html mime-type. `InheritedResources::Base` already\nresponds to `:html`, and the `respond_to` macro is strictly additive.\nTherefore, if you want to create a controller that, for example, responds ONLY via `:js`,\nyou will have to write it this way:\n\n```ruby\nclass AccountsController \u003c ApplicationController\n  respond_to :js\n  inherit_resources\nend\n```\n\nBy default, `InheritedResources::Base` will inherit from `::ApplicationController`. You can change this in a rails initializer:\n\n```ruby\n# config/initializers/inherited_resources.rb\nInheritedResources.parent_controller = 'MyController'\n```\n\n## Overwriting defaults\n\nWhenever you inherit from InheritedResources, several defaults are assumed.\nFor example you can have an `AccountsController` for account management while the\nresource is a `User`:\n\n```ruby\nclass AccountsController \u003c InheritedResources::Base\n  defaults :resource_class =\u003e User, :collection_name =\u003e 'users', :instance_name =\u003e 'user'\nend\n```\n\nIn the case above, in your views you will have `@users` and `@user` variables, but\nthe routes used will still be `accounts_url` and `account_url`. If you plan also to\nchange the routes, you can use `:route_collection_name` and `:route_instance_name`.\n\nNamespaced controllers work out of the box, but if you need to specify a\ndifferent route prefix you can do the following:\n\n```ruby\nclass Administrators::PeopleController \u003c InheritedResources::Base\n  defaults :route_prefix =\u003e :admin\nend\n```\n\nThen your named routes will be: `admin_people_url`, `admin_person_url` instead\nof `administrators_people_url` and `administrators_person_url`.\n\nIf you want to customize how resources are retrieved you can overwrite\ncollection and resource methods. The first is called on index action and the\nsecond on all other actions. Let's suppose you want to add pagination to your\nprojects collection:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  protected\n    def collection\n      get_collection_ivar || set_collection_ivar(end_of_association_chain.paginate(:page =\u003e params[:page]))\n    end\nend\n```\n\nThe `end_of_association_chain` returns your resource after nesting all associations\nand scopes (more about this below).\n\nInheritedResources also introduces another method called `begin_of_association_chain`.\nIt's mostly used when you want to create resources based on the `@current_user` and\nyou have urls like \"account/projects\". In such cases you have to do\n`@current_user.projects.find` or `@current_user.projects.build` in your actions.\n\nYou can deal with it just by doing:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  protected\n    def begin_of_association_chain\n      @current_user\n    end\nend\n```\n\n## Overwriting actions\n\nLet's suppose that after destroying a project you want to redirect to your\nroot url instead of redirecting to projects url. You just have to do:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  def destroy\n    super do |format|\n      format.html { redirect_to root_url }\n    end\n  end\nend\n```\n\nYou are opening your action and giving the parent action a new behavior. On\nthe other hand, I have to agree that calling super is not very readable. That's\nwhy all methods have aliases. So this is equivalent:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  def destroy\n    destroy! do |format|\n      format.html { redirect_to root_url }\n    end\n  end\nend\n```\n\nSince most of the time when you change a create, update or destroy\naction you do so because you want to change its redirect url, a shortcut is\nprovided. So you can do:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  def destroy\n    destroy! { root_url }\n  end\nend\n```\n\nIf you simply want to change the flash message for a particular action, you can\npass the message to the parent action using the keys `:notice` and `:alert` (as you\nwould with flash):\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  def create\n    create!(:notice =\u003e \"Dude! Nice job creating that project.\")\n  end\nend\n```\n\nYou can still pass the block to change the redirect, as mentioned above:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  def create\n    create!(:notice =\u003e \"Dude! Nice job creating that project.\") { root_url }\n  end\nend\n```\n\nNow let's suppose that before create a project you have to do something special\nbut you don't want to create a before filter for it:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  def create\n    @project = Project.new(params[:project])\n    @project.something_special!\n    create!\n  end\nend\n```\n\nYes, it's that simple! The nice part is since you already set the instance variable\n`@project`, it will not build a project again.\n\nSame goes for updating the project:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  def update\n    @project = Project.find(params[:id])\n    @project.something_special!\n    update!\n  end\nend\n```\n\nBefore we finish this topic, we should talk about one more thing: \"success/failure\nblocks\". Let's suppose that when we update our project, in case of failure, we\nwant to redirect to the project url instead of re-rendering the edit template.\n\nOur first attempt to do this would be:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  def update\n    update! do |format|\n      unless @project.errors.empty? # failure\n        format.html { redirect_to project_url(@project) }\n      end\n    end\n  end\nend\n```\n\nLooks too verbose, right? We can actually do:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  def update\n    update! do |success, failure|\n      failure.html { redirect_to project_url(@project) }\n    end\n  end\nend\n```\n\nMuch better! So explaining everything: when you give a block which expects one\nargument it will be executed in both scenarios: success and failure. But if you\ngive a block that expects two arguments, the first will be executed only in\nsuccess scenarios and the second in failure scenarios. You keep everything\nclean and organized inside the same action.\n\n## Smart redirects\n\nAlthough the syntax above is a nice shortcut, you won't need to do it frequently\nbecause (since version 1.2) Inherited Resources has smart redirects. Redirects\nin actions calculates depending on the existent controller methods.\n\nRedirects in create and update actions calculates in the following order: `resource_url`,\n`collection_url`, `parent_url` (which we are going to see later), and `root_url`. Redirect\nin destroy action calculate in following order `collection_url`, `parent_url`, `root_url`.\n\nExample:\n\n```ruby\nclass ButtonsController \u003c InheritedResources::Base\n  belongs_to :window\n  actions :all, :except =\u003e [:show, :index]\nend\n```\n\nThis controller redirect to parent window after all CUD actions.\n\n## Success and failure scenarios on destroy\n\nThe destroy action can also fail, this usually happens when you have a\n`before_destroy` callback in your model which returns false. However, in\norder to tell InheritedResources that it really failed, you need to add\nerrors to your model. So your `before_destroy` callback on the model should\nbe something like this:\n\n```ruby\ndef before_destroy\n  if cant_be_destroyed?\n    errors.add(:base, \"not allowed\")\n    false\n  end\nend\n```\n\n## Belongs to\n\nFinally, our Projects are going to get some Tasks. Then you create a\n`TasksController` and do:\n\n```ruby\nclass TasksController \u003c InheritedResources::Base\n  belongs_to :project\nend\n```\n\n`belongs_to` accepts several options to be able to configure the association.\nFor example, if you want urls like \"/projects/:project_title/tasks\", you can\ncustomize how InheritedResources find your projects:\n\n```ruby\nclass TasksController \u003c InheritedResources::Base\n  belongs_to :project, :finder =\u003e :find_by_title!, :param =\u003e :project_title\nend\n```\n\nIt also accepts `:route_name`, `:parent_class` and `:instance_name` as options.\nCheck the [lib/inherited_resources/class_methods.rb](https://github.com/activeadmin/inherited_resources/blob/master/lib/inherited_resources/class_methods.rb)\nfor more.\n\n## Nested belongs to\n\nNow, our Tasks get some Comments and you need to nest even deeper. Good\npractices says that you should never nest more than two resources, but sometimes\nyou have to for security reasons. So this is an example of how you can do it:\n\n```ruby\nclass CommentsController \u003c InheritedResources::Base\n  nested_belongs_to :project, :task\nend\n```\n\nIf you need to configure any of these belongs to, you can nest them using blocks:\n\n```ruby\nclass CommentsController \u003c InheritedResources::Base\n  belongs_to :project, :finder =\u003e :find_by_title!, :param =\u003e :project_title do\n    belongs_to :task\n  end\nend\n```\n\nWarning: calling several `belongs_to` is the same as nesting them:\n\n```ruby\nclass CommentsController \u003c InheritedResources::Base\n  belongs_to :project\n  belongs_to :task\nend\n```\n\nIn other words, the code above is the same as calling `nested_belongs_to`.\n\n## Polymorphic belongs to\n\nWe can go even further. Let's suppose our Projects can now have Files, Messages\nand Tasks, and they are all commentable. In this case, the best solution is to\nuse polymorphism:\n\n```ruby\nclass CommentsController \u003c InheritedResources::Base\n  belongs_to :task, :file, :message, :polymorphic =\u003e true\n  # polymorphic_belongs_to :task, :file, :message\nend\n```\n\nYou can even use it with nested resources:\n\n```ruby\nclass CommentsController \u003c InheritedResources::Base\n  belongs_to :project do\n    belongs_to :task, :file, :message, :polymorphic =\u003e true\n  end\nend\n```\n\nThe url in such cases can be:\n\n```\n/project/1/task/13/comments\n/project/1/file/11/comments\n/project/1/message/9/comments\n```\n\nWhen using polymorphic associations, you get some free helpers:\n\n```ruby\nparent?         #=\u003e true\nparent_type     #=\u003e :task\nparent_class    #=\u003e Task\nparent          #=\u003e @task\n```\n\nRight now, Inherited Resources is limited and does not allow you\nto have two polymorphic associations nested.\n\n## Optional belongs to\n\nLater you decide to create a view to show all comments, independent if they belong\nto a task, file or message. You can reuse your polymorphic controller just doing:\n\n```ruby\nclass CommentsController \u003c InheritedResources::Base\n  belongs_to :task, :file, :message, :optional =\u003e true\n  # optional_belongs_to :task, :file, :message\nend\n```\n\nThis will handle all those urls properly:\n\n```\n/comment/1\n/tasks/2/comment/5\n/files/10/comment/3\n/messages/13/comment/11\n```\n\nThis is treated as a special type of polymorphic associations, thus all helpers\nare available. As you expect, when no parent is found, the helpers return:\n\n```ruby\nparent?         #=\u003e false\nparent_type     #=\u003e nil\nparent_class    #=\u003e nil\nparent          #=\u003e nil\n```\n\n## Singletons\n\nNow we are going to add manager to projects. We say that `Manager` is a singleton\nresource because a `Project` has just one manager. You should declare it as\n`has_one` (or resource) in your routes.\n\nTo declare an resource of current controller  as singleton, you just have to give the\n`:singleton` option in defaults.\n\n```ruby\nclass ManagersController \u003c InheritedResources::Base\n  defaults :singleton =\u003e true\n  belongs_to :project\n  # singleton_belongs_to :project\nend\n```\n\nSo now you can use urls like \"/projects/1/manager\".\n\nIn the case of nested resources (when some of the can be singletons) you can declare it separately\n\n```ruby\nclass WorkersController \u003c InheritedResources::Base\n  #defaults :singleton =\u003e true #if you have only single worker\n  belongs_to :project\n  belongs_to :manager, :singleton =\u003e true\nend\n```\n\nThis is correspond urls like \"/projects/1/manager/workers/1\".\n\nIt will deal with everything again and hide the action :index from you.\n\n## Namespaced Controllers\n\nNamespaced controllers works out the box.\n\n```ruby\nclass Forum::PostsController \u003c InheritedResources::Base\nend\n```\n\nInherited Resources prioritizes the default resource class for the namespaced controller in\nthis order:\n\n```\nForum::Post\nForumPost\nPost\n```\n\n## URL Helpers\n\nWhen you use InheritedResources it creates some URL helpers.\nAnd they handle everything for you. :)\n\n```ruby\n# /posts/1/comments\nresource_url               # =\u003e /posts/1/comments/#{@comment.to_param}\nresource_url(comment)      # =\u003e /posts/1/comments/#{comment.to_param}\nnew_resource_url           # =\u003e /posts/1/comments/new\nedit_resource_url          # =\u003e /posts/1/comments/#{@comment.to_param}/edit\nedit_resource_url(comment) # =\u003e /posts/1/comments/#{comment.to_param}/edit\ncollection_url             # =\u003e /posts/1/comments\nparent_url                 # =\u003e /posts/1\n\n# /projects/1/tasks\nresource_url               # =\u003e /projects/1/tasks/#{@task.to_param}\nresource_url(task)         # =\u003e /projects/1/tasks/#{task.to_param}\nnew_resource_url           # =\u003e /projects/1/tasks/new\nedit_resource_url          # =\u003e /projects/1/tasks/#{@task.to_param}/edit\nedit_resource_url(task)    # =\u003e /projects/1/tasks/#{task.to_param}/edit\ncollection_url             # =\u003e /projects/1/tasks\nparent_url                 # =\u003e /projects/1\n\n# /users\nresource_url               # =\u003e /users/#{@user.to_param}\nresource_url(user)         # =\u003e /users/#{user.to_param}\nnew_resource_url           # =\u003e /users/new\nedit_resource_url          # =\u003e /users/#{@user.to_param}/edit\nedit_resource_url(user)    # =\u003e /users/#{user.to_param}/edit\ncollection_url             # =\u003e /users\nparent_url                 # =\u003e /\n```\n\nThose urls helpers also accepts a hash as options, just as in named routes.\n\n```ruby\n# /projects/1/tasks\ncollection_url(:page =\u003e 1, :limit =\u003e 10) #=\u003e /projects/1/tasks?page=1\u0026limit=10\n```\n\nIn polymorphic cases, you can also give the parent as parameter to `collection_url`.\n\nAnother nice thing is that those urls are not guessed during runtime. They are\nall created when your application is loaded (except for polymorphic\nassociations, that relies on Rails' `polymorphic_url`).\n\n## Custom actions\n\nSince version 1.2, Inherited Resources allows you to define custom actions in controller:\n\n```ruby\nclass ButtonsController \u003c InheritedResources::Base\n  custom_actions :resource =\u003e :delete, :collection =\u003e :search\nend\n```\n\nThis code creates delete and search actions in controller (they behaves like show and\nindex actions accordingly). Also, it will produce `delete_resource_{path,url}` and\n`search_resources_{path,url}` url helpers.\n\n## What about views?\n\nSometimes just DRYing up the controllers is not enough. If you need to DRY up your views,\ncheck this Wiki page:\n\nhttps://github.com/activeadmin/inherited_resources/wiki/Views-Inheritance\n\n\nNotice that Rails 3.1 ships with view inheritance built-in.\n\n## Some DSL\n\nFor those DSL lovers, InheritedResources won't leave you alone. You can overwrite\nyour success/failure blocks straight from your class binding. For it, you just\nneed to add a DSL module to your application controller:\n\n```ruby\nclass ApplicationController \u003c ActionController::Base\n  include InheritedResources::DSL\nend\n```\n\nAnd then you can rewrite the last example as:\n\n```ruby\nclass ProjectsController \u003c InheritedResources::Base\n  update! do |success, failure|\n    failure.html { redirect_to project_url(@project) }\n  end\nend\n```\n\n## Strong Parameters\n\nIf your controller defines a method named `permitted_params`, InheritedResources\nwill call it where it would normally call params. This allows for easy\nintegration with the strong_parameters gem:\n\n```ruby\ndef permitted_params\n  params.permit(:widget =\u003e [:permitted_field, :other_permitted_field])\nend\n```\n\nRemember that if your field is sent by client to server as an array, you have to write `:permitted_field =\u003e []`, not just `:permitted_field`.\n\nNote that this doesn't work if you use strong_parameters' require method\ninstead of permit, because whereas permit returns the entire sanitized\nparameter hash, require returns only the sanitized params below the parameter\nyou required.\n\nIf you need `params.require` you can do it like this:\n\n```ruby\ndef permitted_params\n  {:widget =\u003e params.fetch(:widget, {}).permit(:permitted_field, :other_permitted_field)}\nend\n```\n\nOr better yet just override `#build_resource_params` directly:\n\n```ruby\ndef build_resource_params\n  [params.fetch(:widget, {}).permit(:permitted_field, :other_permitted_field)]\nend\n```\n\n\nInstead you can stick to a standard Rails 4 notation (as rails scaffold generates) and write:\n\n```ruby\ndef widget_params\n  params.require(:widget).permit(:permitted_field, :other_permitted_field)\nend\n```\n\nIn such case you should remove #permitted_params method because it has greater priority.\n\n## Funding\n\nIf you want to support us financially, you can [help fund the project\nthrough a Tidelift subscription][tidelift]. By buying a Tidelift subscription\nyou make sure your whole dependency stack is properly maintained, while also\ngetting a comprehensive view of outdated dependencies, new releases, security\nalerts, and licensing compatibility issues.\n\n## Bugs and Feedback\n\nIf you discover any bugs, please describe it in the issues tracker, including Rails and InheritedResources versions.\n\nQuestions are better handled on StackOverflow.\n\nMIT License. Copyright (c) 2009-2017 José Valim.\n\n## Security contact information\n\nPlease use the Tidelift security contact to [report a security vulnerability][Tidelift security contact].\nTidelift will coordinate the fix and disclosure.\n\n[rubygems_badge]: https://img.shields.io/gem/v/inherited_resources.svg\n[rubygems]: https://rubygems.org/gems/inherited_resources\n[actions_badge]: https://github.com/activeadmin/inherited_resources/workflows/ci/badge.svg\n[actions]: https://github.com/activeadmin/inherited_resources/actions\n[tidelift_badge]: https://tidelift.com/badges/package/rubygems/inherited_resources?style=flat\n[tidelift]: https://tidelift.com/subscription/pkg/rubygems-inherited-resources?utm_source=rubygems-inherited-resources\u0026utm_medium=referral\u0026utm_campaign=readme\n\n[Tidelift security contact]: https://tidelift.com/security\n","funding_links":["https://tidelift.com/funding/github/rubygems/inherited_resources","https://tidelift.com/badges/package/rubygems/inherited_resources?style=flat","https://tidelift.com/subscription/pkg/rubygems-inherited-resources?utm_source=rubygems-inherited-resources\u0026utm_medium=referral\u0026utm_campaign=readme","https://tidelift.com/security"],"categories":["Ruby"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Factiveadmin%2Finherited_resources","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Factiveadmin%2Finherited_resources","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Factiveadmin%2Finherited_resources/lists"}