XCI-691 Testing Feedback

22 posts / 0 new
Last post
XCI-691 Testing Feedback

Please post test feedback as replies to this message.

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.



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:

  1. Test 3 -- I made the email change at 4:03pm yesterday and checked several times after an hour and didn't see the change.  This morning I logged in and saw the change though.  Should it take more than an hour to propagate?  When I switched it back this morning, I changed it at 10:25am and as of now it is already changed (little over an hour).
  2. Test 4 - after I onboarded a test account I have, the new entry showed up twice in the search results but pointed to the same entry (see my test log for screenshot)
  3. Test 6 -- I had same question as JP about WBS groups but otherwise it worked fine.  We'll reply in other thread.

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:

  1. Can we make it more transparent using a JIRA/Confluence provisioner log entry, user documentation, or some other way, when removing a user from JIRA or Confluence user's doesn't deactivate them because they own a JIRA project or for some other reason? Maybe the provisioner should log the failure and return the user to the appropriate group?
  2. If a user is removed from JIRA users and their JIRA account is deactivated, but the continue to be in the Confluence users group, will they be able to access Confluence with an inactive JIRA account? I had no way to verify what happens in testing.

My testing log is here.

All tests PASSED except Test 8 because Majordomo integration isn't done.

Log in to post comments