Converting BROWSE grants on categories to BROWSE grants on portlet-definitions

MUMMNG-2277.md

Intent

The exercise here is to move from

• portlets being in categories and BROWSE permission being granted to groups of users on categories, to
• BROWSE permission being granted to groups of users directly on specific portlets

Background

BROWSE permission is intended to gate whether users can see the app directory entry for an app, whether in search results, when browsing, or when following a deep link to an app details page.

This is intended to be distinct from so-called SUBSCRIBE permission, which grants ability to launch or render the content and to add the content to one's layout (which is where the name of the permission comes from, and which makes some sense, since there'd be little point to adding content to one's layout that one cannot exercise.)

The resulting permissions environment is intended to be powerful and flexible.

• In many cases, the set of users who can find the thing and who can use the thing should be the same. It's useful for those users and noise for anyone else. Portal administration functionality seems firmly in this category -- the only people who need to know about the portlet management tooling in MyUW are the people who manage portlets in MyUW.
• In some cases, the set of users who can find the thing should be wider than the set of users who can use the thing. This might be the case for a My Final Grades app showing grades to students -- academic advisors maybe should be able to find and reference this app even though they do not themselves use it. It might often be the case that un-authenticated users should be able to find and view the app directory entry for a thing even though authentication is required to actually exercise the thing, so that this content can be search engine (Google) indexed.
• In some cases, the set of users who can find the thing should be narrower than the set of users who can use the thing. This is the case for the random bits that are technically portlets peppered into regions in Respondr. Users may need to exercise this content to get header messaging and skinning and Google Analytics and so forth to work properly, but they don't need to be finding any of this in search results and the less they have to think about this noise the better.

BROWSE and SUBSCRIBE as distinct permissions are intended to support all of these use cases, without constraining the way Categories are used.

Motivation

The intent of moving from

• portlets being in categories and BROWSE permission being granted to groups of users on categories, to
• BROWSE permission being granted to groups of users directly on specific portlets

is to

• improve the ease of understanding who has BROWSE permission on what portlets. After this change, simply look at the portlet's portlet-definition, and it will tell you directly.
• make it feasible to confidently update BROWSE permission so as to get to more thoughtful use of these permissions. After this change, simply update this permission grant right in the relevant portlet definition.
• make it feasible to confidently work with stakeholders in nuancing the access control on the app directory presence for apps
• improve supportability of MyUW, especially once there's a helpdesk-facing UI for inspecting these permissions
• in particular, set the stage for tweaking these permissions in the face of more campuses adopting new MyUW and so potentially benefiting from clarity in what users find and for tweaking these permissions to nuance what app directory information is publicly available, enabling public search and browse over the directory and eventually public web crawler crawling of this content (hi, Google!)
• open the door to implementing a more efficient BROWSE permission calculation algorithm involving comparing the user's group memberships more directly against the specific portlet-definition's data rather than traversing the categories directed acyclic graph.

Syntax

The syntax to grant BROWSE permission in a portlet-definition is

<permissions>
  <permission system="UP_PORTLET_SUBSCRIBE" activity="BROWSE">
    <group>Some Group Name</group>
    <group>Some Other Group Name</group>
  </permission>
</permissions>

Localhost tier

Authenticated Users were granted BROWSE on Demonstration category

Group Authenticated Users had been granted BROWSE on the category Demonstration.

In localhost, it turns out these uw-quickstart portlet-definitions are in the Demonstration category:

• demo-email-preview
• emergency-alert-admin

Which are both portlets MyUW is not actually using, so nothing to do here except delete the GRANT on the category.

Demonstration has no child categories.

Students were granted BROWSE on Notification category

Group Students had been granted BROWSE on the category Notification.

In localhost, in turns out these uw-quickstart portlet-definitions are in the Notification category:

• activate-services
• employee-heritage-questionnaire
• madison-snow-emergency
• student-elections
• waa-membership

Notification has no child categories.

To achieve the equivalent BROWSE permissions without requiring the grant on the Notification category, added

