Assuming lazy consensus without any further feedback, I'll start creating Jira tickets either tonight or tomorrow.
Thanks, Tony >-----Original Message----- >From: Marlon Pierce [mailto:[email protected]] >Sent: Tuesday, February 07, 2012 2:06 PM >To: [email protected] >Subject: Re: [DISCUSS] Proposal for Person Profile Direction in Rave > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Sounds great to me since it will make Rave more social. The last item (#6) >introduces some broader issues: > >* Internal notification/messaging requirements ("Person X wants to be >connected to you"), so we may want to expand this to think of general >messaging requirements. > > >* Symmetric connections (friendships, family connections, business >connections) vs. asymmetric connections (following public figures and >institutions that don't follow you back): what will we support? Can we support >multiple models? > > >* We'll also want to address scaling at some point. > > > >Marlon > > >On 2/7/12 10:07 AM, Carlucci, Tony wrote: >> 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 >> >> >> >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.16 (Darwin) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iQEcBAEBAgAGBQJPMXYIAAoJEEfVXEODPFIDZ2UIAJMCpA3OdutpCld/pMe5t >H+i >bvfJdrMb5ELmweSQEORq35YFaV1/EkgDFbLBxMC7P4+wSr9jh2sNPyK5v5vXTai >I >/PoR4/uBJz+DG7Wn41cRMIoWeyy81SnpF28BQsafJSJXfc+eg8IGU5C8ap+ygfcg >vbawSepW736j3IaoJNaCXKF1jWQbxBrCaBV2g3o3Xg0qZLggcsQaGPkGYdBDDy >PW >yGZZrfYnZOnTgiDEEateemiCCElZyzr/YgNRMhqAaSgTuVcgRPCS9KdnKXg0DycO >AQxBD7nrAwhHHa+MrWhE1txMij340BEnUISQVj+Jxl/gc36ConJs5wqSv/In8Iw= >=98f+ >-----END PGP SIGNATURE-----
