[sakai2-tcc] Maintenance Branch Merge Policy: Delegated Access Patches SAK-22079

[Bryan Holladay]

TCC et al,

I am requesting a few small patches to be included in to the Sakai
2.9.x maintenance branch so that the Delegated Access 1.0 release will
be compatible with the 2.9.x branch of Sakai.  I feel this is
important for the adoption of this tool because of how far away the
2.10.0 release for Sakai is.  There are no API changes, no DB changes,
and only tool functionality changes if the delegated access tool is
being used.

I have created a jira (SAK-22079) for a Sakai 2.9.x maintenance branch
merge.  The patches are linked in the description.  Each patch is a
minimal modification that uses a user's session, sakai.props and sakai
events to communicate with the Delegated Access tool and doesn't
effect the tools if the delegated access tool isn't included in the
build or being used.

I am willing to do all the merging and QA testing required for these patches.

Here are my comments on the qualifications listed in
https://confluence.sakaiproject.org/display/TCC/Maintenance+Branch+Merge+Policy


>The change is narrow in scope (modest changes to a single project)

Each project (kernel, portal, site-manage) do not depend on each other
and creates no dependencies to the Delegated Access tool. They use
Session variables, sakai.props and event triggers to communicate. If
there are no session variables for delegated access, the behavior
stays the same in each tool

>The change has been reviewed and approved by tool lead for the maintenance branch

This email is requesting the patch reviewal.

>The change does not require database changes

No db changes required

>The change has been running in production for one month minimum

Columbia has been running these patches in production for over a month (2.8.x)

>Changes that could impact internationalization negatively must be tested in two languages that are not variants of the same country.

No internationalizations changes in these patches

>The change is non-disruptive to the user experience ( I.e. changes that don't require user retraining and are unlikely to break existing customizations).

Unless the institution enables Delegated Access, there will be no
disruptions to the user experience.

>Exceptions to this rule may be made if the change is configurable and is disabled by default.

The user facing changes are configurable and off by default (site-manage)

>Prior to merging, the change must be tested with the target maintenance branch, by the requesting institution, using a documented test plan.

I will spearhead the testing (bryan)



Thanks,
Bryan