...
This feature is being developed (primarily?) by UW-Madison for use in the redesigned UW-Madison portal.
Favorites is a different way of interacting with layout.
...
Feature branch for favorites portlet: https://github.com/Jasig/uPortal/tree/UP-3896 , leading to this pull request: https://github.com/Jasig/uPortal/pull/290 .
Some features have come into this branch via pull requests, vis: * un
- Un-favoriting: https://github.com/Jasig/uPortal/pull/203
- Re-name favorites portlet definition: https://github.com/Jasig/uPortal/pull/215
- Favorites collections as their own folder type: https://github.com/Jasig/uPortal/pull/230
- Maximizing a portlet supersedes focusing on a fragment: https://github.com/Jasig/uPortal/pull/260
Got mockups / screenshots?
Note that some of these do not reflect the very latest code / design.
| Gallery |
|---|
Design
Where are favorites stored?
...
Edit UI lists all favorites, collections first then portlets.
In edit mode users can re-order individual favorites and favorited collections, subject to DLM precedence and re-ordering restrictions.
Items with deleteAllowed=true (DLM) are hyperlinks to ActionUrls deleting the layout node from the relevant favorites-modeling layout folder (type="favorites" or type="favorite_collection"). Trash glyph.
Items with deleteAllowed=false (DLM) are not hyperlinks and have tool tips explaining they are not deleteable. Lock glyph.
Edit controller checks if signaled nodeId is deletable. Adds errorMessage render parameter if needed. Adds successMessage render parameter if success.
That the re-order glyph appears even when there's only one item of a type (only one favorited portlet or only one favorited collection) is a feature not a bug: on design consult, the suggestion was that the glyph is worth retaining to communicate to the user that if he or she had more items, they would be re-order-able.
Adding to favorites
Add to Favorites is added to the per-portlet options menu:
Configuration
Turning it off
If a user doesn't have a folder of type "favorites" in their layout, the theme transform detects that fact and suppresses "Add to favorites" from the portlet options menu, since there's no folder into which to save the user's favorites. This means that you can control who has access to Favorites by deciding to whom you direct DLM managed fragments with folders of type=favorites.
If you publish the Favorites portlet and the folder of type=favorites to no one, then you can safely ignore the Favorites feature entirely.In edit mode users can re-order
You might gently introduce Favorites to a beta audience by only publishing the Favorites portlet to that audience and also only publishing favorites-type-folder-containing-fragments to that beta audience.
Integration with Marketplace
The Marketplace portlet is intended to be a good place for users to browse for favorites. If you choose to implement Marketplace (or to substitute your own suitable portlet), you can tell Favorites the fname of your Marketplace portlet via portal.properties configuration. When this fname is declared, Favorites will display the link to Marketplace in appropriate places. When it's not declared, no worries, degrades gracefully.
Forced favorites, restrictions on re-ordering
Since individual favorites and favorited collections , subject to DLM precedence and re-ordering restrictions.
are merely usages of DLM layouts, DLM edit restriction apply. Because these types are goofy, the built-in admin UI tooling for editing these layouts and the restrictions on them just doesn't work. However, you can edit the DLM fragments containing the template type=favorites and type=favorites_collection folders by editing and importing/exporting the relevant fragment-layout XML entity files.
Delete restrictions should just work.
Re-order restrictions will be goofy, since the Favorites edit UI currently only makes a partial effort to reflect DLM restrictions. If it thinks you can't move an item at all, the move control is suppressed. However, DLM is more complicated than that – conceivably you might be able to move an item to some drop locations but not others. The UI won't reflect this and experimentation suggests that rules would only be enforced on next login.
Anyway, those ordering restrictions seem like false requirements. If you actually have those requirements, please do get in touch and/or jump in to help implement support for them – our own feelings at Wisconsin are that we probably want to leave re-ordering wide open for end-user customization if they care enough to re-order.
mUniversality perks
Favorite collections will appear in your mUniversality list view!
Who's interested in adopting / working on this?
...