The negative-ACL Selenium tests intermittently failed with
StaleElementReferenceException (masked as a generic RuntimeException) and
a NullPointerException when reading a freshly-created role/permission row
that had not yet rendered.
Root causes and fixes:
- Several user-management RPCs were fired through a plain AsyncCallback, so
they were invisible to the pending-Ajax counter and waitForAjaxRequests()
returned before their deferred CellTable repaint ran. Wrap them in
MarkedAsyncCallback: createRoleDefinition, getRolesAndPermissionsForUser,
getUserList, addPermissionForUser, removePermissionFromUser and
removeRoleFromUser.
- Pair those marks with waitForAjaxRequests() barriers on the test side after
add/delete clicks (WildcardPermissionPanelPO, UserRoleDefinitionPanelPO).
The ...AndExpectPermissionError() variants deliberately click directly and
wait for the alert instead, since the RPC fails rather than completing.
- Add RoleDefinitionsPanelPO.findRoleWhenPresent(): wait for Ajax, then poll
until the row is present before returning it, and use it from
TestNegativeAcls so a not-yet-rendered row no longer NPEs.
- Stop CellTablePO/GenericCellTablePO from masking staleness: narrow
createEntry's catch to the exceptions the reflective construction can
actually throw, unwrap InvocationTargetException(StaleElementReferenceException)
and rethrow it, and retry getEntries() a bounded number of times so a
redraw-during-read is tolerated rather than surfaced as an opaque failure.
- PageObject.waitUntil now ignores StaleElementReferenceException.
Assisted-By: Claude Opus 4.8 (Claude Code)
header was too long. now uses "..." and full form on hover.
togglable checkbox not standard usage in this context. was replaced with
static text "Yes"/"No"
edit user dialog > opt out checkbox value was not initialized. corrected
The following commit was not checked properly. It was assumed to be a
merge with the main branch, but was actually a merge with a very stale
main branch with many conflicts that were then resolved manually.
1373405280
If null is passed to email subscription flag, nothing will be changed.
Previously, it was the case that null could not be passed, behaviorally
the same value as before would have to be reapplied in expected use
cases which could cause data consistency issues
Axel Uhl
Masha Kashirina
service-tip-git
Adrian Bollig
Sohaib Baig