| Section | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Existing Portlets
These are possible changes to existing portlets.
(easy) Announcements Portlet (mentor: Unlicensed user Erik Erik)
Announcements Portlet as it is now, could use a few enhancements
...
(medium) Bookmarks Portlet AJAXification (mentor: Unlicensed user, Unlicensed user Eric Dalquist, Jen Bourey)
The Bookmarks Portlet has been included with uPortal since 3.0 and includes a dynamic interface that uses 100% custom JavaScript and no real AJAX callback support.
...
(medium) JSR-168 IMAP/POP multi-server portlet (mentor: Unlicensed user Jen Bourey)
While the Duke tabbed mail portlet has provided Jasig with a first pass at a multi-server, configurable IMAP/POP portlet, the portlet has not been submitted for incubation and may not address the needs of all institutions. It would be nice to have a more stable, mature version. A well-planned, generalizable portlet built from community specifications would be an attractive portlet to bundle with uPortal.
Content/Document Management JSR 170 (Java Content Repository) Portlets (mentor: Unlicensed user CrisH)
The points might be one, two, or more portlets, additionally, some of this work is already begun as an ASU student project. I do think that even if there is one portlet that does everything, the ability to configure that portlet to only do "some" things would be valuable, e.g., only display some content from a JCR.
...
Google Gadget Portlet (mentor: Unlicensed user Jen Bourey)
I know there was talk about this in the past, but I'm not sure where it ended up.
...
- Gadget hosting support (see above)
- OpenSocial services backed by Portal/Portlet APIs (possibly leveraging an existing implementation like Apache Shindig, or a hybrid like Sling)
- Support for white/blacklisting services from public/external sites, and exporting hosted services (OpenSocial or portlets) for hosting in remote OpenSocial containers
Admin Portlets (mentor: Unlicensed user, Unlicensed user Eric Dalquist, Jen Bourey)
- (hard) User Manager Portlet - An administrative portlet developed using Spring WebFlow 2 that allows administrators to add, modify, and delete local portal users including password management. It could also tie into a newer version of the UP_PERSON_DIR table to allow for administration of local user attributes as well. Additional optional parts include: An end-user targeted flow for users to change their passwords. The portlet could use the Fluid pager component for navigating the users in the system. The portlet could tie into the permissions APIs to allow for delegated administration of users within specific groups.
- (medium) User admin portlet (for managing local portal users)
- (medium) LDAP admin portlet (for browsing adding/creating/deleting users in LDAP)
- (medium) Self registration portlet (both for local portal user, ldap users)
- (easy) Change password, possibly related to the previous point, maybe separate
- (hard) Portlet Manager for publishing portlets (unicon is already well down this road, but what might unicon not be able to get to)
- (hard) Deploy a new portlet UI, possibly tie-in to portlet manager, possibly a separate portlet
- (medium) DLM fragment creator (right now you can only create or delete dlm fragments by editing an xml file)
- (hard) DLM audience, PAGs, Person Directory editor portlets (right now this done by editing configuration files in text editors outside of the portal)
- (medium) Monitoring portlets (probably multiple here, some showing different stats collection results, some showing jmx info/controls, e.g., number of currently active sessions, ehcache info/controls)
...
Third Party Portlets (Incorporate from somewhere else?) (mentor: Unlicensed user CrisH)
Work to try to get technology developed elsewhere to run seemlessly and possibly ship with uPortal, by listing these things I do not mean to imply I know they exist, I just expect they already do and it would probably be better to use them if they exist, then to create our own versions. The effort of each of the following is marked as easy assuming the work is only to package already existing portlet code up for use in uPortal, it assumes minimal to no code changes. This may or may not be a realistic assumption, depending on the third party code that is used.
...