-
Notifications
You must be signed in to change notification settings - Fork 0
Special functions
There are a couple of special functions that can be utilised in order to ease specific tasks that are commonly needed.
Provides a simple base for exporting different data to csv files compatible with Microsoft Excel.
Used to report more critical faults to the server administrators. Errors will be reported to a preconfigured e-mail address.
FaultReport.send('Custom error message')
Edit the default to
e-mail in app/mailers/fault_mailer.rb
. This can be an array of, or a single, string.
There exist one template for the text version and html version of the e-mail respectively. These are found in app/views/fault_mailer/
It is possible to disable features for the public by using custom functionality. This function also allows you to disable a feature at a specific date. This function is only available in a controller including ViewPermissionConcern.
class CustomController < ApplicationController
include ViewPermissionConcern
def custom_disabled_action
disable_feature
# Feature specific code
end
def custom_action_with_end_date
disable_feature from: '2017-02-27'
# Feature specific code
end
end
The database is structured after a permission model that selectively enables access to different areas. The permissions for each user is stored in the permissions
column and consist of a 64-bit field where every bit is a toggle for the permission on that bit index. This gives a maximum of 64 permissions!
Permissions are defined in app/constants/permission.rb
on the following format:
module Permission
ALL = 1 << 0
LIST_ORCHESTRA_SIGNUPS = 1 << 1
MODIFY_ARTICLES = 1 << 2
LIST_USERS = 1 << 3
MODIFY_USERS = 1 << 4
DELETE_USERS = 1 << 5
LIST_CORTEGE_APPLICATIONS = 1 << 6
APPROVE_CORTEGE_APPLICATIONS = 1 << 7
end
The bit shift operator specifies the bit that defines the permission in question. The above code results in the following content:
module Permission
ALL = 0b0000000000000000000000000000000000000000000000000000000000000001
LIST_ORCHESTRA_SIGNUPS = 0b0000000000000000000000000000000000000000000000000000000000000010
MODIFY_ARTICLES = 0b0000000000000000000000000000000000000000000000000000000000000100
LIST_USERS = 0b0000000000000000000000000000000000000000000000000000000000001000
MODIFY_USERS = 0b0000000000000000000000000000000000000000000000000000000000010000
DELETE_USERS = 0b0000000000000000000000000000000000000000000000000000000000100000
LIST_CORTEGE_APPLICATIONS = 0b0000000000000000000000000000000000000000000000000000000001000000
APPROVE_CORTEGE_APPLICATIONS = 0b0000000000000000000000000000000000000000000000000000000010000000
end
Permissions are referred to by using the module name together with the permission identifier, like this:
Permission::LIST_USERS
It is possible to limit the access to specific views by utilising the module ViewPermissionConcern. This function is only available in a controller including ViewPermissionConcern.
Most functions can be overridden by being an administrator, which all users with the first permission bit set are. This equals the permission Permission::ALL
.
# Require the following permission to continue. Overridable.
require_permission(permission)
# Require membership of the model. This is defined per-model basis and may or may not be implemented in the model you wish to test against. Non-overridable.
require_membership(model)
# Require ownership of the model. The same restrictions as above applies. Non-overridable.
require_ownership(model)
# Require membership of the model, or that the user has a specific permission set. Overridable.
require_membership_or_permission(model, permission)
# Require ownership of the model, or that the user has a specific permission set. Overridable.
require_ownership_or_permission(model, permission)