Using FileImporter in a job (user problem)


I have created a job that will import some pdf files to the filemanager. That works when importing the first time.

When I have a file that is already in the filemanager, it will add a new FileVersion.
Within that functionality, the FileVersion is duplicated first and there it goes bananas.

Within the FileVersion::duplicate function there is assumed that there is a loggedin user. That works as long as you execute the code when logged in. But I use it in a (cron)job, so there is no user.

When importing a file for the first time (File::add()), there is a check whether there is a loggedin user, else the $uID will be 0:

$uID = 0;
$u = new User();
if (isset($data['uID'])) {
$uID = $data['uID'];
} else if ($u->isRegistered()) {
$uID = $u->getUserID();

Shouldn't this be done when adding a new file version (within FileVersion::duplicate())?

Or is there some other way to use it when using the fileimport (adding new fileversion) in a (cron)job?


View Replies:
jshannon replied on at Permalink Reply
This kind of bug exists in a few places in the core.

While you can probably convince someone to fix this bug, the easiest solution would be to "log someone in" as part of the cron job.


SnefIT replied on at Permalink Reply
Thanks for the quick reply.

I already thought about that. Could be used as a 'last resort'. I don't want to bind the files to an user, it should just be 0. Just like the 'original' file that was imported by the job.

I'm now using an override for FileVersion and override FileVersion::duplicate.

Another solution can be first deleting the original file and just adding a new one but I like to keep the versions.

mkly replied on at Permalink Reply
You can set a custom user during the job.
$req = Request::get();
$ui = UserInfo::getByID(USER_SUPER_ID);

Instead of the admin user(USER_SUPER_ID) you could set a particular user to run jobs as. For example a "jobs" user. Or a particular user for that particular job.