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.6
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.
Added a summary confirmation message for requesters when people are sponsored using file import. When the Sponsor System was first released, at the end of the file import process, the requester received a separate confirmation e-mail for every sponsored individual. All these individual messages were unwieldy, so the confirmation-of-sponsorship messages were turned off for sponsorships created with file import. Now, the system sends one confirmation notice to the requester listing all the sponsorships. (Ticket 9)
The file import process requires a file in .csv format. If the user tried to upload a .doc file, an unhelpful error page appeared, and it was difficult for the user to back out of the process. The error page now informs the user that the file is in the wrong format and provides a way to go back to the file upload page. (Ticket 28)
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. This has been fixed. (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 made it difficult to know that you found the right record. This has been corrected. (Ticket 62)
The system was allowing numbers to be entered in the first and last name fields when creating sponsorships with weak identities and temporary uniqnames. This is no longer allowed. (Ticket 70)
When a new sponsorship with a strong identity and regular uniqname was created, two "show password" buttons appeared. One worked, one did not. The non-working button was removed. (Ticket 72)
If a user did an advanced search, found a previously created Type 1 sponsorship (strong identity and regular uniqname), and attempted to edit it, the system gave the error: "The sponsorship start date must be today or any date in the future." This has been fixed. (Ticket 74)
Needed to separate notification to sponsored individuals from notification to groups of sponsored people when using file import. The same mechanism was used when individual sponsorships were created and when multiples were created using file import. These were separated so we can turn one off and not the other. (Ticket 89)
There are some differences in SMBIO and the Sponsor System search mechanism that needed clarification and resolution. This has been taken care of. (Ticket 86)
The Sponsor System was imposing a 32-character limit on non-UMICH e-mail addresses. This limit was increased to match the 70-character limit that M-Pathways uses. (Ticket 97)
When a search returned more than 3,800 results, the result was an LDAP server (cache) error. This was corrected, and now if too many search results are returned, the user is prompted to narrow the search criteria. (Ticket 103)
When a sponsorship administrator began the sponsorship process, searching to see if the person was 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 instructed to narrow the search by entering additional search criteria. However, for sponsorships with strong identities, typing more information into any of the available fields did not result in a list of names to select from. The error message continues to display. The error message now instructs the user to contact he Accounts Office for assistance in narrowing the searcy. (Ticket 109)
If a user was creating a set of identities using the file upload, and the file to upload was poorly formatted (if, for example, the data in the file was outside the accepted columns), the user got an error message that did not help them figure out what was wrong. The error message is now more helpful. (Ticket 111)
When creating an identity, if a user added a Social Security Number for an identity that was already in use, the error message was "Error creating entity in M-Pathways." This didn't help the user figure out what was wrong. The system now passes on the error message generated by M-Pathways, which provides more information. (Ticket 114)
The system allowed an in-use uniqname to be assigned to a new person. This has been resolved. (Ticket 115)
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. This has been corrected. (Ticket 124)
When a user was creating a Type 1 sponsorship and using IE, the required data on the right did not update. The first item was checked, and all others were bullets, but items did not get checked off as the user added them. People using the Sponsor System via IE should have the same experience as those using Firefox; that is, as a user inputs required data, that data should be checked off in the "required data" box. This has been corrected. (Ticket 142)
The system did not allow two-character names (for create and edit). Now the system allows for names as short as one character (that is, it requires that the First Name and Last Name fields not be empty. (Ticket 149)
An error in the authorization logic that checks whether the sponsorship administrator's training flag has been set (that is, whether the administrator has completed Access and Compliance training) has been corrected. (Ticket 150)
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 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)
A problem occured that resulted in two uniqnames having the same UMID. This may have been an anomaly. (Ticket 60)
There is a problem with the search result set being dependent on drivers. When a driver is down, search results are affected. (Ticket 85)
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)
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)
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)
Multiple users can edit the same sponsorship simultaneously if they are using different browsers (e.g., Firefox and IE.) (Ticket 147)
Users are sometimes hitting a size limit exception when doing an advanced search on first name, last name, and requester. (Ticket 148)
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)
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 advance 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)
There is a need to use the file import process to create Type 1 sponsorhips (those with strong identities and regular uniqnames) from existing UMID/Emplid data imported to the Sponsored System. (Ticket 160)
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). (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)
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)
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)
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 need an administrative user interface to allow system administrators to add to the list of sponsorship administrators and authorities. (Ticket 165)
We need a user interface to allow sponsorship authorities to perform administrative tasks, an administrative interface. (Ticket 171)
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)
We need to create a sponsorship administrator role that is limited to creation of sponsorships with temporary uniqnames. Temporary staff could then be allowed to create sponsorhips for U-M hotel guests and meeting participants who need wireless access for brief periods of time. Because of the considerable responsibility, we require that full sponsorship administrators be regular staff. (Ticket 175)
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.
