rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ankur Goyal <asgo...@umail.iu.edu>
Subject Re: [DISCUSS] Proposal for Person Profile Direction in Rave
Date Tue, 07 Feb 2012 20:29:27 GMT
The description of this proposal covers most of the thing and is clear.

On Tue, Feb 7, 2012 at 10:07 AM, Carlucci, Tony <acarlucci@mitre.org> 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: acarlucci@mitre.org<mailto:acarlucci@mitre.org> | v: 781.271.2432 | f:
> 781.271.3299
> The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message