Is there any way of using Couch to delete old records overnight using a cron job?

The issue is that a cron job is not run as a Couch user, so there's no logged in admin user. <cms:db_delete> therefore doesn't act, and just says 'Cheating?'.

[trendoman]

GDPR complience??
If <cms:db_delete> tag says 'Cheating?!' then script is running as a regular anonymous visitor (id = '-1'). There is no easy way to avoid security checks.

One can perform either direct database query via <cms:query> which is very-very *not recommended* because.. reasons.
One can authorize the script via native <cms:process_login> tag or mingle with $AUTH via php directly. However this exposes the script to anyone if done without extra protection (allow only one certain ip and certain time interval).

A better way is to employ GC addon (a part of Mosaic) - it runs in background and can do jobs in a separate process. This way, cron would request a page as anonymous visitor and be satisfied with it. GC would launch an elevated worker with a task to perform (clean up entries older than xx days) and shut down. Maybe it is time @KK gives a little tutorial about it

GDPR complience??

Combination of GDPR and Covid rules. If people ask to delete their accounts, I have to delete them under GDPR - but because this involves records of attendance which may be required for Test & Trace during Covid, I have to keep them for 21 days first. So "deletion" is actually disabling an user account and setting it to delete on a certain date. The corn job should be doing the deletion.

If <cms:db_delete> tag says 'Cheating?!' then script is running as a regular anonymous visitor (id = '-1'). There is no easy way to avoid security checks.

Yes, that's what I thought.

A better way is to employ GC addon (a part of Mosaic) - it runs in background and can do jobs in a separate process. This way, cron would request a page as anonymous visitor and be satisfied with it. GC would launch an elevated worker with a task to perform (clean up entries older than xx days) and shut down. Maybe it is time @KK gives a little tutorial about it

Sounds like what I need, but is there any reference to it anywhere in the forums/docs? If not, over to @KK!

[trendoman]

The corn job should be doing the deletion.

I understood the typo but I saw that horror in my infancy.. Still feel uneasy about the "corn"

childrenofthecorn.jpg (6 KiB) Viewed 1662 times

Over to @KK, indeed.

So, after a long pause and much manual running of what should be cron jobs, I'm back to looking at this.

I've had a look at the GC addon code and at my MySql database. It's a bit beyond my level, but it looks to me as though it:
- Has a method of establishing whether a call to it is legitimate (comes from a defined 'admin' route)
- Collects jobs to be run from entries in the couch_settings table (?) with a key starting 'gc_jobs'
- Then runs the jobs

So I'm guessing a cron job running an (unprivileged) php task with the right 'admin route' would lead to the tasks being run as admin.

Is that right? Again, ideally input from @KK would be great, but if @trendoman can add more that would also be good!

[KK]

Hi,

GC (Garbage Collector, of course) is actually a "poor man's" alternative for cron - i.e. is a lightweight replacement for cron.
However it gets triggered only when somebody uses the admin-panel. Therefore, it won't be ideal for cases (like yours) where a certain event has to be triggered at a predefined time. That would need proper cron.

That said, deleting pages from cron should be no different from how it is done through Couch's GC. Mosaic makes use of GC heavily to delete orphaned entries (pages) and, I think, you should be able to adapt its code for your purposes.

As pointers, please refer to the following two functions -
1. function process_gc() in addons/mosaic/mosaic.php
2. function db_delete() in addons/data-bound-form/data-bound-form.php (this is the actual implementation of <cms:db_delete> tag).

As you'll notice, essentially it only involves first getting the ID's for all the pages that are to be deleted and then doing the following for each page -

Code: Select all

$pg = new KWebpage( $tpl_id, $page_id );
$pg->delete();

Hope this helps.

Hi, @KK, and thanks for responding.

I'm trying this on my localhost, and must be getting something wrong! My approach was to

• create a cms:func
• get a template ID using <cms:templates> (18) and a few page IDs by viewing pages from the admin panel (36132 to 36135).
• feed these to the cms:func

Code: Select all

<?php require_once( 'couch/cms.php' ); ?>

<cms:func 'deleteRecord' templateId = '' idToDelete=''>
    <cms:php>
        global $CTX;
        $recordIdToDelete = $CTX->get('idToDelete');
        $templId =  $CTX->get('templateId');
        echo "$recordIdToDelete : $templId \n";
        $pg = new KWebpage( $templId, $recordIdToDelete );
        $pg->delete();
    </cms:php>
</cms:func>

<cms:call 'deleteRecord' '18' '36132' />

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

Results:

• First attempt, while logged in as superadmin , using the exact code above - success; page 36132 is gone.
• Second attempt, while not logged in (as if running from cron), as above but record number 36133 - response is 'Cheating?', and the record is not deleted.

So including this within the usual Couch require / invoke pair doesn't work. In fact after another test, even this results in 'Cheating?':

Code: Select all

<?php require_once( 'couch/cms.php' );
        $pg = new KWebpage( 18, 36133 );
        $pg->delete();
?>

But if I don't require couch.php, the KWebpage object and therefore the 'delete' method is not defined....