The Sponsor System continues to be available only to the ITCS Accounts Office.
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.2.
No changes from the initial release.
No changes from the initial release.
NOTE: Ticket numbers are from our FootPrints tracking system. They are included here for the use of project staff only.
Country codes will be added to the Sponsor System's user interface. (Until then, a paper copy of codes has been provided to Accounts Office staff.) (Ticket 17)
If a user searched for, found, and selected a sponsored identity then entered an invalid end date (end dates must be in the future) while editing it, multiple, repetative error messages appeared. This has been corrected. (Ticket 21; was resolved as part of Ticket 102)
If an existing identity with a uniqname is sponsored, the e-mail that is sent to the requester failed to include the uniqname and appeared with $login$ instead. This has been corrected for sponsorships with regular uniqnames, and the e-mail now displays the existing uniqname. This has not yet been corrected for sponsorships with temporary uniqnames. (Ticket 47)
Users were unable to modify search criteria without re-entering sponsorship information because of a size limit on the search result. This has been corrected. (Ticket 68)
Problems in search results based on birth date were resulting in creation of duplicate identities because some existing identities matching birth date were not found. This has been corrected. (Ticket 83)
Searching by name (before creating a sponsorship) was returning more Emplids in the M-Pathways test environment than from the Sponsor System; the results should match. Data was coming from the Registry instance of the data source instead of from the respected data source. This has been corrected. (Ticket 84)
Added state codes as a drop-down selection. (Ticket 91)
A logging rotation error was fixed. (Ticket 99)
There had been an increase in failures of the advanced search. In some cases, users were redirected to the U-M Gateway page instead of seeing their search results. An error page alerting the user that the search timed out has been implemented. (Ticket 101)
A confusing error message resulted from entry of an invalid sponsorship end date. This has been corrected. (Ticket 102)
A failure in the advanced search when searching by administrator or requester that was caused by an issue with the search buffer has been corrected. (Ticket 103)
A typo in the search error screen has been fixed. (Ticket 104)
First name and last name are not capitalized on redisplay even though they are matched on the search. (Ticket 120)
NOTE: Ticket numbers are from our FootPrints tracking system. They are included here for the use of project staff only.
If a user searches for, finds, and selects a sponsored identity then enters an invalid end date (end dates must be in the future) while editing it, multiple, repetative error messages appear. (Ticket 21)
Entering an invalid department or uniqname (in the Admin field) in the advanced search causes blank fields or a blank results pane. (Ticket 25)
If you import a file that includes errors—data omitted in some rows—you'll see a screen that allows you to "Fix Errors." if you click on this and fix one error and save, then go on to "Edit" a second identity (one without obvious errors), you find the error message from the previous fix persists. (Ticket 27)
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. (Ticket 28)
Duplicates are created for alumni whose Office of University Development (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 rather than getting a uniqname via the Sponsor System. (Ticket 39)
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. (Ticket 49)
If a sponsorship with a temporary uniqname is set up for someone who happens to be alumni, a regular uniqname is created. Alumni should not be sponsored as a means of getting a unqname. They should instead visit the Alumni Association website to create their own uniqname. Once they have a uniqname, a sponsorship can be added to their identity. (Ticket 56)
When a user enters a requested uniqname but makes an error elsewhere in data entry and sees an error message, the uniqname originally entered disappears. The entered data should remain. (Ticket 57)
If you search 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. (Ticket 62)
Middle name does not display in the search results, and it should. (Ticket 63)
System allows numbers to be entered in the first and last name fields when creating sponsorships with weak identities and temporary uniqnames. (Ticket 70)
When a new sponsorship with a strong identity and regular uniqname is created, two "show password" buttons appear. One works, one does not. The non-working button needs to be removed. (Ticket 72)
If a user does an advanced search, finds a previously created type 1 identity, and attempts to edit that identity, they system gives the error: "The sponsorship start date must be today or any date in the future." (Ticket 74)
The default sponsorship length for Temporary Staff should be one year. The Sponsor System currently shows it as 30 days. (Ticket 76)
If a Type 1 sponsorship is created for someone with an existing UMID and then the non-UMICH e-mail address is deleted, two error messages instead of one appear. (Ticket 77)
Theew is a problem with the search result set being dependent on drivers. (Ticket 85)
There are some differences in SMBIO and the Sponsor System search mechanism that need clarification and resolution. (Ticket 86)
The Sponsor System sends individual e-mail notifications to each sponsored individual when sponsorships are created using file import. The e-mail notifications to sponsored individuals need to turned off when sponsorships are set up using file import. (Ticket 88)
Sponsor System is imposing a 32-character limit on non-UMICH e-mail address. This needs to be increased to match the 70-character limit that M-Pathways uses. (Ticket 97)
Before the next release (1.3, which will be made available to departmental sponsorship administrators), we need to provide all people who have completed the process to become sponsorship administrators with access to the Sponsor System and make sure they are authorized to sponsor for the appropriate departments. (Ticket 105)
A "null pointer" issue was causing some searches to result in a Java StackTrace error. (Ticket 107)
When a sponsorship administrator begins the sponsorship process, searching to see if the person is already in the system, and searches on a very common name, the administrator is informed that there are too many search results to display and instructed to narrow the search by entering additional search criteria. However, if the administrator is creating a sponsorship with a weak identity and a temporary uniqname (a Type 3 sponsorship), it is impossible to enter any other search criteria than first and last name. Then the administrator is stuck and unable to continue the sponsorship process. (Ticket 108)
When a sponsorship administrator begins the sponsorship process, searching to see if the person is already in the system, and searches on a very common name, the administrator is informed that there are too many search results to display and instructed to narrow the search by entering additional search criteria. However, for sponsorships with strong identities (Types 1 and 2), typing more information into any of the available fields does not result in a list of names to select from. The error message continues to display. (Ticket 109)
When a user attempts to edit the name of an identity and clicks "Save Information," they get an error message saying the sponsorship start date is invalid. Multiple versions of the error message may appear. The system seems to be expecting the start date to be today or later, even though the sponsorship was originally set up in the past with a valid start date. (Ticket 110)
If a user is creating a set of identities using the file upload, and the file to upload is poorly formatted (if, for example, the data in the file is outside the accepted columns), the user gets an error message that does not help them figure out what is wrong. (Ticket 111)
If a user enters numbers instead of text in the advanced search for requester, administrator, or department or enters text instead of dates for start date, the system generates a blank page instead of an error message. (Ticket 112)
In the View & Modify Existing People screen (after using search to find the identity), if a user accidentally types invalid information in the first name field, they get two error messages that say the same thing. (Ticket 113)
When creating an identity, if a user adds an SSN for an identity that is already in use, the error message is "Error creating entity in M-Pathways." This doesn't help the user figure out what's wrong. A more specific message, such as "SSN is already assigned to another identity" would be better. (Ticket 114)
The system allowed an in-use uniqname to be assigned to a new person. This may be because JKservices was down. (Ticket 115)
When a sponsorship was created while JKservices was down, a uniqname was not assigned to the identity and an e-mail message was sent to the sponsored individual and the requestor without the uniqname. (Ticket 116)
Date of birth and middle name do not always persist from screen to screen during the sponsorhip creation process. (Ticket 119)
Need to updte SpringLdap version 1.2 to the new SpringLdap version 1.3. (Ticket 121)
Search results differ depending on which browser is used, Firefox or IE. For now, we recommend use of Firefox. (Ticket 122)
NOTE: Ticket numbers are from our FootPrints tracking system. They are included here for the use of project staff only.
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. These multiple messages will be stopped in Version 1.3. We would still like to provide a summary notification as an enhancement at some point. (Ticket 9)
The system does not validate non-UMICH e-mail addresses to make sure they don't end in @umich.edu. However, adding the validation might make it difficult for people who don't have non-UMICH e-mail addresses. We will continue to allow @umich.edu addresses in the non-UMICH e-mail address field for the foreseeable future. Note that this affects both single and multiple sponsorship creation. (Ticket 19)
Provide reports for sponsoring authorities. The reports will cover the activity of their sponsorship administrators. (Ticket 32)
We need a mechanism by which sponsorship administration privileges come up for regular renewal by the sponsoring authority. Those that are not renewed then need to expire. (Ticket 38)
Sponsorship administrators need some choices when selecting/creating a uniqname (for regular, not temporary, uniqnames). (Ticket 48)
Need to separate notification to sponsored individuals from notification to groups of sponsored people 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. (Ticket 89)
After creating an identity, the Sponsor System should display the identity's entity ID/UMID and directory ID. (Ticket 90, Ticket 64)
The Sponsor System sends individual notifications to the requester for each sponsorship created using the file import process. This means multiple messages for the requester, which has proven annoying. We need to turn off e-mail notification to the requester for sponsorships created using file import. (Ticket 92)
Expand the Web Services option for MCIT for creating sponsorships to all sponsorship types. The initial release of the Sponsor System only allows its use for sponsorships with weak identities and temporary uniqnames. (Ticket 93)
OTID and uniqname self-registration process for sponsored people who receive regular (not temporary) uniqnames. (Ticket 94)
Expand the file-import option so it can be used for all sponsorship types. (The initial release of the Sponsor System only allowed its use for sponsorships with weak identities and temporary uniqnames). (Ticket 95)
Add the ability for sponsorship administrators to set preferences. (Ticket 96)
Provide programmatic access to, and command line tools for, the MCommunity infrastructure. (Ticket 98)
Consider adding a prompt to search by any former names as well as current name when doing the search prior to creating a sponsorship in an effort to reduce creation of duplicate IDs. (Ticket 100)
Create a process for ensuring that access is set up for people who become new sponsorship administrators. This process should include providing them with links to documentation and information about their responsibilities. (Ticket 106)
Consider making United States the default country when the user selects a country from a drop-down menu. Otherwise, the user must scroll all the way to the bottom of the list to select it. (Ticket 117)
Consider providing a field for searching by UMID in the initial search-match before setting up a sponsorship. Accounts Office staff say that sponsorship administrators often have a UMID for someone they want to sponsor, and it would prevent creation of duplicates if they could search by UMID to find the correct entry to sponsor. (Ticket 118)
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.
