If a user has WRITE permission to an object, they should see this object in the list

[ttemnikova]

Expected behavior

A user with WRITE permission only should see the object in the list of objects of this type (i.e. WRITE permission should be like READ+WRITE)

Actual behavior

The user with WRITE permission but without READ permission can access the object via a direct link, but does not see this object in the list (e.g. cohort characterization analysis in the list of cohort characterizations)

Steps to reproduce behavior

1. user1 creates an object (concept set, cohort definition, characterization, pathways, incidence rates, PLE or PLP)
2. user1 grants WRITE permission to the object to user2, but does not grant READ permission
3. user2 opens a list of objects of this type

[anthonysena]

From discussion today on the Atlas/WebAPI developer subteam call, this should be addressed by the work done by @rkboyce on #2316 which adds a new Atlas "read only" user role which should prevent this behavior.

[chrisknoll]

I think the solution is here:

                if (Objects.equals(authorizationInfo.getUserId(), entity.getCreatedBy().getId())){
		    hasAccess = true; // the role is the one that created the artifact
		} else {
                    EntityType entityType = entityPermissionSchemaResolver.getEntityType(entity.getClass());

                    List<RoleDTO> roles = getRolesHavingReadPermissions(entityType, entity.getId());

                    Collection<String> userRoles = authorizationInfo.getRoles();
                    hasAccess = roles.stream()
                            .anyMatch(r -> userRoles.stream()
                                    .anyMatch(re -> re.equals(r.getName())));
                }

The initial IF that checks to see if you are the owner then you have read access can be modified to additional check if you have WRITE access (call over to hasWriteAccess()).

[rkboyce]

This is not an issue that will affect organizations who want to use the read-restricted role because we have now documented on the wiki (which we will point to in the release note) the use case and preparation required for using the new feature. However, the issue is noted in the wiki with discussion.