topic Re: Results in the node browser (lucene) in Alfresco Archive

Results in the node browser (lucene)

abirb — Mon, 12 Jan 2009 06:51:29 GMT

Hi, I have a issue (doubt rather) with the results displayed in the node browser , hope someone can throw some light on the scenario.When I upload a file(content) using the 'Add Content' UI fo alfresco to any particular space , and do a lucene query in the node browser the result is something like {

Re: Results in the node browser (lucene)

janv — Tue, 13 Jan 2009 17:22:11 GMT

It sounds as if you have added a category to that space - which I assume is called "move" ?

If so then "{}member" is a special QName, see http://wiki.alfresco.com/wiki/Search#Category_Queries

Hope this helps.

Regards,
Jan

Re: Results in the node browser (lucene)

abirb — Wed, 14 Jan 2009 06:59:02 GMT

hi,
thanks for the reply , let me expalin my scenario a little more , I have created 2 spaces (temp1 & temp2) , on temp1 I have WebDav enabled it and have added two rules on it namely , one adds an aspect to the inbound items , and the second rule moves the items from temp1 to temp2 (name of the rule on temp1 is 'move …' ) .

Now when i do drop the files on the webdav location it correctly adds the aspect and moves the files to temp2 , and now when I do a lucene query in the node browser on temp2 (as explained in the previous post) I get to see results as described in the post earlier.

Further , I did enable WebDav on temp2 this time and added the rules , and the results showed up just fine in the node browser.. 🙂

I guess , something to do with the move of the files to the location is resulting in the described results..

Rgds

Re: Results in the node browser (lucene)

rsulliv1 — Mon, 02 Nov 2009 05:09:39 GMT

Did you find any update to this?

I think your issue was noted by J. Potts in his actions article:

http://ecmarchitect.com/images/articles/alfresco-actions/actions-article.pdf

Note that in Alfresco's “moveNode” call, they use destinationAssocQName as the qname of the newlymoved
node. That variable resolves to the string “move”. If you ever move more than one document
into a folder using that action, you'll get integrity violations. This seems like a bug to me. My version of
the “moveNode” call uses the current name of the object being moved as the new name, which seems
like a better way to go.