Clientside Integration with Group Control

At the end of the day, Ember FW GC has one purpose, and one purpose only - to make seamless the clientside integration of an app with the Group Control App. It is only the client side integration because there are other addons and aspects which help to use parts of Group Control on the server side (though most Group Control integration on the serverside is done within the Group Control App itself), notably see Auth Core docs to see how role control works on the server side. But for client side there are many aspects of Group Control, which need to be integrated to every app which extends Group Control, and these will be discussed.

Ember FW GC in General

So at its most basic level Ember FW GC helps to implement into the current app the various models which are created and controlled in the Group Control App: the role, the department, the app, and the user. But before we discuss how each of these models are implemented and controlled, we must also discuss the authentication required to ensure the current user has the proper access.

Authentication and Current User

One of the main features that is added to the apps by Ember FW GC is the ability to log in to the apps and have a "current user" that is authenticated, and control which apps and which features in the apps this user has access to. There are many aspects of this user and authentication that are built in for you into the FwHeader, the FwGcNav, the Login Page, the ReLogin Modal, etc. Most of these aspects are already setup for you, and require no additional setup. One other important thing to note about authentication is that whenever you are setting up a route for a page (unless you wish for the page to be accessible for a non-authenticated user who is not logged in), that you extend AuthRoute, which is designed to re-route to the login page if the user is not logged in.

Sometimes in developing, you will need to have access to certain information about the authenticated user, who is currently logged in. Maybe you need their full name, their email, or even their current department as you are filtering certain information. These are the most common needs of information from the current user, but there is a variety of other uses as well. Any information needed for you from the current user can be found by using the CurrentUser Service, which is arguably the most commonly used service from Ember FW GC, and is used multiple times in every app. It is vital that you at least know of the existence of the Current User service as you will inevitably need to use it at some point in developing.

Departments

Department is a vital concept, but one that is almost entirely integrated for you, just by using the regular components from Ember FW GC. Every user is always logged into a specific department. Within this department, they have specific roles, which allow them access to specific features of the app (based on role control, explained below). Using the FwHeader, you can change your current department, using the switch department feature. All data in the apps (with a few notable exceptions) should be saved to a specific department, so data from other departments is not accessible in all departments. This does not effect the client side at all, but while we are on the subject, most tables in your app should have the FK_deptID foreign key. A user can only see the information for the roles they have in their current department (ie a user with an admin role in the Training department will not see the Admin dropdown in Informatics, if they only have base in Informatics).

Perhaps here it is important to mention that the DepartmentTransitionMixin, which is implemented in the application.js route by default, allows you to switch departments by passing the query parameter of setdept at the end of your url. If the user has access to that department, this query param will switch before rendering the page. This is helpful especially in email links, linked to specific information. For example, the apps.bennerlibrary.com/msgc/#/channels/1?setdept=info will switch the department to the informatics department, before loading the channel with id 1 (since you can only access channel 1 from the department which it is in). This is not a feature that is often used, but when it is needed, it is helpful to know about.

Apps

The Apps the user has access to is mostly self contained in the App-Switch Modal, which can be called by the App Switcher button in the FwHeader. There is hardly a need to check apps the current user has access to outside of this, but if the need arises this can also be checked by the has-app helper.

Roles

Assuming your app has already set up the roles in the database (as discussed in Auth Core), there is quite often times when you wish to show or hide certain information based on the current roles of the user. If you are seeking to hide an entire page, the RestrictedRoute enables certain pages to be restricted only to certain roles. If you wish to merely hide certain information on a specific page (such as a button or a dropdown) based on certain roles, you can use the has-role helper.

It is important that any restrictions to roles on the client side is also restricted in the server requests themselves (as documented here) since technically one can call the server request directly without needing to go through our client side (ie the request called by a button shown only to admin should only be allowed to be run by an admin). But it is important to make sure that you are not just filtering on the server either, and are using these various elements of Ember FW GC to ensure that the GUI is a pleasant experience for our end users.

Users

By far the most commonly used model from Group Control is the User model. Not only is the user model very commonly linked as foreign keys in most tables in our apps (as is GC Department), but in almost all the apps, the user model is desired to be a part of dropdowns to select a GC user for certain data in the app. In order to do this, you need to have access to find the user model from the store. In order to do this, you must properly import both the User Model, and the User fw-app Adapter in order to allow the GC user model to be found by calling:

this.get('store').findAll('user');

This has been done for you in basically every app, and so, it is very common to see the GC user already implemented for you. A few apps also implement GC department or GC group in a similar way, but this is far less common. And so, the GC User model is arguably one of the most obvious features implemented by Ember FW GC. There are two more things to note about GC User model before moving on.

inDept Filter

Whenever you are displaying an array of users, you should usually filter where inDept is true, unless you have a clear reason for wanting to see all users. inDept is a boolean which tells you that that user model is a regular user within the department (not a guest user). Because all users who ever worked for Benner Library are in departments as "guest users" you usually do not want a dropdown containing all guest users, but only the regular users. For more information, see API Docs for inDept.

Using GC User Model with CurrentUser Service

It is perhaps important to note as a final note that the Current User service is not the same as the GC user model, thus setting a user variable you wish to save to currentUser will not work. Instead, if you wish to set the user variable to the current user, you must find the GC user model by the currentUser.userId, and set the user variable to that model in order to not have any errors. This is what it would look like:

// NOT THIS
this.set('user', this.get('currentUser'));

// But this, assuming users is an array of Group Control user models
this.set('user', this.get('users').findBy('id', this.get('currentUser.userId')));