@braindeaf I've handled that with an id translation in the users controller like:
class UsersController < BaseController
before_action :convert_me_id
def convert_me_id
if params[:id] && params[:id].casecmp('me') == 0
params[:id] = context[:current_user].id
context[:me] = true
end
end
end
This just uses the UserResource and not a MeResource. You could modify the params or the context in the case of an id using me
to alter the response. The methods like fetchable_fields
, updatable_fields
all have access to the context either as an argument or on the resource instance.
def _replace_to_many_links(relationship_type, relationship_key_values, options)
if relationship_type == :user_groups && @model.user_groups.any?
fail JSONAPI::Exceptions::ToManySetReplacementForbidden.new(detail: 'User already has user group(s) assigned.')
end
super(relationship_type, relationship_key_values, options)
end
downcase' for nil:NilClass ruby-2.7.2@manager-ruby272/gems/jsonapi-resources-0.10.4/lib/jsonapi/relationship.rb:66:in
block (3 levels) in polymorphic_types'each'
/Users/anujp/.rvm/gems/ruby-2.7.2@manager-ruby272/gems/jsonapi-resources-0.10.4/lib/jsonapi/relationship.rb:65:in
block (2 levels) in polymorphic_types'
Is it no longer possible to inherit from JSONAPI::ResourceController
in 0.10.4 on rails 6.0? I'm working on an upgrade from rails 5.2, but I'm also experiencing the same problem if I create a new app following the docs. Whenever I make a request I get the error:
#<NameError: uninitialized constant JSONAPI::ResourceController
Did you mean? JSONAPI::ResourceControllerMetal>
Tried setting config.autoloader = :classic
but that didn't change anything.
I've been able to work around this by using:
class MyController < ActionController::Base
include JSONAPI::ActsAsResourceController
end
This is the only relevant commit that I've been able to find so far that might be causing this
Thanks! (I'm on ruby 2.7.2)
class Api::V1::TagAssociationResource < JSONAPI::Resource
model_name 'TagAssociation'
attributes :tag_id, :tag_type_id, :taggable_id, :taggable_type, :time_range_appointment_id
# def self.creatable_fields(_context)
# super - [:time_range_appointment_id]
# end
before_save do
if !@model.taggable && @model.time_range_appointment_id.present?
time_range = TimeRange.find_by(appointment_id: @model.time_range_appointment_id)
@model.taggable = time_range
end
end
end
Response body: {"errors":[{"title":"Param not allowed","detail":"time_range_appointment_id is not allowed.","code":"105","status":"400"}]}
class Api::V1::TagAssociationResource < JSONAPI::Resource
model_name 'TagAssociation'
attributes :tag_id, :tag_type_id, :taggable_id, :taggable_type, :time_range_appointment_id
def time_range_appointment_id=(val)
@time_range_appointment_id = val
end
def time_range_appointment_id
nil
end
def self.fetchable_fields(_context)
super - [:time_range_appointment_id]
end
before_save do
if !@model.taggable && @time_range_appointment_id.present?
time_range = TimeRange.find_by(appointment_id: @time_range_appointment_id)
@model.taggable = time_range
end
end
end
Hi all! What would be the best way to define an attribute on each of a resource's records just before returning it? The use case is to mark resources as "recommended" on the fly. I've tried to override the records
method as such:
def self.records(options = {})
objects = super
# sets the attr_accessor `recommended = true` on the model
Recommender.new(context[:current_team]).mark_recommended(objects)
objects
end
This doesn't work though, the response still shows recommended: nil
. From what I've dug so far we lose this attribute somewhere during resource_klass.sort_records
in apply_request_settings_to_records
of ActiveRelationResource
def self.fetchable_fields(_context)
super - [:time_range_appointment_id]
end
config.top_level_meta_record_count_key = :record_count
, and I get a meta
object at the top level with a record count, but it seems to return the full count of the model rather than the full count after filters. Is this as designed? Do I need to implement my own processor? I would think so except the processors documentation for v0.9 says that would be redundant, if I'm reading it right. (I'm using v0.10 but there are no docs for processors for that version)