Skip to content
This repository has been archived by the owner on May 4, 2022. It is now read-only.

Show app directory search results the user can BROWSE but not SUBSCRIBE #844

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

apetro
Copy link
Contributor

@apetro apetro commented Jul 13, 2018

Restores the search result count badge on the app directory results tab. That badge had been temporarily removed in #843 because it was including items the user could BROWSE-but-not-SUBSCRIBE in the count even though those search results were not displayed to the user.

This makes that badge count correct by following through on including the BROWSE-but-not-SUBSCRIBE items in the search results display. These you're-allowed-to-learn-about-this-item-but-you-cannot-actually-launch-it items are displayed at the end of the search results, after the items the user can actually launch.

include-not-subscribable-in-search-results

(The use case here is there may be situations in which it is helpful for a user to know about, reference, show another user about an item in MyUW, even though that item isn't intended for their own use. For instance, academic advisors helping students to understand content available to students, even though the advisors themselves cannot launch all of that content.)


Contributor License Agreement adherence:

They had been counted in search results badge count.
Show them last so that badge count and displayed items match
and to honor the intention of granting BROWSE without SUBSCRIBE.
This mock app directory entry now serves as an example of an item with canAdd set to false.
Retain launch URL in not-logged-in case since user might be able to log in to gain privileges to really launch the item, and getLaunchURL( app,  true)  generates a URL suitable for not-logged-in-users to try to log in to gain access.
@davidmsibley
Copy link
Contributor

What are we waiting for on this PR?

@apetro
Copy link
Contributor Author

apetro commented Aug 1, 2018

We are probably waiting on teeing up local data changes so that the BROWSE permissions result in users finding content that they might value finding. I should have some local merge requests soon proposing applying the BROWSE permission grants explicitly on the individual portlet-definition entity files rather than inheriting these via categories.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants