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.7
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.
An enhancement was added that allows sponsorship administrators to check whether the uniqname they would prefer be created is available or not and to allow them to select from some available alternatives if it is not. This applies to regular (not temporary) uniqnames only. (Ticket 48)
There is a problem with the search result set being dependent on drivers. When a driver is down, search results are affected. This has been resolved. (Ticket 85)
A Web Service option for Medical Center Information Technology (MCIT) to use for creating sponsorships was added to the Sponsor System in July and was fine tuned with the August release. The Web Service is able to search M-Pathways (Wolverine Access) data to see if the identity being created already exists. If the identity already exists, the Web Service creates a sponsorship using the existing UMID (and uniqname if one exists); if not, it creates a new UMID and uniqname. The MCIT Web Service creates sponsorships with strong identities and regular uniqnames, but the process is capable of creating sponsorships with weak identities and temporary uniqnames. (Ticket 93)
A web user interface for adding new sponsoring authorities and sponsorship administrators was provided to the Accounts Office. The Sponsor System Administration Tool provides a web user interface for adding and removing sponsoring authorities and sponsorship administrators. It also provides a mechanism for linking the authorities and administrators with the ID numbers of the departments they are authorized to do authorization and administration for. Until now, this work had to be done manually by ITS system adminstrators. (Ticket 165)
When a user created a new sponsorship, the default date of birth was appearing in the wrong format (the month and day were switched). This has been corrected.
Improvements were made in the way address information is stored to ensure consistent formatting.
NOTE: Ticket numbers are from our FootPrints tracking system. They are included here for the use of project staff only.
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 M-Pathways student records. When a sponsorship administrator tries to sponsor such an alum, the initial search for existing records brings up two records, one from M-Pathways 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)
If a user tries to do an advanced search on an invalid department, instead of seeing the "0 Matches" screen in the right-hand pane, the pane is completely blank. There should be an error message instead. (Ticket 138)
When a user edits a sponsorship, if they change the country of the home contact from US to another country and remove the state information, when they save, the state information reappears. It should disappear. (Ticket 140)
When a user is creating a sponsorship and includes an invalid end date, they get an error message (as they should). However, the department disappears. The user is unlikely to notice this, and will get an error message when they've corrected the end date and attempted to continue sponsoring. The department listed should not disappear. (Ticket 141)
When a Type 3 sponsorship (one with a temporary uniqname) is added to an existing identity, the uniqname is not included in the confirmation message sent to the sponsor. (Ticket 143)
When a user does an advanced search and searches on requester, admin, or department, and then tries to search on some other criteria, the old search criteria reappear in the search fields. It doesn't look as if the old search criteria are reused. This appears to be a display issue. Deleted search criteria should stay deleted. (Ticket 146)
Users are sometimes hitting a size limit exception when doing an advanced search on first name, last name, and requester. (Ticket 148)
When a user tries to create a sponsorship and searches for an identity, if the identity is in M-Pathways and the MCommunity Registry, no information is appearing in the identity record when the user clicks the "i" for details. The information from M-Pathways should appear. (Ticket 154)
The Sponsor System needs a way to search M-Pathways that is not a "funnel" search. When a user tries to search on a common name with some other criteria to narrow (birthdate, address, etc), the search should not pull up the entire list of similarly named identities, even if no exact match is found. If no match is found, the search should give the results "no match" or give a list of the closest matches (a limited number of close matches). (Ticket 155)
After a user has created a sponsored identity with a temporary uniqname, when the user tries to edit the identity, the field for "Contact Information-Address 1" is not editable. You can see it, but you can't change it. (Ticket 158)
Need better error message for when a user does an advanced search by the start date and enters the date in a wrong format. Right now the error is, "Query too general." The tester recommends that it say, "Wrong date format" instead. (Ticket 159)
If, while creating a sponsorship, the user types an invalid uniqname into the "Requested uniqname" field, they get a green checkmark. This is likely to cause the user to believe the uniqname is available rather than unavailable/invalid. All unavailable uniqnames should be rejected (both those unavailable and those that are invalid). Additional uniqname-checking rules were applied in Release 1.7, but this issue has not yet been completely resolved. (Ticket 161)
Users currently can't include periods or parentheses in first or last names in the Sponsor System, but they are allowed to do this in M-Pathways. They should also be allowed to do this in the Sponsor System. (Ticket 164)
Users see different results depending on the web browser they are using (IE vs. Firefox). In IE, the country field, United States, is a default value already in the box. In Firefox, you use the pull-down list, and United States is the bottom choice, you then click on that value and Firefox fills in the value. (Ticket 166)
Recommended uniqnames listed as available should resemble the sponsored person's real name, but they don't. (Ticket 167)
The confirmation page needs text modifications. The term Entityid should not be used; UMID should be used instead. Recommended text: "UMID created in M-Pathways" and "DirectoryID created in MCommunity. (Ticket 168)
If a user edits a contractor sponsorship to change the end date of the sponsorship, the user sees a "Phone number invalid" error. The user has to remove the phone number in order to change the end date. (Ticket 169)
A sponsorhip administrator was able to sponsor herself. The system should prevent this. (Ticket 170)
The Accounts Office has reported a problem when using file import for Type 3 uniqnames for people who already have UMIDs (for example, conference attendees who get a UMID because they get a stipend before a uniqname is requested). The Accounts Office sets up the sponsorships at the request of the department, then the department informs the Accounts Office after the fact and after new UMIDs have been assigned by the Sponsor System, that the sponsorees already had UMIDs. Short-term fix: Added a place for UMID's in the spreadsheet people submit to request sponsorships from the Accounts Office. A longer-term fix within the Sponsor System itself is needed. (Ticket 185)
In the "Sponsor People" pane, under "Valid Dates," change "End" to "Expiry." Make the word "Expiry" a link to some help text that explains what happens when the sponsorship expires. (Ticket 240)
Could not verify uniqname was available or change uniqname when editing. For a Type 1 identity, clicking on "Check Availability" removed the option to change the uniqname at all. The same happened for a Type 2 identity. When editing a Type 3 identity (after doing an advanced search, selecting an identity, and clicking "Edit"), the screen appears to allow the user to change the uniqname, however, changing the uniqname doesn't work—after clicking "Save Information," the uniqname remains the same. Also, clicking "Check Availability" did nothing. (Ticket 277)
This situation occurs when a person already has a UMID but does not have a uniqname or any sponsorships and does not have an entry in the MCommunity Registry. The Sponsor System should find the M-Pathways entry and use that as the basis for sponsorship, the UMID should remain unchanged, and a uniqname should be created and included in the M-Pathways entry. However, the Sponsor System creates a new identity with the info from M-Pathways and a 99 UMID. It creates a uniqname associated with the 99 UMID and therefore does not send the uniqname to the M-Pathways entry. (Ticket 281)
When adding a Type 1 sponsorship (stong identity, regular uniqname) to an identity with a Type 2 sponsorship (weak identity, regular uniqname) only, the 99 UMID of the Type 2 sponsorship should be replaced by a regular UMID and an M-Pathways entry should be created, the uniqname should remain the same, and the result should be one sponsored identity with two sponsorships and a corresponding M-Pathways entry. However, the Sponsor System keeps the 99 UMID and does not create a real UMID. Therefore, an M-Pathways entry is not created. The confirmation screen says that an entry has been created in M-Pathways (but this is not true). (Ticket 282)
When a VIP or Associate becomes faculty, staff, or student, the uniqname should remain the same. However, there isn't enough identity information in the Sponsor System for the M-Pathways entry to match the Sponsor System entry. The result is a duplicate. We need to determine how to handle this and provide a way for the transition to occur. (Ticket 283)
Sponsor System can't find identities with no UMID or uniqname. When a user tries to create a sponsorship of any type, people in the MCommunity Registry who lack uniqnames and UMIDs do not show up as available to sponsor. (Ticket 286)
Sponsor System can't find some identities with UMID and uniqname. When a user attempts to find an identity in order to add a (Type 1 or 2) sponsorship, sometimes the identity is available and sometimes it is not. (Ticket 287)
When a user searches on an identity and reaches the "View and Modify Existing People" screen, under "reasons" the user sees "Faculty" if the business reason selected was "Incoming Faculty/Staff." The full name of the reason needs to be used, even if it needs to be abbreviated, to prevent confusion. (Ticket 290)
The sponsorship expiry notice should go to the requester rather than to the sponsorship administrator. (Ticket 292)
We need to make some text changes to the sponsorship expiry notice based on Ticket 292 above and also to make it clearer that access to computing services ends when the last sponsorship expires and, in most cases, those services cannot be reactivated after expiry. (Ticket 293)
If an identity is available through M-Pathways, but is not in the MCommunity Registry, and a user attempts to assign a Type 2 sponsorship (weak identity, regular uniqname) to that identity, the original UMID is replaced with a 99 UMID. The original UMID should remain. (Ticket 294)
When a user adds a Type 1 sponsorship (strong identity, regular uniqname) to a previously existing identity (that has a UMID and uniqname), if the user accidentally deletes the State (or any required data), and gets an error message that the data be added, the uniqname creation box inappropriately appears. If the user adds a new uniqname, the new one shows up in the Quick Search list, but the old one shows up in the "View and Modify Existing People" screen. (Ticket 297)
If a user selects an existing Identity from the search results for sponsorship creation, the Sponsor System populates a different date of birth. This problem is associated with entries coming only from M-Pathways. (Ticket 303)
Administrative Tool: When a user attemps to add a sponsorship administrator and enters a uniqname that does not exist, there is no error message explaining that the uniqname is not valid.
Administrative Tool: The user can add him/herself as a sponsorship administrator, yet the policy states no one can be both an authority and an administrator. (Ticket 388)
NOTE: Ticket numbers are from our FootPrints tracking system. They are included here for the use of project staff only.
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)
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. This covers such things as setting their own defaults if they always do the same type of sponsorship. (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)
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)
It would be helpful to have the file upload feature produce a file of all the sponsorships vs. having the information appear only on the screen (where you have to copy and paste it if you need it in a file). (Ticket 136)
We have been asked to consider changing "Home Street Address" to "Home Contact Information" in the Required Data Combinations box. Some users may be confused because more information is required than just the street address. (Ticket 151)
In the advanced search, users can search for department only by typing the name of the department. It would be nice if users could search by department number as well. (Ticket 152)
When a user is creating a set of sponsorships using file import and makes a mistake, the error page is a dead end. It would be nice to include a link back to the upload-identity screen from the error page. (Ticket 153)
There is a need to use the file import process to create Type 1 sponsorships (those with strong identities and regular uniqnames) from existing UMID/Emplid data imported to the Sponsored System. (Ticket 160)
The system should display the UMID on the confirmation page for sponsorships created via file import. (Ticket 172)
When an administrator does an advanced search, they are usually looking for the last few sponsorships they created. They would like the result set to be able to be sorted by date and, by default, to display the most recent sponsorships first. (Ticket 173)
Creating sponsorships via file import is currently limited to 50 sponsorships at a time, yet we have conferences at U-M with as many as 1,500 participants. We need ways to make it easier for people to create more than 50 sponsorships (with temporary uniqnames) at once. (Ticket 174)
Provide a way for sponsorship administrators to choose whether e-mail notifications are sent or not. This includes the confirmation sent to the sponsored individual, the confirmation sent to the requester, and the expiry notice. The default would be for the notices to be sent, but we would let sponsorship admins change this if they wish. (Ticket 314)
Administrative Tool: Users would likely find it helpful to search for multiple departments using a range of department ID numbers. This would mean adding the ability to search by range rather than by individual department IDs only. (Ticket 387)
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.
