Permissions on Portlets

Two different permissions govern users' access to portlets once they are published:  BROWSE and SUBSCRIBE.

• SUBSCRIBE grants ability to use, render, run, exercise the content.
• BROWSE grants ability to find the content in the app directory, read about it.

So:

Granting SUBSCRIBE and BROWSE yields a typical experience -- find the thing in customize, add it to your layout, launch it. No worries.

Granting SUBSCRIBE but not BROWSE grants ability to exercise a portlet but suppresses it from the app directory, customize, etc. Useful for a portlet you want users to use (Google Analytics?) but not trip over in the app directory.

Granting BROWSE but not SUBSCRIBE grants ability to find the content, read about it, but not to launch or add it to your layout. This was intended to facilitate support and assistance use cases. Academic advisors might need to find, read about, see screenshots of, know the URL of, a portlet that summarizes a user's enrolled courses, say, even though those advisors do not themselves have courses. (This use case can also be addressed by designing apps to behave reasonable for wider ranges of users, so a courses portlet could cope with a user not having courses, etc. But that requires engineering reasonable into the apps, whereas tweaking permissions at the portal tier lets us deal with the vagaries of the portlets we got today.)

Denying both BROWSE and SUBSCRIBE makes the content totally unavailable to the user.