<permissions>
  <permission system="UP_PORTLET_SUBSCRIBE" activity="BROWSE">
    <group>Students</group>
  </permission>
</permissions>

to each.

MyUW HR Officers were granted BROWSE on Work category

Group MyUW HR Officers were granted BROWSE on category Work.

In localhost, in turns out these uw-quickstart portlet-definitions are in the Work category:

• account-admin-tools
• benefits-enrollment
• cintax
• contact-information
• doit-consolidated-billing-invoice
• earnings-statement
• employee-resources
• hr-payroll-benefits-news
• hrs-career-opportunities
• HRSBusinessEmailAdmin
• HRSManagerTimeApproval
• HRSSelfServiceLinks
• leave-statement
• lynda-dot-com-at-uw-madison
• make-a-difference
• my-professional-development
• university-personnel-systems-development
• university-staff-benefits-statement
• uw-system-earnings-statement
• uw-system-employee-resources
• uw-system-gb-hr-connect
• uw-system-leave-statement
• uw-system-university-personnel-systems-development
• wiscareers

Work has no child categories.

To achieve the equivalent BROWSE permissions without requiring the grant on the Work category, added

<permissions>
  <permission system="UP_PORTLET_SUBSCRIBE" activity="BROWSE">
    <group>MyUW HR Officers</group>
  </permission>
</permissions>

to each.

Everyone was granted BROWSE on several categories

Here's the big one.

Group Everyone (which is everyone, including unauthenticated users), was granted BROWSE on a slew of categories, namely

• Academics
• Advisor
• Applications
• Entertainment
• Featured
• Information
• Instructors
• Library
• News

These categories have no child categories.

In localhost, it turns out these uw-quickstart portlets are in one or more of those categories:

• academic-resources
• box
• BusinessDMPortlet
• calendar
• cals_resources
• campus-news
• class-schedule
• course-resources
• course-services
• directory
• doit-help-desk-notices
• enrichment-opportunities
• enrolled-classes-map
• etext-pilot
• favorite-library-e-resources
• FinalGrades
• financial-services-and-resources
• google-apps
• grad-application-status
• hr-payroll-benefits-news
• insite
• learn-at-uw
• learning-support
• library-reserves-by-department
• lynda-dot-com-at-uw-madison
• madison-snow-emergency
• mobile-myuw-announcement
• my-bookmarks
• MyCourses
• myuw-news
• notification
• nursing_school_resources
• post-graduation-plans
• radiology_resources
• rb-reports
• responsive-myuw-announcement
• scholarships-at-uw-madison
• school_of_education_resources
• search
• single-wisc-mail
• soher
• student-center
• textbooks-by-department
• tuition-account-erefunds
• university-personnel-systems-development
• upcoming-campus-events
• uw-badger-headlines
• uw-system-gb-hr-connect
• uw-system-hr-news
• uw-system-hr-payroll-benefits-news
• uw-system-news-employee-resources-tab
• weather
• wisc-act-admin
• wisc-chat
• wisc-mail
• wisccal-available-portlet

(None of the default_entities are both in one of these categories and not overridden in uw_quickstart entities.)

To achieve the equivalent BROWSE permissions without requiring the grant on a category, added

<permissions>
 <permission system="UP_PORTLET_SUBSCRIBE" activity="BROWSE">
   <group>Everyone</group>
 </permission>
</permissions>

to each portlet.

Portal Developers are granted BROWSE on all portlets

This grant is special, granting Portal Developers BROWSE on the special object ALL_PORTLETS.

To achieve the equivalent BROWSE permissions without requiring the grant on ALL_PORTLETS, add

<permissions>
 <permission system="UP_PORTLET_SUBSCRIBE" activity="BROWSE">
   <group>Portal Developers</group>
 </permission>
</permissions>

to each portlet.

This is worth doing in that it makes the permissions more explicitly expressed in the portlet-definitions and it sets the stage for a BROWSE permission evaluation algorithm that does not traverse categories and does not rely upon the ALL_PORTLETS special object, that is, does not rely upon uPortal's permissions engine, instead checking against portlet-definition data more directly.