This is the first release of the Sponsor System to be made available to departmental sponsorship administrators. It marks the official release of this system to the campus community.
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.3-4.
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.
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 imported a file that includes errors—data omitted in some rows—you saw a screen that allowed you to "Fix Errors." If you fixed one error and saved, then went on to "Edit" a second identity (one without obvious errors), the error message from the previous fix persisted. This no longer happens (Ticket 27)
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 needed to make sure that inactive uniqnames are reactivated upon sponsorship. A manual process was implemented for doing this. (Ticket 49)
Middle name was not displaying in the search results. It has now been added. (Ticket 63)
After creating an identity, the Sponsor System now displays the identity's entity ID/UMID number and its directory ID number. (Ticket 64)
The default sponsorship length for Temporary Staff should be one year. The Sponsor System was showing it as 30 days. It has been changed to one year. (Ticket 76)
If a Type 1 sponsorship was created for someone with an existing UMID and then the non-UMICH e-mail address was deleted, two error messages instead of one appeared. This has been corrected. (Ticket 77)
The Sponsor System was handling a response code returned by SMBIO in a way that resulted in creation of a duplicate ID. This has been fixed. (Ticket 82)
The Sponsor System was sending individual e-mail notifications to each sponsored individual when sponsorships are created using file import. ITCS Accounts Office staff and departmental requesters asked that this not happen. The e-mail notifications to sponsored individuals have been turned off when sponsorships are set up using file import. (Ticket 88)
The Sponsor System was sending individual notifications to the requester for each sponsorship created using the file import process. This meant multiple messages for the requester, which has proven annoying. E-mail notification to the requester for sponsorships created using file import has therefore been turned off. (Ticket 92)
A "null pointer" issue was causing some searches to result in a Java StackTrace error. The issue has been resolved. (Ticket 107)
When a sponsorship administrator began the sponsorship process, searching to see if the person is already in the system, and searched on a very common name, the administrator was informed that there were too many search results to display and was instructed to narrow the search by entering additional search criteria. However, if the administrator was creating a sponsorship with a weak identity and a temporary uniqname (a Type 3 sponsorship), it was impossible to enter any search criteria other than first and last name. Then the administrator was stuck and unable to continue the sponsorship process. Now the search looks only at the Sponsor System (and not at M-Pathways) for Type 3 sponsorships. This prevents the error. (Ticket 108)
When a user edited a sponsorship and saved the changes, an error resulted regarding sponsorship start and end dates. This has been fixed. (Ticket 110)
If a user searched for requester and entered numbers instead of letters, the screen went blank. Now an error message is displayed. (Ticket 112)
Validation rules for first name were different in the create and update screens. The result, when a user accidentally entered invalid data in the first name field, was two error messages. This has been corrected. (Ticket 113)
To speed data entry, "United States" was made the default country for the home contact section. (Ticket 117)
Date of birth and middle name did not always persist from screen to screen during the sponsorship creation process. This has been corrected. (Ticket 119)
Quck search results were different using Internet Explorer as compared to when using other web browsers. This has been corrected. (Ticket 122)
If an apostrophe was included as part of a last name, it was being interpreted as a number and therefore invalid data during sponsorship creation. Also, leaving the non-UMICH e-mail address field blank was resulting in duplicate error messages. These issues have been resolved. (Ticket 123)
When middle name was added to the search results, a new problem was inadvertantly introduced. The row of info (i) buttons on the right was obscured by the Sponsorship Information box. This has been resolved, and those buttons are once again viewable and clickable. (Ticket 126)
For clarification, the attribute "Mais Email" in the M-Pathways tab of the info box available from the search results was renamed "E-Mail Address." (Ticket 127)
Changes were made to the OTID letters to accommodate the need for new employees to fill out an I-9 form in Wolverine Access prior to their first day of employment. (Ticket 128)
The error message that people who are not sponsorship administrators see if they try to access the system was rewritten. It now informs people that only sponsorship administrators can use the Sponsor System and directs them to the application form. (Ticket 129)
When creating a sponsorship using Internet Explorer, the state field as part of address was not available. This has been corrected. (Ticket 131)
Some text changes were made on the Provide Person Information page to make the labels clearer. (Ticket 132)
UMID was only showing on the confirmation screen when one was created. This has been changed so that UMID is also displayed if one already existed. (Ticket 133)
Data from the Sponsor System was being displayed on the Dearborn tab of the information box. This has been corrected. It now appears on the Sponsor System tab. (Ticket 134)
The search results page that appears during creation of a sponsorship has a series of blue info (i) buttons. After clicking one of these, a window appeared with a row of tabs that overlapped. This looked bad, so the width of the window was increased to prevent the overlapping. (Ticket 135)
If a user tried to do an advanced search on an invalid sponsorship administrator, instead of seeing the "0 Matches" screen in the right-hand pane, the pane was completely blank. There is now an error message instead. (Ticket 137)
If a user tried to do an advanced search on an invalid start date (such as letters instead of numbers), instead of seeing the "0 Matches" screen in the right-hand pane, the pane was completely blank. There is now an error message instead. (Ticket 139)
NOTE: Ticket numbers are from our FootPrints tracking system. They are included here for the use of project staff only.
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. The error page should inform the user that the file is in 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)
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)
A problem occured that resulted in two uniqnames having the same UMID. We're still investigating whether this was an anomaly or not. (Ticket 60)
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)
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)
There 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 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)
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)
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)
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)
Need to update SpringLdap version 1.2 to the new SpringLdap version 1.3. (Ticket 121)
A search from the Quick Search box returned an editable entry with no sponsorship data; the uniqname could be changed, which should not happen. Also, the search results varied depending on which web browser was used. (Ticket 124)
There appears to be a discrepancy in how the session timeout occurs. A tester returned to a session after some time had elapsed and worked through two or three pages before being notified that the session had timed out. (Ticket 125)
We need a more automated process for granting access to the system to new sponsorship administrators. (Ticket 130)
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)
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)
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 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 provide support to sponsorship administrators across all three campuses.
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.
