A Wikified version of the ALM Gap Analysis word document
| Why was this Wikified? This was wikified to put it on the web in a way more ammenable to public comment, collaborative editing, and linking from issues referenced here to further information. |
The original posting for the ALM Gap Analysis was here.
The original document is also attached to this page below. Further explanation of some aspects of the analysis and an additional requirement were outlined in a follow-up email between several core developers. The details are found in ALM Gap Analysis Further Explanations.
ALM Gap Analysis
The table below contains a summary of the key aspects that make up or directly affect usage of Aggregated Layout Management. The list includes items that exist in either the ALM implementation provided by Sungard SCT's Luminis product or in Jasig's uPortal ALM implementation. It also includes items that are in neither implementation but have been identified by problems incurred by customers in the field.
The table has been constructed to indicate if that feature exists in either portal and in cases where the feature's functionality may not be clear examples are included. Following the table are additional thoughts on some of the items not supported by either implementation.
This is a work in progress so any additional information or recommendations are welcome. Please bring them to my attention Mark R. Boyd.
| ID | Feature | Y/N | SCT | Y/N | JA-SIG |
|---|---|---|---|---|---|
| F1 | Define Pushed Fragments | Y | Via dlm.xml file. Must edit file on all servers in cluster or share via network drive. | Y | Via GUI screens. Stored in DB, all servers in cluster have access. |
| F2 | Define fragment owner who can edit a specific fragment | Y | Via dlm.xml file. Regular user account defined as the owner of the fragment's layout. That user's layout becomes the fragment's layout. That fragments can only be edited by logging into that account and altering the layout. | Y | The creator of the fragment is the implicit owner. |
| F3 | Grant permission to other users to maintain the layout of a specific fragment. | Y | Accomplished via sharing the login id and password of the fragment owner account with those who are to maintain the layout. Users can not edit the fragment's layout while logged in to their own account. | N | Only the owner of the fragment can edit the fragment and can do so while logged into their account. |
| F4 | Define Pulled Fragments | N | N/A | Y | Via GUI screens. Stored in DB, all servers in cluster have access. |
| F4.1 | Changes in fragments by one server should be seen and loaded by other servers without a webserver restart. | Y | Dlm.xml is reloaded on a configurable, periodic basis. If a shared network drive is used to house dlm.xml then other servers will see changes and load them. | ? | Unknown |
| F5 | Assign who can subscribe to pulled fragments by group membership. | N | No | Y | Via GUI using GroupsManager |
| F6 | Assign who receives pushed fragments by simple membership-in-group. (Boolean summation expression like student or faculty or ...) | Y | Via declaration in dlm.xml file and use of plugged-in group membership evaluator. | Y | Via GUI using GroupsManager |
| F7 | Assign who receives pushed fragments by complex membership-in-group relationships. (Arbitrarily complex boolean logic expression like freshman and (chemistry-major or (engineering-major and not comp-sci-major )). | Y | Via declaration in dlm.xml file and use of plugged-in group membership evaluator. | N | Only simple group membership is supported. |
| F8 | Provides pluggable "assignment" mechanism for assigning who receives fragments. (i.e.: so assignment can be made by other aspects beyond group membership or via more complex logic.) (PAGS provides this through mapping dynamic groups at login time through the existing groups infrastructure. This is a formalization or standardization of a plug-in mechanism.) | Y | Via interfaces and declaration of implementers of interfaces and their configuration in our dlm.xml file. (Note: Although we can target fragments using complex Boolean logic channel access is still granted by Boolean sum so channels accessible to a fragment owner my not be accessible to the target audience causing some channels to appear broken.) | N | Only simple group membership is supported. |
| F8.1 | Provides pluggable "assignment" mechanism for assigning who receives channels. (To provide common functionality for both channel assignment and fragment assignment.) | N | Only simple group membership is supported. | N | Only simple group membership is supported. |
| F9 | Grant pushed-fragment publishing capability | N | Fragments are only defined by declaration in dlm.xml file so only admin users with access to the disk drive can define. | Y | Those who have channel publishing permission are allowed to define pushed fragments. |
| F10 | Grant pulled-fragment publishing capability | N | See above. | Y | Those who have channel publishing permission are allowed to define pulled fragments. |
| F11 | Ability to individually grant pushed-fragment publishing capability or pull-fragment publishing capability to a user. | N | See above. | N | Any user with channel publishing permission is allowed to define pushed or pulled fragments. |
| F12 | Ability to assign relative "strengths" to fragments by which fragments can have visual priority over lesser fragments. | Y | Fragments have a priority value defined in dlm.xml. Higher priority fragments have visual precedence when the fragment locks UI elements in place. Fragments with higher priority can "bump" fragments with lower priority even when their elements are locked in place. | ? | Unknown. |
| F13 | Fragment layout editing must be able to lock elements in place individually like tabs, columns, and channels but accommodating the mechanism in F12. | Y | Fragments elements have a moveAllowed attribute that can be set by a user editing the fragment's layout. Tabs locked in place can only be "bumped" by tabs from fragments with higher priority. User owned tabs have a priority of zero, i.e.: lowest priority. Columns locked in place can not be bumped by end users adding columns to their left but columns may be added to their right if allowed for by the fragment owner. | ? | Unknown |
| F14 | If a fragment element that previously allowed lower priority items to "bump-it" were changed so that it were locked in place, any items with lower priority that previously had "bumped" that element move to a lower visually-valuable location. | Y | Lower priority elements in a more visually valuable location get "bumped" back by a change in fragment restrictions and end up in the next most visually valuable location after the fragment that has now bumped them in an effort to get them as close as allowed to the original location chosen by the user. | ? | Unknown |
| F15 | Changes in fragments elements resulting in overriding prior user specified ordering of elements must attempt to preserve as much of the user specified ordering as can be accomplished while complying with fragment restrictions. | Y | Lower priority elements in a more visually valuable location that get "bumped" back by a change in fragment restrictions will still be in the same order relative to each other and will be located immediately next to the fragment element that "bumped" them back. | ? | Unknown |
| F16 | Fragment layout editing able to restrict child elements from being added to parent elements like columns to a specific tab or channels to a specific column. | Y | Container fragment elements (i.e.: tabs and columns) have an addChildAllowed attribute that can be turned on or off while changing the fragment's layout. | ? | Unnown |
| F17 | Users can add content to fragment elements if the mechanism of F16 has not placed any restrictions adding such content. | Y | End users can add columns to fragment owned tabs and channels to fragment owned columns. | ? | Unknown |
| F18 | If a fragment element previously allowed adding of child elements and such capability was revoked any child elements added by a user but now discarded are accessible to end users so that they can retrieve "auto-removed" content. | N | Currently any child content added to fragments elements by end users is lost if a fragment modifies the element to prevent adding child elements like columns to tabs or channels to columns. | ? | Unknown |
| F19 | Fragment layout editing able to restrict deletion of specific elements like tabs, columns, or channels individually. | Y | Fragment elements have a deleteAllowed attribute that can be set when editing a fragment's layout allowing users to delete that element from their layout and not have it show up when logging back in unless that capability were revoked by a fragment owner. | ? | Unknown. |
| F19.1 | End users able to delete fragment content if allowed for by the mechanism in F19 and not have it show up thereafter unless such capability were overridden by the editor of the fragment. | Y | Fragment elements have a deleteAllowed attribute that can be set when editing a fragment's layout allowing users to delete that element from their layout and not have it show up when logging back in unless that capability were revoked by a fragment owner. | ? | Unknown |
| F20 | Ability for the user to see what elements available from a fragment have been removed by them and enable the user to recover those elements. | N | No | ? | Unknown |
| F21 | If a fragment element could be deleted and later was changed to prevent deletion it reappears in layouts where users had deleted it. | Y | Yes | ? | Unknown |
| F22 | End user is allowed to change aspects of individual fragment elements if such aspects exist and if allowed for by the fragment. Examples are tab name, column width, and channel user-override-able publish-time parameters. | X | End users can change tab names and column widths if allowed for by the fragment. There is a bug in Luminis whereby they can change channel publish-time parameters that allow end user overrides but such changes are not persisted. | ? | unknown |
| F23 | A fragment able to restrict changing element aspects if so desired. | Y | Fragment container elements like tabs and columns have an editAllowed that can allow users to alter tab names and column widths or prevent them from doing so. | ? | Unknown |
| F24 | If a fragment element previously allowed altering aspects and then later revoked such a capability any value set by the user reverts to the value set by the editor of the fragment. | Y | The next time a user logs in the values will revert to those set in the fragment. | ? | Unknown |
| F25 | Provides a mechanism where-by channels can determine if they are being viewed and configured in a fragment by a fragment editor or in a fragment being viewed by an end user. | Y | ChannelStaticData.isIncorporated() has been added and returns true if a channel was incorporated into the user's layout from a fragment. (This allows channel designers to provide different functionality to fragment editors and fragment users. For example our improved bookmarks channel allows the original subscriber to a channel to edit its bookmarks while one that was incorporated into a user's layout is not editable.) | ? | Unknown |
| F26 | Provides a mechanism where-by a channel can persist information or configuration made by the fragment owner and then later use such information when being viewed by a user of that fragment. | Y | ChannelStaticData.getInstanceId(type) along with final static variables USER_SCOPE and GLOBAL_SCOPE provide the channel with identifiers that can be used to persist information in a fragment and later retrieve that same information when being viewed by a user of that fragment. (This is used in our improved bookmarks channel allowing bookmarks to be set by fragment owners and viewed by users of the fragment. It also allows for each bookmarks channel instance to have its own set of bookmarks without conflicting with those of other instances.) | ? | Unknown |
| F27 | Provides a mechanism that restricts what channels can be added to a fragment so that only channels that can be viewed by the target audience of the fragment can be added. | N | If the roles of fragment owners are out-of-line with the configured target audience of a fragment then a fragment owner can subscribe to those channels but users of that fragment get "not authorized" messages in place of those channels. | ? | Unknown |
| F28 | If changes are made in the target audience of a fragment causing some channels on its surface to no longer be accessible to some members of that target audience there is a visual indication of such a problem and the specific channels having that condition. | N | See comment for F27 and discussion below. | ? | Unknown |
| F29 | Provide a way to override the mechanism in 27 to allow channels only viewable by some subset of the fragment's target audience to be added to the fragment for the express purpose of gracefully appearing or disappearing if not viewable by the user without incurring that channel being replaced by the error channel with the message, "You are not authorized to view this channel." | ? | ? | ? | ? |
Known issues
Publishing Fragments with Inaccessible Content
When providing pushed or pulled layout fragments to a portion of a site's user population there is a miss match between the means of selecting the receiving or target audience of that fragment and the means of defining the audience that can view specific channels. This can lead to some being placed in a fragment that is inaccessible to the target audience.
First of all, when channels are published groups can be selected who are then authorized to subscribe to and use the channels. The fragment editor is a member of some set of groups. When editing a fragment the pool of channels from which that user selects channels for inclusion in the fragment is based on that user's group membership and which channels have been granted to those groups.
Secondly, when the fragment is published, groups can be selected which can use the fragment. In the case of pulled fragments users in those groups can subscribe to the fragment. In the case of pushed fragments users in those groups have the fragment show up for them automatically.
As noted these two targeting measures can potentially conflict. That set of channels available to the fragment editor for inclusion in the fragment is not the same set of channels that can be viewed and used by the target audience of the fragment. When such is the case the target audience sees error messages in some fragment channels indicating, "You are not authorized to view this channel."
For example, lets assume that the faculty group have been given permission to publish fragments to the student group. Since fragment publishing in JASIG' ALM is currently determined by having the channel publishing permission an administrator must grant the channel publishing permission to the faculty group. Additionally, since faculty are to be able to target the student group when publishing fragments an administrator must grant the "select group" permission on the student group to the faculty group using the Permissions Manager channel. Finally, lets say that some channel, the Daily Business Cartoon channel, is only accessible to the faculty group.
Now a faculty user can log in, create a fragment, add the Daily Business Cartoon to the fragment's surface, and publish the fragment selecting the student group as the ones to whom this pushed fragment will appear.
When we then log out and log in as a student the fragment shows up in the layout and the "broken" message is clearly visible.
The crux of the problem is two fold in JASIG's ALM: channels can be placed onto the fragment prior to selecting a target audience and the pool of channels that can be placed is determined by the group membership of the editor of the fragment. Publishing comes later. This should be reversed. Until a target audience has been selected the editor should not be able to place channel content on the fragment or at least only be able to place publicly accessible content on the fragment.
If the target audience is ever changed some channels already placed on the fragment may become inaccessible to the target audience. A mechanism must be added to highlight such channels via some warning icon. Such a mechanism must also highlight the fragment itself so that if such channels were on a fragment tab not currently being viewed attention of the problem would be brought to the editor and would give some indication as to the location of the offending channel(s). Such indication should remain visible until the fragment no longer contains content that is inaccessible to its target audience.
The current approach of publishing the fragment only after channels have been placed on its surface may be done solely to prevent the target audience from seeing the fragment in their layout until it is set up completely. That could still be accommodated by using a new attribute to indicate if the fragment is enabled and should be sent to its target audience.
Targeting Fragments and Channels Using Other Aspects
Currently, the target audience for channels and fragments is determined by a simple Boolean sum of group memberships. For example, if the user is in group A or group B or group C then they can subscribe to a specific channel. This targeting approach is determined using the Groups Manager channel to select the groups that are in the effective equation. Upon selection the Groups Manager channel hands the selected list of groups back to the Channel Manager channel which then creates a permission for each of those groups for accessing that channel. Later, during subscribing and again during rendering the system asks if the user has permission to subscribe to that channel which returns true if they are a member of any of the originally selected groups.
Targeting via more complex Boolean logic is possible but would require a different channel for configuring such a selection. Additionally, other means of assigning both channels and fragments to users are possible beyond membership in groups. The PAGS group store is one such mechanism that allows attributes of the person's directory information to be used indirectly. With this approach Groups Manager is still used and hence only results in a Boolean sum configuration. PAGS just adds mapping of existence of a certain attribute to being a member of a pseudo group, a group that only exists at runtime and contains only those people that have that particular attribute.
Conceptually, both new types of audience selection can be achieved by making the selection mechanism extendable and pluggable. By doing so a more complex mechanism can be plugged-in to accommodate more complex groups constructs or to base assignment on aspects beyond group membership. Such a mechanism is greatly facilitated by having a pluggable UI piece available, namely channels. Any additional selection mechanism plugged in must provide a channel for configuring that mechanism. Say for example that we wanted to grant access to channels and fragments if the user in group A but not if in group B. This and much more complex assignments should be doable via an extension and a corresponding channel allowing publishers to select via different Boolean constructs and also potentially based on items beyond just group membership.
One problem with making channel and fragment audience selection pluggable is that each user of the selection mechanism, Channel Manager and Fragment Editor, has its own storage mechanism for persisting the currently selected set of groups and the relationship constructs that dictate the target audience using those groups. In each case the underlying construct is a Boolean sum. This does provides a consistent UI appearance. But Channel Manager uses the permissions store to persist the selected set of target groups and entities while the fragment infrastructure uses its own UP_GROUP_FRAGMENT table to persist the target groups for a fragment.
Further investigation is needed to identify more completely how conversion would affect authorization checks. It is certain that some changes would have to be made so that ALM uses the existing standard for evaluating if a user has permission to use a fragment. It would seem logical that it should provide hooks into the permissions layer via an implementation of the IPermissible interface and then look to the permissions infrastructure to determine if a user has access to a specific fragment rather than using its own store. For its current Boolean sum approach this would suffice. For a pluggable, more complex assignment construct this is not the case.
The Boolean sum approach is inherent in the PermissionsManager's approach to assigning permissions. The user has the sum of the permission assigned to the groups to which they are a member. There would also have to be some pluggable mechanism added to the permission layer so that delegation made by a pluggable mechanism that used constructs different from a Boolean sum could be delegated to for providing answers to authorization questions for users. Such a mechanism would evaluate authorizations based on the configured constructs made using the plugged-in mechanism's target-audience-selection editor.
