Fix minor regression with PR 1464

When defining a standard filter that returns "any" issue, don't specify the
project id. Advanced and simple filters both works in the same way,
regarding inclusion of subprojects, as long as the project_id property
is not filled explicitly.

Prevous to PR1464, the api would include subprojects always, but after
the PR, it would have different behaviour if, for example, having
configured $g_view_filters = ADVANCED_ONLY

Fixes: #25515

core/filter_api.php

@@ -3171,19 +3171,14 @@ function filter_create_recently_modified( $p_days, $p_filter = null ) {
 }
 
 /**
- * Create a filter for getting issues assigned to the specified project.
- * @param integer $p_project_id The project id or ALL_PROJECTS.
+ * Create a filter for getting any issues without restrictions
  * @return mixed A valid filter.
  */
-function filter_create_any( $p_project_id ) {
+function filter_create_any() {
 	$t_filter = filter_get_default();
 
 	$t_filter[FILTER_PROPERTY_HIDE_STATUS] = META_FILTER_NONE;
 
-	if( $p_project_id != ALL_PROJECTS ) {
-		$t_filter[FILTER_PROPERTY_PROJECT_ID] = array( '0' => $p_project_id );
-	}
-
 	return filter_ensure_valid_filter( $t_filter );
 }
 
@@ -3850,7 +3845,7 @@ function filter_standard_get( $p_filter_name, $p_user_id = null, $p_project_id =
 
 	switch( $p_filter_name ) {
 		case FILTER_STANDARD_ANY:
-			$t_filter = filter_create_any( $t_project_id );
+			$t_filter = filter_create_any();
 			break;
 		case FILTER_STANDARD_ASSIGNED:
 			$t_filter = filter_create_assigned_to_unresolved( $t_project_id, $t_user_id );