improve unsearchableNodeIds node permission

[BomAle]

	/**
	 * Return either NULL for no restrictions, or a list of container IDs we cannot search in because of app specific permissions and configuration
	 * You do not need to check for 'view' permissions against the logged in member here. The Query search class does this for you.
	 * This method is intended for more complex set up items, like needing to have X posts to see a forum, etc.
	 * This is used for search and the activity stream.
	 * We return a list of IDs and not node objects for memory efficiency.
	 *
	 * return 	null|array
	 */
	public static function unsearchableNodeIds()

This function is useful but it don't cover parents permissions at this time.

I am here to suggest to integrate some other checks (into forum there is a check for min_posts_view) by default

massUpdate is a slow action, editing all index item, it cover all parents permissions... I suggest to define a immediate check:

- avoiding task routine

- improve user expirience on permissions

- third parts satisfaction when use inbuilt search class

$unsearchableIds = array();
if ( $this instanceof \IPS\Node\Permissions )
{
	$list = iterator_to_array(
		\IPS\Db::i()
		       ->select( static::$databasePrefix . static::$databaseColumnId, static::$databaseTable )
		       ->setKeyField( static::$databasePrefix . static::$databaseColumnId )
	);

	/* If we're trying to *read* a content item (or in fact anything, but we only check read since if we managed to access it we don't need to check this again for other permissions),
	check if we can *view* (i.e. access) all of the parents. This is so if an admin, for example, removes a group's permission to view (i.e. access) a node, they will not be able
	to access content within it. Though this is not in line with conventional ACL practices, it is how the suite has always worked and we don't want to mess up permissions for upgrades  */
	foreach ( $list as $id )
	{
		if ( !static::load($id)->can( 'view' ) ) //or read?
		{
			$unsearchableIds[] = $id;
		}
	}
	static::$unsearchableNodeIds = count( $unsearchableIds ) ? $unsearchableIds : NULL;
}

return static::$unsearchableNodeIds;

OR more easy:

disable/remove/save corresponding permissions on child nodes into form/module admincp when into a parent node is changed the permissions (massChange could help here)

example:

if i don't have permission on parent node because on permission sets of the child node i do?

@Matt @bfarber

[TSP]

If anything, for performance reasons, I think this should be handled on save of permissions, to keep the permission check as light as possible. 

[bfarber]

Can you please clarify exactly what issue you are facing or what you are trying to accomplish? I'm not really clear why you are requesting the change you are requesting.

[BomAle]

i have written a app to fetch polls along suite including into pages app. For easy manage I don't use internal item search index because the function (on first post) don't cover parent permissions directly.

The counting of results could not be aligned with permissions.

[bfarber]

Ok so breaking it down, you're trying to find topics that contain polls that the user can see, is that right? And the problem you're running in to is that you're having topics returned that are stored in forums the user could 'see' but actually can't because the parent permissions block access?

[BomAle]

yes, but also for improve safety I suppose is very important update the child permission when a parent is changed...

[bfarber]

When we store a content item in the search index, we call to searchIndexPermissions() to fetch permissions for the content item, which inherently checks the parents already. What you are describing seems like it would be a major issue for every search if it were the case (searching for a topic pulls topics you can "see" even if you can't see the parent forums where the topic is located), and I can't seem to reproduce that, ignoring the rest of what you are talking about.

[BomAle]

I don't understand a thing:

I see that the permissions are not aligned in the subnode. (why?)

you prefer handle permissions into your script to avoid check parent when is the case?

you align the search index item but not the node?

(see screenshot) a topic into SUB forum with permission to read is not readable because into "A test Category" is not able to view forum. if I not wrong the topic was visible on 3.4.x

[bfarber]

For the search index, we don't explicitly just grab the permissions stored in core_permission_index, however. The content item method searchIndexPermissions() (which just pulls from Node\Model searchIndexPermissions()) specifically walks up the tree to make sure the parents can be read as well, and this permission merge is what is stored in the search index.

[BomAle]

Personally I don't like this procedure, because you use disabledPermissions() and permission() when get form to edit node/model (I like it) but this check don't cover parent... (why this decision not update directly the child or give it a option to update the child? could you at least notice the admin that such permission is disabled on parent?)