Cookbook for getting custom role based icons

4.666665
Average: 4.7 (3 votes)

Adding a system icon to Luminis

Overview

There are many small steps that need to be completed in order to have a new system icon display in Luminis. You will need the source package of the "edu.(your_university).icons" package, access to the cpadmin utility, and an instance of Banner INB open for modification, and the icons themselves.

The convention over configuration method of the class will enforce a consistant naming convention across the system. Choose your role name to be the same as your system name.

Create a CustomIcons.java file

Save the file CustomIcons.java (attached) inside of a package name like "edu.(your_university).icons".

Edit the line that lists the package name to reflect the choice above. Also edit the array of roles_watched. You want to append to this array by adding the name of your external system(s).

Check org.jasig.portal.channels.cpicons.icon_evaluator

Make sure that the value reflects the package path and class name of the file you just edited:

configman -s org.jasig.portal.channels.cpicons.icon_evaluator edu.(your_university).icons.CustomIcons

Modify pds.roles.external

Luminis keeps an internal record of which roles it should listen to over the LDI events system. You will need to do a

configman -g pds.roles.external

to fetch the existing roles. Now, to append to this list, copy the result of the output above, and add your system as such:

configman -s pds.roles.external "..., ..., ...", 

separating the roles with a comma.

'''Note''': Luminis takes the GORRSQL role name, and converts the string to a capitalized format. For instance, "DUCK" would be entered in pds.roles.external as "Duck"

Edit /opt/luminis/webapps/luminis/WEB-INF/config/cpinfo.properties

You will need to add a line with your system in the following format:

< system >.enabled:prop

'''Note:''' The naming convention for your system here is all lowercase. Yeah, I don't really know why either.

Edit $CP_ROOT/webapps/luminis/WEB-INF/uPortal/org/jasig/portal/channels/cpicons/channel.xsl

You will need to add a template stub to generate the actual icon inside of the icons channel. This can be accomplished by adding the following:

Save the file channel.xsl (attached) over your existing channel.xsl file (after you make a backup of course!):

cp $CP_ROOT/webapps/luminis/WEB-INF/uPortal/org/jasig/portal/channels/cpicons/channel.xsl 
$CP_ROOT/webapps/luminis/WEB-INF/uPortal/org/jasig/portal/channels/cpicons/channel.xsl.original

Modify the section where the template calls are listed. Make sure to replace "system_name" with the name of YOUR system. Do this once for each new external system you want a custom icons for.

This defines an XSL template name "custom_icons" that will do all of the heavy lifting for us. Hopefully, it is explainatory enough to be understood at a glance. The second template "custom_icons_pre" defines two Javascript functions that the "custom_icons" template will call. The function "show" takes a system name, and resolves it to a URL inside of a pop-up Window. Now before you jump on me about not using the code inside of uPortal's nested-tables.xsl file, know that I didn't use it to correct some issues.

* The nested-tables.xsl file is overly verbose, and repeats itself in multiple places.
* Systems like Banner which do not lend well to refreshing the page it is running in do not do well with the function OpenWin(); It will restart your Banner session if an icon exists to launch it, and is clicked twice. My function checks to see if the window exists, and instead of refreshing, it focuses the window instead.

Copy over the icons

Copy the icons for your system to the skin directory of the skin you are using. This can be found at:

cp $CP_ROOT/webapps/luminis/custom

Once the icons are copied over, you can deploy the new skin with the following command:

deployskintemplate -t < skin > -c

Deploy your channel

Launch the ant build utility and deploy this package in the uPortal style. You will need to restart Luminis for the package, and configman values to take effect.

Luminis should now be listening for the new role, via LDI events.

Update GTVSQRU

Add your system name to the GTVSQRU form inside of Banner. Choose a start date earlier than the current date for the change to be effective instantly.

Update GORRSQL

Under the INTCOMP process, select your system you have just entered inside of GRTSQRU. Enter in your SQL, and make sure to click '''Validate''', and '''Active''' choose a start date prior to today's date.

'''Note:''' Making a role inactive does not revoke the role from the people it has been granted to via LDI events. It simply keeps any further changes from being calculated.

Process your role changes

This will recalculate all of the roles, and update them, and generate a sync request to LDI for bridging into Luminis.

Check processing status of LDI

The following code will show a list of events both pending and completed. Events with a 0 are waiting to be processed, 1 is in process, and 2 is finished processing. Make sure that the newly requested sync has registered itself in this table, and is marked as a 2.

select a.* from gobeqrc a                                                       --Monitor LDI events
order by a.gobeqrc_activity_date desc

Check Message Broker (LDI) status in Luminis:

mbtool list brokerstatus

'''Note''': The mbtool brokerstatus seems to be totally agnostic to the fact of whether the message broker process is actually running. If events sit in the gobeqrc table as a "0" (unprocessed) for more than 15 minutes, run the command below to start the broker:

/opt/luminis/products/lmg40/Events/bin/startevents &

Check error logs if something happens:

tail -50 $CP_ROOT/logs/ldi-error.log

Log out of Luminis, and then back into Luminis.

Check cp.log

See if you can find any lines beginning with "Custom role:" in cp.log. This will let you know on login if your account was associated with, or enabled any role based icons.

cat $CP_ROOT/logs/cp.log | grep "Custom role:"