Problems, need help? Have a tip or advice? Post it here.
12 posts Page 1 of 2
Hi

Please refer to the previous thread (viewtopic.php?f=4&t=12803) for some background on this - but the situation now is a little different. I never managed to get that situation resolved and ended up with a regular manual task to delete data, which wasn't great but worked.

I'm closing down the site now and have to advise all the users - 13800 of them. I can't send more that 200 emails every hour, so I want to use a cron job running every ten minutes to:

* Get the next batch of 30 users, where the 'email sent' field in the extended user record is blank
* Send an email to each one
* Update the 'email sent' field to show that the email has been sent.

This runs fine if I initiate it while logged in, but not if I'm not logged in, or if it's run by the cron job - if I'm not runnign it when logged in I get the 'Cheating?!' response.

I'd really appreciate it if @KK, or someone else who understands it, could tell me exactly how to use the 'GC addon' referred to - but never resolved - in the previous thread, or some other way of doing this.

I have to get these emails sent, and unfortunately I've been held up by the client on some details, so time is short before my domain name and hosting expire. Manually running it every ten minutes 24/7 for most of the next week is really not an option!
Hello!
I can help you understand why the issue, I hope that will help you make the relevant changes in your code:

Cheating?!

You get this because you have a system in place that allows the users to login to access data.

So why does the message appear?: Simple answer is, "Because you are trying to edit details that cannot be edited by the current k_user_access_level."

Just if you want to test your cron for working, make sure that the code invoking the cron job is in no way within the k_loggin_in tag (this is just to test, as I do not know if that is what your use case could work with).

Currently your cron code is like:
Code: Select all
<cms:if k_logged_in>
    <!-- Cron Code here -->
</cms:if>


To check if your error resolves test as following:
Code: Select all
<!-- Cron Code here -->
<cms:if k_logged_in>
    ...
</cms:if>


Regards,
GenXCoders
Image
where innovation meets technology
Simply make the cron a superadmin. :)
Thanks for responding!

There's no 'if k_logged_in' in this file at all. The template is hidden and in the superadmin group in the admin panel, but it has no access level set (and as far as I'm aware, the 'hidden' and 'group' apply only to where it's found in the admin panel, and don't control actual access).

The requirement for authentication is presumably coming from Couch when there is an attempt to update the database to set the 'email_sent' field to say this email has been sent.
There's no 'if k_logged_in' in this file at all.

It may not be there in this file, but you have extended users module activated. And with the module activated, the k_logged_in is being checked.

As trendoman suggested, you could try something as:
Code: Select all
<cms:if k_logged_in && k_user_access_level gt '7'>
   Cron Code here
</cms:if>

But this will make sure that the cron executes only when logged in as superadmin.

Regards,
GenXCoders
Image
where innovation meets technology
daldred wrote: Thanks for responding!

There's no 'if k_logged_in' in this file at all. The template is hidden and in the superadmin group in the admin panel, but it has no access level set (and as far as I'm aware, the 'hidden' and 'group' apply only to where it's found in the admin panel, and don't control actual access).

The requirement for authentication is presumably coming from Couch when there is an attempt to update the database to set the 'email_sent' field to say this email has been sent.


I was suggesting this -
When a page runs in Couch, Couch determines who is behind it. It is possible to manipulate Couch to think a user has superadmin privileges. Work with $AUTH->user->access_level.

@genxcoders, OP's issue is not in logic. Anonymously running page will always be assigned to a user with id: -1, access_level: 0. The task is to assign access_level '10' for that user. It is safe to do so, because no one else would use that page's script and the script does not accept user input from browser.
Thanks, Trendoman

Can I actually assign a value to the Auth variable, then? I'm away from the PC for an hour or so so I can't simply test!
daldred wrote: Thanks, Trendoman

Can I actually assign a value to the Auth variable, then? I'm away from the PC for an hour or so so I can't simply test!


KAUTH is a class defined in /couch/auth/auth.php. So, $AUTH contains an object, an instance of that class. It is not intended to be just a variable :) $AUTH references the current user in its property $user (an instance of KUser class from /couch/auth/user.php).
That's why we can change anything about the current user if we use $AUTH->user.

This should work -
Code: Select all
    <cms:php>
        global $AUTH;
        $my_access_level = &$AUTH->user->access_level;
        $my_access_level = 10;
    </cms:php>


Pls check PM
Thanks again. Trendoman. I've just tried using this code to strip things back to the basics and test the approach::
Code: Select all
<?php require_once( 'couch/cms.php' ); ?>
<cms:template title='Test' clonable='1'></cms:template>

    <cms:php>
        global $AUTH;
        $my_access_level = &$AUTH->user->access_level;
        $my_access_level = 10;
    </cms:php>

   <p>*** <cms:show k_user_access_level /> ***</p>

<?php COUCH::invoke(); ?>

Unfortunately it returns 10 when I'm logged in as superadmin, but 0 if I log out then try it; which implies that any Couch code run after the php block isn't respecting the access level as set.

I haven't tried it with a cron job yet, but if it doesn't work in the browser I wouldn't expect the cron job to fare any better!

(I'll get back to you on the PM)
Don't worry, Couch variable k_user_access_level is set way-way earlier, it is immutable by the time Couch runs code from a template. Couch variables like that one (i.e. the ones visible in <cms:dump>) always come from Context ($CTX) - they are merely a 'picture on the wall' - and Couch does not rely on those when deciding what to do. :)

It is not difficult to change that variable to reflect on the new access_level, but absolutely meaningless.

Your cron job will do just fine, because database-related operations use internal routine to check access.
12 posts Page 1 of 2