*** Bug 29141 has been marked as a duplicate of this bug. ***

I haven't done it in the first iteration because it's a bit tricky.

A user who enqueued a job should be able to access to page, and view their jobs.

Should we have the view available for any staff users? Only those with admin access?

Otherwise we need to list the permissions of the different pages that allow background jobs. But I don't like this solution.

I think superlibrarians should be able to see all background jobs.

As for other users, could it be a permission? The other links in the Administration page or Tools page are all linked to permissions.

We could maybe emulate the items_batchmod and items_batchmod_restricted permissions?

background_jobs : access to all background jobs

background_jobs_restricted : access to background jobs limited to jobs started by user

? 

I'm not sure what appears in that page and what are the implications of having access to it (I don't even remember in what context I had to have access to it when I wrote this bug lol!). Can we stop background jobs from there? If that is the case, should we also have a permission to stop jobs? Or is that ability implied when having access to the page?

Tools that allow you to batch delete/edit/create will use the "background jobs" (also "task queue" sometimes) feature in a near (hopefully) future.

The goal is to process the job when the server can do it (and to not block the user, the job is enqueued and they don't need to care about it).


So any users with access to those tools (listed is short now, but will be extended later, even to plugins certainly) should have access to the list of jobs THEY enqueued (at the minimum).

I don't think it should be a permission, neither it should be linked to the permissions of the tools using the task queue (it's a list that we will need to keep up-to-date, and it will be tricky when it will be extended to plugins).

> Can we stop background jobs from there?

Yes, you can cancel a job, but only those you started (or you have the manage_background_jobs permission).

I am in favor of displaying a link to that page for any users with access to the staff interface.

(In reply to Jonathan Druart from comment #4)
> > Can we stop background jobs from there?
> 
> Yes, you can cancel a job, but only those you started (or you have the
> manage_background_jobs permission).

This is the theory, the code is wrong!

 64     if ( my $job = Koha::BackgroundJobs->find($id) ) { # FIXME Make sure logged in user can cancel this job
 65         $job->cancel;
 66     }

will fix separately.

I think we could have a 'Server status' entry in the main page, that could contain some information currently in the about.pl page about the running processes (e.g. ES/ status, indexed records, etc).

And that page could have some sections, one of them (the only one for now until we migrate things there) the background jobs. Displaying only the tasks the user is allowed to see, if any.

Created attachment 125964 [details] [review]
Bug 29020: Add link on the mainpage for users without admin access

Created attachment 125965 [details] [review]
Bug 29020: Add link on the admin module

I think those patches provide a good ergonomic to the two type of users.
Those with admin access will have the link in the admin module, the others will see a "background jobs" on the mainpage.

Test plan:
Have 2 users, one P1 with parameters > manage background jobs, the other P2 without.

Log in with P1: no link on the main page

Create a job with P1 (batch delete biblio records for instance).

Go to the main page => You see the link

Click => you have access to your jobs

Log in with P2, create a job

=> Nothing on the main page, P2 has access to the job from the admin module.

Feel free to provide an alternative patch.

Note that this patch also fixes bug 29178.

Created attachment 125980 [details] [review]
Bug 29020: Add link on the mainpage for users without admin access

Created attachment 125981 [details] [review]
Bug 29020: Add link on the mainpage for users without admin access

Created attachment 125982 [details] [review]
Bug 29020: Add link on the admin module

It works! P1 and P2 are inverted in the test plan, but
the principle that user with manage permission accesses
bg jobs from the admin page and user who do not only
have access through main page is there.

Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>

*** Bug 29178 has been marked as a duplicate of this bug. ***

Created attachment 126439 [details] [review]
Bug 29020: Add link on the mainpage for users without admin access

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Created attachment 126440 [details] [review]
Bug 29020: Add link on the admin module

It works! P1 and P2 are inverted in the test plan, but
the principle that user with manage permission accesses
bg jobs from the admin page and user who do not only
have access through main page is there.

Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

This patches work as advertised and should be added to Koha.

I still think we need to polish the area a bit:
- If you ever run any 'background job' ("what are they? I just used the batch delete tool") you will see the link forever, in an area that is usually reserved for notifying required actions, forever.
- One posible placement could be the user account dropdown at the top, and always display. Showing an empty table if never ran any background job.
- Another option could be in the Tools area, same behavior of the empty table if never ran anything.

Those are my thoughts. That should be worked somewhere else. Passing QA. If I manage to provide alternate patches, it will be follow-ups to this.

(In reply to Tomás Cohen Arazi from comment #17)
> I still think we need to polish the area a bit:
> - If you ever run any 'background job' ("what are they? I just used the
> batch delete tool") 

Agreed. I think calling them "background jobs" is too developer focused and not user-friendly.

(In reply to David Cook from comment #18)
> (In reply to Tomás Cohen Arazi from comment #17)
> > I still think we need to polish the area a bit:
> > - If you ever run any 'background job' ("what are they? I just used the
> > batch delete tool") 
> 
> Agreed. I think calling them "background jobs" is too developer focused and
> not user-friendly.

Suggest then please. What about the placement?
We have a bug to rename it "tasks/task queue", is that  what you have in mind?

Pushed to master for 21.11, thanks to everybody involved!

(In reply to Jonathan Druart from comment #20)
> Pushed to master for 21.11, thanks to everybody involved!

Thank you for your hard work on the area. And sorry for the delays in the testing phase.

Hi, 

May we have this in the stable branches please?

Liz

or at least 20.05

(This is an aside not directly related to Koha, but I was thinking about this a little bit the other day, while working with Discourse. It uses Sidekiq (https://en.wikipedia.org/wiki/Sidekiq) for running it's background tasks. A top level administrator can just go to http://<discourse>/sidekiq to see everything related to background tasks. As far as I can tell, there's no link to sidekiq from Discourse, but it is handy for the administrators to be able to trigger and review jobs from there.)

(In reply to Liz Rea from comment #22)
> Hi, 
> 
> May we have this in the stable branches please?
> 
> Liz

Andrew?

Pushed to 21.05.x for 21.05.14

Not backported to oldoldstable (20.11.x). Feel free to ask if it's needed.