[Catalyst] Applying a global SQL filter on REST controller.

[Rajesh Kumar Mallah]

Hey  ,

Thanks for the reply . I am new Catalyst stilling reading docs
on actions . Shall update if i am able to use the method you
suggest.


Kind Regards
Rajesh Mallah.

> Hi Mallah,
>
> typically with DBIx::Class you would have a Chained root action in your
> controller which puts an already filtered DBIx::Class resultset on the
> stash and have all other action chained off this one.
>
> DBIC::API provides generate_rs [1] to enable you to do this.
>
>
> On 2017-02-06 07:12, Rajesh Kumar Mallah wrote:
>>
>> Ok it did work out and i am able achieve what i wanted.
>>
>>
>> I created the below subroutine in:
>>
>> ControllerBase/REST.pm
>>
>> sub list_munge_parameters {
>>      my ( $self, $c ) = @_;
>>      $c->log->debug(" ***** list_munge_parameters  callled!");
>>      $c->req->_set_search_parameters( { society_id =>
>> $c->user->society_id() } );
>> }
>>
>> But is it ok to use "PROTECTED METHODS" ?
> They might be renamed, go away etc. on a refactor, which is why they
> aren't exposed and documented.
>
>>
>> Regds
>> Mallah
> Best regards, Alex
>
> [1] https://metacpan.org/pod/Catalyst::Controller::DBIC::API#generate_rs
>
>>
>>
>>
>>>
>>> Ok i do see some light! that I am exploring.
>>> Sorry for the noise i shall post again if i find a
>>> solution or otherwise even.
>>>
>>>
>>>
>>  
 http://search.cpan.org/~abraxxa/Catalyst-Controller-DBIC-API-2.006002/lib/Catalyst/Controller/DBIC/API.pm
>>> list_munge_parameters
>>>
>>> list_munge_parameters is a noop by default. All arguments will be
>>> passed
>>> through without any manipulation. In order to successfully manipulate
>>> the
>>> parameters before the search is performed, simply access
>>> $c->req->search_parameters|search_attributes (ArrayRef and HashRef
>>> respectively), which correspond directly to ->search($parameters,
>>> $attributes). Parameter keys will be in already-aliased form. To store
>>> the
>>> munged parameters call $c->req->_set_search_parameters($newparams) and
>>> $c->req->_set_search_attributes($newattrs).
>>>
>>>
>>>
>>>> Dear Catalyst Experts/Users/Hackers,
>>>>
>>>> Please guide for the below situation,
>>>> I have put reasonable effort by searching on online
>>>> resources.
>>>>
>>>>
>>>> We have an application backed by SQL tables that stores
>>>> data of multiple customers in same table . We have
>>>> many such tables and all of them bear a column customer_id
>>>> for separating the records of one customer to another.
>>>>
>>>>
>>>> The security isolation requirement is that one customer should
>>>> not get to see records of other customer. What i have in mind
>>>> is to append an SQL filter customer_id = << customer_id of logged in
>>>> customer >>
>>>> at a global level . The controller modules for each database table are
>>>> being (auto)generated by the helper
>>>> Catalyst::Helper::Controller::DBIC::API::REST The dataset is being
>>>> exposed
>>>> via REST utilising
>>>> Catalyst::Controller::DBIC::API
>>>>
>>>> Can anyone please guide where such a constraint can be put ?
>>>>
>>>> Regds
>>>> Rajesh Kumar Mallah.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> List: Catalyst at lists.scsys.co.uk
>>>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>>>> Searchable archive:
>>>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>>>> Dev site: http://dev.catalyst.perl.org/
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> List: Catalyst at lists.scsys.co.uk
>>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>>> Searchable archive:
>>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>>> Dev site: http://dev.catalyst.perl.org/
>>>
>>
>>
>>
>>
>> _______________________________________________
>> List: Catalyst at lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>
>
>
>
 *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
> Handelsgericht Wien, FN 79340b
>
 *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> Notice: This e-mail contains information that is confidential and may be
> privileged.
> If you are not the intended recipient, please notify the sender and then
> delete this e-mail immediately.
>
 *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>