Hi anil kharat1,

The behavior you are seeing (redirecting to a "New" form) is occurring because your Query Business Rule creates a mismatch between List Visibility and Record Accessibility.

The Root Cause:

1. The List: Your custom Query BR forces the list to display records that the user technically does not have ACL access to (or modifies the query so the constraints are bypassed during the fetch).

2. The Form/Builder: When you click the record, the system loads the Content Builder UI page ($streamline_content_authoring.do). This page performs its own canRead() check on the target record.

3. The Mismatch: Since the underlying Read ACL still fails for that user, the Content Builder cannot load the existing data. Instead of showing an "Access Denied" error, the UI page fails gracefully by initializing in a "Create New" state (empty canvas), which is what you see in your screenshot.
   
   

The Solution: You should remove or disable the custom Query Business Rule. Manipulating the query to bypass "Security Constraints" is not recommended practice.

Instead, you need to satisfy the ACL (Access Control List) requirements for the sn_cd_content_base table:

1. Debug Security: Impersonate the user, enable System Diagnostics > Session Debug > Debug Security, and try to access the list/record.

2. Identify the Role: Check which Read ACL is failing. Usually, for Content Publishing, the user needs roles like sn_cd.content_manager, sn_cd.admin, or must be part of the specific Audience defined on the content record.

3. Grant Access: Assign the correct role or Group to the user. Once the ACL passes legitimately, both the "Security constraints" message in the list AND the "New Record" issue on the form will disappear.

Hope this helps!