The MCommunity Sponsor System allows authorized U-M staff members to create online identities, including uniqnames, for people who are affiliated with the University but who do not appear in any of the official University data feeds. Sponsored individuals include, for example, conference attendees, contractors, incoming faculty who need access to U-M resources before the hiring process is complete, guests who need wireless access, and others.
MCommunity Sponsor System Version 1.0, released October 30, 2008, to staff members in the ITCS Accounts Office.
The web interface to the Sponsor System will work with these web browsers. It supports the current version of each plus the version immediately preceding that. It may work with other browsers and versions, but it has not been tested with others.
Safari for Mac OS X v10.4-10.5 (3.1.1 and 3.1.2)
Safari for Windows XP and Vista ( 3.1.1 and 3.1.2)
IE 7 for Windows XP (7.00.5730.1100 and 7.0.5730.13)
IE 7 for Windows Vista (7.0.6001.18000 and 7.0.6000.16386)
IE 6 for Windows XP (6.00.2900.2180 and 6.00.2900.5512)
Mozilla Firefox3 for Mac OS X 10.4 and above and Windows (3.0 and 3.01) Note: current version is now 3.0.2.
Mozilla Firefox2 for Mac OS X and Windows (2.0 and 2.0.0.16)
User can create a sponsorship. The system
Searches the MCommunity Registry for existing identities.
Searches M-Pathways for existing identities with regular uniqnames.
Either sponsors an existing identity or allows creation of a new, single sponsored identity.
Allows a file of identities to be imported for sponsorships involving weak identities and temporary uniqnames.
Generates e-mail confirmation to sponsored identity and requester.
User can edit sponsored identities. The system
Offers a quick search for finding an existing identity with a sponsorship.
Offers an advanced search that allows the user to find, based on additional search criteria, an existing identity with a sponsorship.
Allows edits to a single sponsored identity.
Allows edits to multiple identities that share a sponsorship.
Allows the user to reset passwords for sponsored individuals with weak identities.
Sponsorships expire on their expiration dates.
Programmatic access is provided through a Web Service. This is being piloted by MCIT for creating sponsored identities with business reasons that result in weak identities and temporary uniqnames.
Integration with Cosign for user authentication.
Integration with the M-Pathways Search Match Bio (SMBio) Web Service to allow the Sponsor System to check to see if the person being sponsored already has a U-M identity record.
Integration with Kerberos for creating a Kerberos principle (and a uniqname and password) and for doing password resets.
Integration with unserver to synchronize uniqnames created by MCommunity with those in legacy systems
Integration with AFS for creating a VICE ID.
Integration with Sentinel, Novell's auditing and monitoring system.
We are using a work-around for file-import creation of temporary uniqnames when a non-UMICH address cannot be obtained for every participant. Conference organizers are unlikely to be able to collect non-UMICH e-mail addresses for all participants, but the system requires one. The Accounts Office will use the Purge Mailbox address as a placeholder in this situation. This will give the Accounts Office an opportunity to monitor some of the e-mails sent by the Sponsor System and allow for temporary uniqnames to be created from file imports even when the people to be sponsored do not have an e-mail address. This is a temporary measure, and we would like to move toward collecting non-UMICH e-mail addresses for all sponsored individuals. We recognize that units will need some time to transition to routinely requesting this information.
Need a summary message for requesters when people are sponsored using file import. At the end of the file import process, the requester receives a confirmation e-mail for every sponsored individual. This needs to be changed so the requester receives one message that lists all the sponsored people.
Need to separate notification to sponsored individuals from notification to groups of sponsored individuals when using file import. Right now, the same mechanism is used when individual sponsorships are created and when multiples are creating using file import. These need to be separated so we can turn one off and not the other.
If you view a person's entry in the Sponsor System (the View & Modify Existing People page), and print that page, some text shows up in the printout that should not be there. The text is in the left-hand margin and is the help text that provides definitions of the fields. The text does not appear on the screen. It only appears when you print the page.
An error screen is needed for the situation where an administrator tries to add a sponsorship that requires a strong identity and regular uniqname to a sponsored person with a temporary uniqname. (The appropriate thing is to let the temporary uniqname expire and create a new sponsorship with a regular uniqname; we just need the error message to let people know this.)
The system does not validate non-UMICH e-mail addresses to make sure they don't end in @umich.edu.
When someone with an inactive uniqname is sponsored, the uniqname remains inactive, which can lead to problems such as creation of a new uniqname instead of using the existing one. We need to make sure that inactive uniqnames are reactivated upon sponsorship.
System currently allows administrators to sponsor themselves; it should not allow this.
System currently does not stop administrators from changing sponsorships for sponsorships outside the units for which they are authorized. This is not a problem while Accounts Office staff are the only users, but it must be corrected before departmental administrators begin using the system.
Identities from M-Pathways with COBRA ID numbers are being displayed in Sponsor System searches; they should not be found and displayed. For now, Accounts Office staff can recognize these because they begin with a "C," and they know not to sponsor any of these IDs.
Sponsor System should display one row per UMID in search results. It sometimes displays two rows for a single UMID if the person's name is listed differently in different data sources.
On quick searches by first and last name, the system sometimes returns identities where the person's middle name matches the first name provided in the search criteria. It should only return first and last name matches.
Search results do not always display existing UMIDs.
For start and end dates, all four digits of the year are required. If the user enters two digits, the system begins the year with 00 (for example, 0008). Either the user should get a more helpful error message (current message warns that date must be today or later) or the system should default to 20??. Or both.
If a user searches for an identity, finds it, and attempts to edit the description field, some inappropriate error messages show up.
If a user searches for an identity, finds it, and attempts to edit the start date that is invalid, unhelpful error messages appear. Instead, the system should not allow entry of start dates in the past.
The file import process requires a file in .csv format. If the user tries to upload a .doc file, an unhelpful error page appears, and it is difficult for the user to back out of the process. Error page should inform the user that the file is the wrong format and provide a way to go back to the file upload page.
We need a mechanism by which sponsorship administration privileges come up for regular renewal by the sponsorsing authority. Those that are not renewed then need to expire.
Duplicates are created for alumni whose OUD records don't have UMIDs. Alumni who graduated before the mid 1990s do not have UMIDs included in their OUD records, even though they do have UMIDs in their old, inactive MAIS student records. When a sponsorship administrator tries to sponsor such an alum, the initial search for existing records brings up two records, one from MAIS and one from OUD. The two records do not match completely because of the UMID issue. Whichever record is selected to sponsor, the result is a duplicate entry, either in M-Pathways or in the MCommunity registry. We need to somehow get all the records aligned so that duplicate entries don't get created. Alumni should create their own uniqnames through the Alumni Association website anyway.
If you sesarch for a preferred name, the record is found, but only the legal name is displayed in the search results. This makes it difficult to know that you found the right record.
Middle name does not display in the search results, and it should.
On the confirmtion screen that you see after creating a sponsorship with a strong identity, the UMID number is not diplayed, and it hould be.
The Sponsor System will not require state and zip for non-US addresses.
After creating an identity, the Sponsor System will display the identity's entity ID and directory ID.
Country and state codes will be added to the Sponsor System's user interface. (Until then, a paper copy of codes will be provided to Accounts Office staff.)
Administrators will be able to set the Sponsor System to omit sending an e-mail for every identity created (avoiding multiple e-mail messages sent to the requester).
A non-UMICH e-mail address will not be required for each sponsored person for file-import creation of multiple temporary uniqnames.
Expand the Web Service option for creating sponsorships to all sponsorship types (Version 1 only allowed its use for sponsorships with weak identities and temporary uniqnames).
OTID and self-registration process for sponsored people who receive regular (not temporary) uniqnames.
Expand the file-import option so it can be used for all sponsorship types (Version 1 only allowed its use for sponsorships with weak identities and temporary uniqnames).
Add the ability for sponsorship administrators to set preferences.
Provide programmatic access to and command line tools for the MCommunity infrastructure.
Provide reports for sponsoring authorities. The reports would cover the activity of their sponsorship administrators.
See MCommunity Sponsor System Documentation for descriptions of and links to all the published documentation for the MCommunity Sponsor System.
The ITCS Accounts Office staff members will provide support to sponsorship administrators across all three campuses after the Sponsor System is made available to them. The first release is being made available only to the Accounts Office.
Accounts Office staff members can escalate any issues they cannot resolve to the MCommunity Operations Team. Sponsorship administrators outside the Accounts Office will be referred to the Accounts Office for assistance if they contact the Operations Team directly.
