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.1.
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.
The system did not provide an error message when an administrator tried to add a sponsorship that requires a strong identity and regular uniqname to a sponsored person with a temporary uniqname. This was resolved by not including weak identities in the search results of people available to be sponsored. (No ticket)
On the confirmation screen that you see after creating a sponsorship with a strong identity, the UMID number was not displayed. This has been corrected, and the UMID is now displayed. (No ticket)
The Sponsor System no longer requires state and zip for non-US addresses. (No ticket)
Date of birth now displays correctly in search results. (Ticket 1)
A problem with search results that was causing display of the wrong UMID and returning middle name matches instead of first name matches has been fixed. (Ticket 2)
COBRA IDs no longer appear in the search results. (Ticket 3)
Search results returned two rows for one person if one data source included a middle name and one did not. This has been corrected. Now one results row is returned per UMID. (Ticket 4)
Search results no longer display names where the middle name matches the searched-for first name. (Ticket 5)
The data included on the M-Pathways tab in the search results now includes the UMID. (Ticket 7)
The system no longer allows creation of uniqnames with less than three characters; it had been creating two-character uniqnames. (Ticket 10)
Problem of search results for a name not displaying a uniqname when one exists has been corrected. (Ticket 13)
Problem of search results not displaying a full name in some cases has been resolved. (Ticket 14)
Error message has been added for when the user does not enter all four digits of the year in a sponsorship start or end date; all four digits are required. (Ticket 16)
The Sponsor System no longer allows people to sponsor themselves. (Ticket 20)
The system has been allowing people to edit sponsorships for departments that they did not have permission to edit; that is, someone authorized only for Department X was able to edit sponsorships for Department Y. This has been corrected. (Ticket 22)
The system now prevents users from changing a start date to a date prior to the current day. (Ticket 23)
A wrong format in birthdate on a second sponsorship resulted in a system error. This has been resolved. (Ticket 26)
A search for a recently sponsored person was resulting in a redirect to the U-M Gateway page. This was a Cosign time-out issue. The issue has been resolved. If a person's Cosign credentials have timed out, they will see an error letting them know that has happened and that they need to log back in. (Ticket 30)
If you view a person's entry in the Sponsor System (the View & Modify Existing People page), and print that page, some text was showing up in the printout that should not be there. It only appeared when you print the page. This has been resolved. (Ticket 31)
The UI now makes it clear (by showing an inactive button) that you cannot use the Sponsor System to reset passwords for people with strong identities. (Ticket 33)
UMID was being pulled from the wrong field in the Registry (the UID field), resulting in errors. This has been corrected. (Ticket 34)
A time zone issue was resulting in errors when selecting the start date. This has been fixed. (Ticket 35)
Conflicts in the format of the Date of Birth attribute across the different data feeds were resulting in entries getting impounded. The format was modified in the Sponsor System, and this has been resolved. (Ticket 40)
Code was modified to perform a length check on uniqnames. This allows the program to respond in an acceptable way if there is corrupt data. (Ticket 41)
Text was added to the notification that goes to requesters that refers them to a web page where they can request computing services for the just-sponsored individuals. (Ticket 42)
System was not prompting user to type in a uniqname request when setting up a sponsorship for someone with a directory entry but no uniqname yet; it was just generating one. This has been resolved. (Ticket 45)
Emplid/UMID was not persisting in cases where one existed in the directory. This issue has been resolved. (Ticket 46)
XSLT style sheet was modified so that UMID is displayed in the event of an error page being generated. Previously, the error generation caused the UMID to be lost. (Ticket 51)
System can now handle multiple file imports at a time and reports errors (that is, when uniqnames other than those requested are created) appropriately to the user. (Ticket 53)
Attributes added to config file to fix the problem of identities not being found because of missing attributes. (Ticket 55)
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 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)
If an existing identity with a uniqname is sponsored, the e-mail that is sent (to the requester?) doesn't include the uniqname and appears with $login$ instead. (Ticket 47)
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)
Search results do not always display existing UMIDs. (Ticket 51)
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)
Some of the default end dates associated with sponsorships (e.g., Temp Staff and U-M Online) don't match the documentation. (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)
We are using a work-around for file-import creation of temporary uniqnames when a non-UMICH address cannot be obtained for every participant. The Accounts Office enters a placeholder Accounts Office address in these cases. The Governance Board requested that non-UMICH e-mail address be required for sponsorships with weak identities. Also, such an address will be needed for uniqname self-registration when it is added to the system. We will ask the Governance Board to re-evaluate whether non-UMICH e-mail addresses should be required for file imports or whether sponsorship administrators should be allowed to suppress the e-mail notifications to sponsored individuals. (Ticket 88; also Ticket 16 in Governance Board FootPrints project)
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)
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. This needs to be changed so the requester receives one message that lists all the sponsored people. (Ticket 9)
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)
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. This is related to Ticket 88 above under "Known Issues." (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)
Add state codes as a drop-down selection. (Ticket 91)
Administrators will be able to choose notification options for uniqname creation. For example, they 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). They will also be able to choose from options for notifying sponsored individuals of sponsorship expiry. (Ticket 92)
Expand the Web Service option for MCIT for creating sponsorships to all sponsorship types (Version 1.0 only allowed 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)
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.
