Integration of Profiles API with "Person" Content Type

[danahertzberg]

User Storys

As a faculty member, I'd like to update my profile in one location and have it populate on all websites that pull in my information.

As a content admin, I'd like to give faculty the ability to update their own profile content without the need to go through me for my specific website.

Overview

Objective: Integrate the Profiles API to streamline data for faculty profiles, ensuring consistency, and making updates efficient.

Scope: The integration will occur in multiple phases to ensure a smooth transition and add enhanced features step-by-step.

Phases

Phase 1: Importing Data for individual Profiles that Maps to Existing Fields

• Objective: Import data from the Profiles API to existing fields in the "Person" content type without major data transformation.
• https://github.com/az-digital/az_quickstart/issues/3362

Phase 2: EDS/Grouper Integration

• Objective: Integrate with EDS and/or Grouper to automate profile creation and update processes.
• https://github.com/az-digital/az_quickstart/issues/35

Phase 3: Adding Experience Section

• Objective: Import additional experience-related data, such as employment history and awards, requiring new fields and updates to the profile display.

Phase 4: Teaching/Courses Section

• Objective: Import teaching and course-related data. Address how imported data should interact with the existing Courses content type.

Phase 5: Research/Publications Section

• Objective: Add fields for research contributions and publications. Address how imported data should interact with the existing Publications content type.

Other Considerations

• Faculty Editing Own Profiles: Note that faculty members may soon have access to edit their own profiles, which might influence editability settings and permissions.

[camikazegreen]

Update from Robbie MacPherson:

I met with Dr. Romero to discuss Phase I and the project in full.

Regarding, “Phase 1: Importing Data for individual Profiles that Maps to Existing Fields, she approves your use of any of the publicly displayed information in UA Profiles.

However, regarding Phase 5, allowing data imported from UA Profiles to be edited in local sites, she does not want to allow edits or changes to imported UA Profiles data, or faculty titles. There has been a lot of work put in to ensure faculty titles display in the proper order, and accurately reflect positions, rank, and track.

As we discussed, if faculty want to update profile information that originates from UA Profiles, they should be directed back to the system of record. This includes Annual Profile, UAccess Employee and UAccess Student. For example, if faculty need to edit their publications or biographies, they should be directed back to Annual Profile. For employee record changes, such as the phone number or campus address: UAccess Employee, course information: UAccess Student. This will not only maintain alignment with the systems of record (aka sources of truth) but will also help ease the support burden.

Regarding support burden, colleges using imported profile information should have a website function for contacting local support. This has been experienced, where we have had to troubleshoot all the way back to finding a particular support person at a college and alerting them. As you can imagine tracking this down wasn’t easy with turnover/anonymity and took away time from other priorities for my team.

If you have any follow up questions, please feel free to include Dr. Romero for discussion.