Access the request in DocumentCreatedEvent

Help / Discuss
1

I have created a component class that listens for document created events so that I can set a unique id for a page.

My issue is that when a page is renamed/moved it calls the document created event which triggers generation of the id which is not what I want.

I need to be able to know when it is a rename so that I can keep the unique id for the page.
I thought I could user the xpage parameter but I don’t have access to the request parameters as the request object wraps a stub in the onEvent method.

Can anyone tell me how I can work our when the DocumentCreatedEvent is triggered due to a rename.

2

Indeed right now a rename is a copy + delete… We need to improve this. A first step is to introduce some rename events, see Loading...

I don’t know how to do it. Maybe find that this is being executed while inside a rename job?

@tmortagne any idea?

3

Yes that’s probably the safest way right now. You can get the current job trough org.xwiki.job.JobContext component (xwiki-commons-job module) and you can find rename job type name in org.xwiki.refactoring.job.RefactoringJobs (xwiki-platform-refactoring-api module).

4

How do I get the JobContext from within a Groovy script in a component method class?

5

I managed to get the job type from the JobContext as below. Unfortunately the job type is “refactoring/rename” for both copy and rename. How do I differentiate between a copy and a rename?

def jobType = "create"

def jobContext = services.component.getInstance(org.xwiki.job.JobContext.class)
if(jobContext) {
  def job = jobContext.getCurrentJob()
  if(job) {
    jobType = job.getType()
  }
}

System.out.println("DocumentCreated: jobType = ${jobType}.")

if(jobType != "refactoring/rename") {
6

Indeed just notice that, not a great idea given the fact that the current behavior of rename is supposed to be a hack… As far as I can see the main difference is that the job request isDeleteSource() will return true for a rename and false for a copy (a difference that should be internal in theory).

In your code it should be something like job.status.request.isDeleteSource()

7

That worked thanks. I ended up with:

def jobType = "create"

def jobContext = services.component.getInstance(org.xwiki.job.JobContext.class)
if(jobContext) {
  def job = jobContext.getCurrentJob()
  if(job) {

    jobType = job.getType()
    if(jobType == "refactoring/rename" && !job.status.request.isDeleteSource()) {
      jobType = "copy"
    }
  }
}

if(jobType != "refactoring/rename") {

  ....
}
8

After several months of using these events to create a unique ID when a page has created I have discovered that the DocumentCreatedEvent is not called when an image is uploaded before the page is saved.

The upload of the image creates a revision of the document without calling the DocumentCreatedEvent. This sounds like a bug to me.

XWiki is making me pull my hair out today.

9

This is definitely a bug but sounds like an old bug. The code in upload action looks OK be right now.

Are you talking about the REST API ?

Anyway if you can reproduce with 10.10 or 9.11.8 would be great to create a jira issue with the steps to reproduce, should be easy to fix.

10

You mean with the WYSIWYG editor? The CKEditor calls save() when attaching the image so the DocumentCreatedEvent should be triggered.

11

Testing shows that when attaching the image using the CKEditor, the document using is created but the DocumentCreatedEvent is not triggered.