Please post test feedback as replies to this message.
Research Software Portal
Provided by ACCESS
© ACCESS All Rights Reserved.
ACCESS is an advanced computing and data resource supported by the
National Science Foundation
and made possible through these lead institutions and their partners:
Carnegie Mellon University,
University of Colorado Boulder,
University of Illinois at Urbana-Champaign, and
State University of New York at Buffalo .
Administrative Login
I added several suggested changes to the Deployment Plan Draft News Announcement.
Acknowledged. Thank you.
In the schedule I was under the impression that WBS staff groups would be active in Jira/Confluence by April 30 and that the staff on-boading and off-boarding process would involve managing WBS groups using CoManage.
It's OK if additional groups, such as those used to grant JIRA and Confluence access are implemented after April 30.
I can configure COmanage so that each of the WBS "active" groups is provisioned to Jira (TEST). I didn't initially do that because I did not see any WBS groups in Jira currently (neither on TEST nor PROD).
If I do configure the WBS "active" groups to be provisioned to Jira (TEST), then the actual users in those groups in Jira will be the intersection of the WBS "active" group and the Jira Users groups in COmanage, since only those users in the Jira Users are provisioned to Jira (this fine-grained control allows, among other things, conservation of Jira licenses).
Can you confirm please that you want me to instantiate the configuration I described above? I can get it done probably tomorrow (Thursday, April 22).
Hi Scott,
JP and I both say yes to this -- please add WBS active groups to the JIRA stage deployment. They are ad hoc-ly defined in JIRA now and this will make it easier down the road even if not everyone adopts them right away.
Thanks!
Shava
All the WBS groups have been provisioned to Jira staging.
The onboarding enrollment flow detailed in the testing plan does ask the person driving the enrollment to select the primary WBS work unit for the enrollee. When the flow completes the enrollee is given a CO Person Role in the WBS COU, and hence winds up in the WBS "active" group.
Likewise, when a CO Person Role status is set to Expired as in the testing plan, then the user is removed from the WBS "active" group.
So both onboarding and offboarding are covered in the test plan.
Are we sure that for "Test 3 (XCDB Changes Are Reflected in COmanage and LDAP)" changing ones e-mail may not have other harmful side effects, even if temporary?
Otherwise, the testing plan covers all the initial functionality and is thorough.
I do not know if there are any harmful side effects to changing email address via the portal. I can say that both Jim and I did so during our own testing and it did not cause any issues for us. Through the TEST COmanage channel, the only possible effect is a change in the OpenLDAP directory and in the TEST Jira, but neither of those are used by downstream PROD services.
I've gotten all tests but Test 8 to work but I understand that this feature is likely not to be ready for this round of testing. Here's some questions:
Test 3 - I am looking into why the cron job that runs the XCDB synchronization does not appear to run consistently at every hour. I will report back when I know more
Test 4 - That the new entry shows up more than once is a known display bug in version 3.3.x of COmanage Registry. As you noted, the links point to a single CO Person Record. The display/rendering bug is scheduled to be fixed in version 4.0.0 of COmanage Registry, due late Q2 or early Q3.
Test 6 - Please see my response to JP's question about the provisioning of WBS groups into Jira, in particular let me know if you want me to proceed with provisioning the WBS "active" groups to Jira (they do not exist now in Jira, so the question is, are they required? Will they be used?)
Test 3 - I found a race condition caused by the cron configuration that caused the synchronization jobs to periodically not run. I have corrected the configuration and the synchronization jobs have run correctly at the top of each hour since.
Running Test 4: COmanage Enrollment for New XSEDE Staff Member using a test account (xsede=jnavarro) resulted in a properly onboarded user. However, there now appears to be 2 identical user entries for jnavarro and the jnavarro user isn't able to login to registry-test. See attached screenshots. Did something fail in this test?
That there are two listings for the same CO Person Record is a known display/rendering UI bug in COmanage Registry version 3.2.x. It is scheduled to be fixed in version 4.0.0, due out in late Q2 or early Q3. Note that it is just a display/rendering bug--only one CO Person Record was creating during the enrollment/onboarding.
The test user jnavarro cannot login to COmanage Registry because when you verified the email during the enrollment you did so using your navarro@xsede.org identity and so the eduPersonPrincipalName recorded was navarro@xsede.org and not jnavarro.
If you want to repeat the test please expunge user jnavarro and then repeat, but be sure to use a private browsing window with no pre-existing sessions for the email verification step and be sure to authenticate using jnavarro and not navarro.
Repeated following instructions correctly, and everything worked.
I updated the XCDB e-mail address for my testing account (jnavarro@xsede.org) 1 1/2 hours ago but see no change in COmanage. If it was Offboarded and Expired would it prevent COmanage from refreshing the e-mail address from XCDB? Just in case, I added it back to the WBS group so that it's Active and am now waiting to see if it will refresh the e-mail from XCDB.
That worked. I think that not refreshing Expired account details is probably OK.
For Tests 6 and 7 I added testing user jnavarro@xsede.org to Confluence Users and Jira users which successfully provision the user in jira-stage. However I removed shm7@xsede.org from the Confluence Users and Jira Users group and no changes to the jira-stage user's Jira account: the Jia account remains Active and the user is still in the jira-users group.
User shm7 cannot be deactivated because they are currently the project lead on these projects in Jira: CEETRAIN, TRAIN.
I have completed tests 1 through 7, and test 9, and they have all PASSED, with a couple of recommendations:
My testing log is here.
All tests PASSED except Test 8 because Majordomo integration isn't done.