Hello Rave Community,
We have internal requirements at MITRE to build out some extensive Person
Profile functionality in Rave. We've developed a proposal of the direction
we'd like to take the Person Profile in Rave, since we think a lot of the
features would be appropriate to put into the core Rave code as opposed to our
custom extension. Before we started creating Jira tickets, we'd like the
community to comment on it to make sure it fits into the community's vision of
Person Profiles. The features below represent what MITRE needs, and would
definitely not represent the whole feature set of Person Profiles in Rave. The
first 3 items are the requirements for our initial version of the Person
Profile and what we would focus on first (essentially the "view" work). The
last three would be future enhancements.
Thanks in advance for your time...
Tony
(1) A Person Profile page can be viewable by any user, not just the owner
a. proposed URI mappings: /portal/app/profile/{username or entityId}
b. We would add a new field to the Page model object: boolean isProfilePage
i. This
will be an indicator to the rest of the application that it is not a
"Traditional" page object, but a "Profile" page
ii. This will
also allow the security layer on the services to use this field to allow
Profile Page objects to be viewed by people other than the owner
iii. Perhaps a
more sustainable long-term solution would be to create a pageClass column
instead of the specific Boolean, that could be "regular, personProfile,
future-alternate-page-class", etc?
(2) The Person Profile page can contain multiple sub-pages (tabs from a UI
perspective), each containing multiple regions and widgets
a. Create a new ProfilePage model object
i. There
will be a one-to-many relationship between Page<->ProfilePage (one Page has
many ProfilePages)
ii. Fields in
ProfilePage
1. Long entityId
2. Page page
3. String title
4. PageLayout pageLayout
5. List<Region> regions ***this may need to be thought out more since a
Region object currently has a Page object attribute ***
(3) Some widgets are fixed and some have no "chrome" (border, menus, etc)
a. Ability to render "fixed" widgets and widgets that don't have "chrome"
on the Person Profile page
b. The solution should be generic enough so that this also available for
traditional pages as well
(4) The owner of the profile can edit information about themselves that the
Rave Administrator deems editable
a. We can build on the existing edit person profile context code in Rave
b. Develop a mechanism that controls what person profile fields can be
editable by a user
i. For
example: out-of-the box we might let users update their email address, but for
an internal corporate implementation of Rave we wouldn't want employees to be
able to change that particular field
ii. Perhaps
an Admin screen that displays all person profile attributes and allows the
admin to turn them on/off for editing?
(5) The composition and layout of the Profile Page can be easily editable
a. Ability to follow a similar model of customization (Drag and Drop,
add/remove widget, etc) of a traditional Page
b. Ability to create two types of Profile Page customizations
i. Owner
Defined Customization: I want EVERYBODY to see these customizations to MY
profile page
ii. Viewer
Defined Customization: I want to see this common set of customizations when
viewing ANYONE's Profile Page
(6) A user can create a connection between the individual they are looking
at and themselves from the Profile Page
a. Create a UserConnection model that connects one Rave User with another
b. Full API stack for managing user connections (add, remove, view, etc)
---
Anthony Carlucci | SW App Dev Eng, Sr. | R501 / KW App Development & Maint
e: [email protected]<mailto:[email protected]> | v: 781.271.2432 | f:
781.271.3299
The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
