Proxy Self-editing

1. Proxy Self-editing design review Oct 20, 2011

2. Definition • Proxy self-editing is when a VIVO user has the authority to do "self-editing" on profile pages that are not his own.

3. Use Cases • A department wants to give its administrative assistants the ability to edit the VIVO profiles of its faculty members. • A library wants to give a student intern the ability to edit the library's VIVO profile. • A faculty member wants to give one of her graduate students the ability to edit her VIVO profile.

4. Desired features • a person may proxy self-edit multiple profiles. (use case 1.) • more than one person may proxy self-edit a given profile.  (use case 1) • proxy self-editing rights can be assigned to other types of profile, not just foaf:Person profiles. (use case 2.) • any user with a profile and user account can assign proxy self-editing privileges for her profile to another user(use case 3)

5. Desired features • having a proxy-self-editor does not prohibit a user from editing his own profile. • a proxy inherits all of the self-editing rights that the profile's "owner" has, such as the ability to edit publications where there is an authorship relationship. • a proxy only inherits self-editing privileges, not any other privileges. For example, if the "owner" of a profile is a curator, the proxy self-editor does not inherit those curator privileges. 

6. Desired features • a site administrator can create "bulk" proxy self-editing relationships, giving one or more users the authority to self-edit one or more profiles. (See UI mock-up B.) • proxy self-editing is configurable:  • it can be "turned off" completely • it can be configured so that only admins may select proxies • Perhaps through deploy.properties; perhaps through permissions.

7. Desired features • User receives notification about the changes that a proxy makes to the user’s profile. • Not practical for release 1.4

8. Design decisions • No distinction between a proxy assigned by the owner vs. a proxy assigned by an admin • We are unwilling to open that can of worms • So an admin can delete a proxy that was assigned by the user, or vice versa. • User may create multiple proxies on his account, since an admin may do the same.

9. Design decisions • Proxies may be assigned to types of Individual other than foaf:Person • This must be configurable by installation • Is it time to think beyond deploy.properties? • In VIVO, we are thinking just People and Organizations. • Vitro doesn’t even include foaf:Person

10. Design decisions • User manages proxies through “My Account” page. • It could be argued that this belongs on the Individual page instead. • We felt that “My Account” is the natural place where the user would look to find this functionality.

11. image

12. Design decisions • Admin manages proxies through a new page • While this seems like a User Accounts function, it actually links Accounts and Individuals. • The UI is sufficiently complex to require its own page.

13. image

14. Design decisions • This will not use N3 editing. • This is quite idiosyncratic. • The N3 editing is not ready (?)

15. Design decisions • Accomplish as much as possible on a single page • Refreshing as necessary to display new information

16. image

17. Design decisions • Two “mirror-image” views are available. • List all profiles for each proxy (default) • List all proxies for each profile • These are also available as search results • Search for proxies • Search for profiles

19. Comments? • These slides are attached to NIHVIVO-2342 • Drafts of wireframes are attached to NIHVIVO-3212 • Please add comments to these issues, or send e-mail to Jim, Tim or Manolo