Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-39575

Cascade site deletions into site alias records

    XMLWordPrintable

    Details

    • Type: Task
    • Status: CLOSED
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.6.x
    • Fix Version/s: 2.6.x, 2.7.x
    • Component/s: Kernel
    • Labels:
      None

      Description

      In SAK-14483 Peter expressed concern that allowing end users to specify site aliases would eventually drain the alias namespace. Although I think an argument could be made that aliases should be immutable and persistent, there is some precedent for using site deletion to trigger what are effectively site-scoped aliases: see SAK-33. Also, the patch attached to SAK-14910 gives non-super end users the ability to modify and delete aliases. If that patch or something like it is accepted, (optional) automated cascaded site alias deletion seems reasonable as well.

      The attached patch (site-ref-alias-cascaded-deletion.diff) follows up on the above by introducing a new class in the site-manage-impl module: org.sakaiproject.sitemanage.impl.SiteAliasCleanupNotificationActionImpl. Upon initialization, this class registers itself as a "transient" NotificationAction and, if enabled, responds to SiteService.SECURE_REMOVE_SITE events by removing all aliases targeted at the deleted site's reference.

      By default, the SiteAliasCleanupNotificationActionImpl bean is enabled and is configured to log and swallow exceptions reaching notify(Notification,Event). These behaviors can be modified by setting the following boolean properties:

      enabled@org.sakaiproject.sitemanage.api.SiteAliasCleanupNotificationAction=true|false
      propagateExceptions@org.sakaiproject.sitemanage.api.SiteAliasCleanupNotificationAction=true|false

      Note that the default behavior is not consistent with historical behavior. But this can be changed easily.

      As noted in the class javadoc, I chose to take the NotificationAction-based approach rather than the ContextObserver based approach since it was not really my intention to represent a new EntityProducer and implementing that interface is, frankly, unpleasant.

        Gliffy Diagrams

          Zeplin

            Attachments

              Issue Links

                Activity

                  People

                  Assignee:
                  dhorwitz David Horwitz
                  Reporter:
                  dmccallum Daniel McCallum
                  Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                    Dates

                    Created:
                    Updated:
                    Resolved:

                      Git Integration