When upgrading, a sysevent_script_action.* Read ACL is automatically created with required role 'maint'<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #6e9db4; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: 500px !important; width: auto; height: auto; } } Issue When upgrading to Yokohama, a read acl with required role = 'maint' is created for sysevent_script_action is automatically created, preventing even admin users from viewing records. Symptoms System property 'com.glide.security.strict_read_roles' is trueACL is created by 'system' Release Yokohama Cause When 'com.glide.security.strict_read_roles' is true, wildcard ACLs are automatically created where field-level read ACLs exist. This is legacy behaviour. The current recommendation is to set 'com.glide.security.strict_read_roles' to false, but it is not automatically set on existing instances. For details, see: KB1204813 Resolution Set com.glide.security.strict_read_roles to false (confirm there are no unexpected impacts in a sub-prod environment)Create a new sysevent_script_action.* read ACL with required role = admin