docbrown/docs/internal
Andy Zhao 955bdcb2bc
Update docs with Forem instead of dev.to (#9316)
* Rename all GitHub links from thepracticaldev/dev.to to forem/forem

* Use new site name

* Rename to Forem

* Rename more dev.to to forem

* Remove unnecessary redirects

* Rename DEV to Forem

* Use Forem instead of DEV for branding

* Use Forem instead of DEV for licensing

* Use seedling instead of DEV logo
2020-07-15 13:29:11 -04:00
..
internal-search.md Update docs with Forem instead of dev.to (#9316) 2020-07-15 13:29:11 -04:00
internal-user-interface.md Update docs with Forem instead of dev.to (#9316) 2020-07-15 13:29:11 -04:00
readme.md Update docs with Forem instead of dev.to (#9316) 2020-07-15 13:29:11 -04:00

title items
Internal Guide
internal-search.md
internal-user-interface.md

Internal Guide

The Forem application contains a rudimentary administration dashboard that lives behind the internal route.

The internal dashboard is made up of a series of views that range from administration tools to simplified reports. These tools are used by users with the admin or super_admin roles to administrate the Forem application.

Authorization for these tools is handled by the Rolify gem.

Currently, a workaround exists to give access to certain internal views via Rolify by assigning the role single_resource_admin to a user.

single_resource_admin users are given access to a Ruby class. In the codebase, there are internal models, not backed by database tables, that exist for this purpose. For example, if you needed to give a user access to only /internal/welcome, you'd run the following command in the Rails console:

user = User.find(some_user_id)
user.add_role :single_resource_admin, Welcome

This gives the user administration privileges on the controller associated with an almost empty Rails model that lives in app/models/internal/welcome.rb:

class Welcome < ApplicationRecord
  resourcify
  # This class exists to take advantage of Rolify for limiting authorization
  # on internal reports.
  # NOTE: It is not backed by a database table and should not be expected to
  # function like a traditional Rails model
end

Now that user will be able to access the view at internal/welcome. The same workaround has been implemented for most of the internal views.