Hi all!

After dealing with this issue for several days, I'm kinda out of options. So I'm turning to the forum hoping someone can help me figure out what I'm doing wrong.

I'm trying to persist some values after the user pays for a product. I'm using db_persist inside the PayPal processor file to increase the number of sales, total earned, etc.
Since many products can be related to an owner, I'm using relations to find that user by ID. This is the code inside the processor:

Code: Select all

<cms:if k_paypal_success>
    <cms:related_pages id='<cms:show pp_item_number />' limit="1">
        <cms:db_persist 
            _masterpage="users/index.php" 
            _page_id=k_page_id
            _mode='edit' 

            user_total_sales="<cms:add user_total_sales '1' />" />

    </cms:related_pages>
</cms:if>

Any insight on this is much appreciated.
Thanks

[KK]

Hi,

Could you please share how the products and users templates are related?

BTW, the <cms:related_pages> does not need an 'id' parameter - it automatically fetches the pages related to whatever page is selected in context (in this case, it would be the product being purchased). Anyway, the id you added should be ignored and shouldn't affect the result.

Hi KK,

This is the relation field connected on the other side

Code: Select all

   <cms:editable 
      type="relation" 
      group="product_info" 
      name="pp_theme_author" 
      label="Author ID (type: relation)" 
      masterpage="users/index.php" 
      has='one' />

Thanks

Hi KK,

I noticed a few things when trying to edit the users.

First of all, the exact same code works if executed from the template where the relation field is declared.

Second, it seems that the _page_id may be affecting this somehow? I'm trying to send an email on a successful transaction, and looks like the db_persist tag is breaking the code, but changing the mode from "edit" to "create" causes the process to complete. Maybe it's because when using "create" the _page_id can be omitted?

[KK]

Hi,

Can I take a look at the problem first-hand?
Please PM me the FTP + Couch access creds for your site, if that is ok.

Thanks.

[KK]

Thanks for the creds.

I had a look and found the problem to be this -

You are using 'extended-users' so when you use <cms:db_persist> in your code, it tries to update the associated core user account as well.

The core user account has a security check built-in that allows only the actual user to update her account or a user with higher privileges (e.g. an admin) to do so.

In your case, it is the IPN from PayPal that is triggering the update and for Couch it appears as if an anonymous visitor (with zero privileges) is trying to edit a user account - and so, understandably, it balks and terminates the script.

As for the solution, I had to fall upon a crude hack to quell Couch's apprehensions.
As shown below, in the 'k_paypal_success' block, just before we invoke <cms:db_persist> we use a bit of PHP to grant the current user (the anonymous IPN) a higher access privilege.

Code: Select all

<cms:if k_paypal_success>
    <cms:php>
        global $AUTH;
        $AUTH->user->access_level = 7;
    </cms:php>

    <cms:related_pages id='<cms:show pp_item_number />' limit="1">
        <cms:db_persist 
            _masterpage="users/index.php" 
            _page_id=k_page_id
            _mode='edit' 

            user_total_sales="<cms:add user_total_sales '1' />" />

    </cms:related_pages>
</cms:if>

This is OK as the execution of the script will not go beyond the <cms:if k_paypal_success> block (the script terminates after that).

Things seem to be working fine in my tests on your setup,
Please do you own tests and let me know if this helped.

[trendoman]

Hello, I would like to add that it is a bad strategy to allow dirty hacks with wrong strategy of creating backend.

User templates should not be changed, rather sales should have a standalone clonable template with reverse_relation field, pointing to existing users.. Means that each successful sale is a cloned page of such template. Other websites could benefit from the fact that sale data can be tracked there as well (time, applied coupon, etc), in case it is needed later.

Hacks to poor thinking leads to no lessons

Hi KK,

Thank you for taking the time to look into the issue
That worked like a charm!

@trendoman, that's a really good point! I myself am not very fond of "hacking" the way a library/framework (or a whole CMS in this case) works. Your suggestion is a good way to go about this, especially when thinking about generating reports or even just list of invoices for users to access from their profile. But this was kind of a hot fix for my site, that's why KK came up with something really quick

Thank you both!