Yii 1.1: Parameterized Named Scope. Re-use the same set of filtering criteria in various models and controllers. Also re-use the same Parameterized Named Scope in all find() functions and in dataprovider. Follow @yiiframework

Here is an example of a parameterized named scope (pns) with 2 parameters (obviously you can use more if needed). The first parameter is used to receive an operator - which can be any of these: =, >=, >, <, <=. The second parameter is used to receive the filtering value.

Now for the important bit: This pns works with two methods.

Method-1: You can pass the parameter values from the controller directly to the pns, via any find() function:

$posts= myTable::model()->pns_recordstatus('>=', 1)->findAll();

Method-2: You can store the parameter values in the empty model (let's call it the filtering-model) that you create in the controller to:

store the filtering criteria that the user might have entered in the gridview; and

store your own filtering criteria that you want to incorporate into the gridview.

In the model's search() function, the DataProvider will invoke the pns, which will incorporate the filtering-model's parameters, so that it will reflect in the CGridView's rows.

Two separate properties (var_operator and var_recordstatus) are created in the model to store the operator and filtering value.

Why create $model->var_recordstatus if the model already has $model->recordstatus (obtained from the record)?

Because you use $model->var_recordstatus in the pns to only include records with recordstatus = 1 or 2. And you then use $model->recordstatus to store the filtering criteria that the user might enter in the gridview to FURTHER filter the records.
If you use $model->recordstatus for both purposes, then the user's filtering criteria will be constantly overwritten by your own value.

(Obviously, if the recordstatus column is not displayed in the gridview, or if it should not be filtered any further by the user, then you only need to use $model->recordstatus.)

The model:

public$var_operator;
public$var_recordstatus;
publicfunctionsearch(){$criteria=newCDbCriteria;
/* Put your other normal filtering criteria here *//* The dataprovider invokes the pns. Here you don't pass any parameters to
the pns, because Method-2 uses the parameters stored in the filtering-model
*/returnnewCActiveDataProvider($this->pns_recordstatus(), array('criteria'=>$criteria,
));
}/* The parameterized named scope */publicfunctionpns_recordstatus($operator=null, $value=null){/*Method-1 uses $operator and $value, which were passed directly to
this pns by the find() function. *//*Method-2 uses $this->var_operator and $this->var_recordstatus, which
were stored in the filtering-model. *//* Test if Method-1 must be used ($value must be between 0 and 2;
and $operator must be set correctly) */if($value >= 0 && $value <= 2 &&
in_array($operator,array('=','>=','>','<','<=',))){$this->getDbCriteria()->mergeWith(array('condition'=>'t.recordstatus'.$operator.$value,
));
}/* Test if Method-2 must be used ($this->var_recordstatus must be
between 0 and 2; and $this->var_operator must be set correctly) */elseif($this->var_recordstatus >= 0 && $this->var_recordstatus <= 2 &&
in_array($this->var_operator,array('=','>=','>','<','<=',))){$this->getDbCriteria()->mergeWith(array('condition'=>
't.recordstatus'.$this->var_operator.$this->var_recordstatus,
));
}else{/* Return no records if neither Method-1 nor Method-2 were used. */$this->getDbCriteria()->mergeWith(array('condition'=>'t.recordstatus=100', /* this will return 0
records, because 100 is not a valid recordstatus. */));
}return$this;
}

This Row-Level-Access-Control I used is just an example to explain pns. However, Row-Level-Access-Control should probably involve defaultScope(), because pns is currently (Yii 1.1.12) not enforced on related tables in relational queries. Here is a wiki on defaultScope doing the same kind of thing as shown in this wiki.