There are currently some problems with namespaced models and policies, especially in engine installs.
ResourceService#resource_class_name runs demodulize on the class name. That means if you have an Admin::Article model, the Admin::ArticleService will not find it, because it will resolve to ::Article instead.
Similarly, the PolicyFinder adds the namespace twice for namespaced models in engine installs. Admin::Article would resolve to Admin::Admin::ArticlePolicy.
The current solution is to override resource_class_name in Admin::ArticleService and override policy_class in Admin::Article.
We've toyed with the idea of having engine installs expect models to be in the engine, as opposed to the main app. This could be done by removing demodulize in ResourceService#resource_class_name. While this would simplify some things, and make it consistent with how non-engine installs work, it would require engine installs to define a model for each service object, even if these only inherit from the main app model. This would increase the number of files, unless the constants could be dynamically defined somehow.
There are currently some problems with namespaced models and policies, especially in engine installs.
ResourceService#resource_class_name
runsdemodulize
on the class name. That means if you have anAdmin::Article
model, theAdmin::ArticleService
will not find it, because it will resolve to::Article
instead.Similarly, the
PolicyFinder
adds the namespace twice for namespaced models in engine installs.Admin::Article
would resolve toAdmin::Admin::ArticlePolicy
.The current solution is to override
resource_class_name
inAdmin::ArticleService
and overridepolicy_class
inAdmin::Article
.We've toyed with the idea of having engine installs expect models to be in the engine, as opposed to the main app. This could be done by removing
demodulize
inResourceService#resource_class_name
. While this would simplify some things, and make it consistent with how non-engine installs work, it would require engine installs to define a model for each service object, even if these only inherit from the main app model. This would increase the number of files, unless the constants could be dynamically defined somehow.Also consider migrating to Pundit.