Node Move - DA versus script - permissions getting stripped when code run in DA

Hi,

I've been wrestling with a problem in some code I'm writing that uses distributed agents to move items around. The same block of code when run within the DA has a different outcome for permissions than when run in Builder (CS 10.0 U 2016-06). We have RecMan installed and Recman Security.

Records Mgmt is set up to force any item that is moved to inherit the permissions. When I run my move within a debug window in Builder I see that happening. What happens when I run the same code within a Dist Agent, is that the permission inheritance is happening, but immediately after, and this seems to be occurring after the node rename which is part of the move, each assigned permission is stripped off. The owner is reduced to See + See Contents (which is what the new destination has set), but the owner group which has full rights, gets completely stripped. I even created a patch to insert additional echo statements to see what was going on in Recman's CBNodeMove and CBNodeMovePost callbacks, but it appears that this stripping of permissions is happening after the RecMan Inheritance callback has run. Also, these events (all audited) don't occur when the code is run in a builder window (I build a test harness to run the Map() function).

Has anyone encountered behaviour like this with Distributed Agents interacting with Move? I cannot tell from the connect logs what is invoking the calls to strip permissions. It's starting to make me wonder if something is getting called out of sequence when run from a DA.

-Hugh Ferguson

Find more posts tagged with

Comments

HFCDev

I FOUND IT!!!!!!

I'm posting the solution in case this is of use to someone later on. The Recman module was a red herring. The root cause was the ***RECYCLE BIN***. Well, it would probably still happen as it's not specificy RecycleBin but rather the node crawler that gets invoked when an item is deleted and is responsible for stripping its permissions. Here's what happened:

* My DA does a move where I move items first to a temporary swap folder, then move them into place (see my other DA related threads on this forum for details of why I'm doing this).

* once all the items are complete, I delete the swap folder.

* when this runs within a builder window, because there isn't an open transaction holding everything, the delete folder event occurs well "after" the move.

* When run in a DA, the delete folder event gets processed in an in-between state. Because the transaction is still open because this is clean-up after the DA has finished processing objects but prior to the final commit, the RecycleBin's PermsNodeCrawlerCallback function will pick up my object which from my perspective is no longer in the swap folder, as in the swap folder. As a result, it does its thing and clobbers the permission. When run outside of DA, the same code would never in a million years detect the just moved item as still being in swap.

This begs the following question: if you are deleting temporary staging areas in a Distributed agent, is there a safe way to *not* have the PermNodeCrawlerCallback pick up any item that may have temporarily resided there?

I'm starting to think that (at least for my version of CS10.0), I may need to add a separate agent which wakes up and cleans up expired swap folders - something I was hoping not to do.

-Hugh

John Simon

"once all the items are complete, I delete the swap folder". Did you use a JobChain task? If so can you use FINALIZE to clean up after the task (and any subtasks) have completed?

HFCDev

This version of the module uses simple jobs. I've got a prototype version of the module that does exactly that - i.e. uses a job chain and moves cleanup to the Finalize phase. For this version, I simply created another simple job task that handles the clean-up and call it from the job that just completed.

-Hugh

John Simon

Hugh,

I hear you. I am in the middle of writing a DA task to create a records reporting table (think when will this record be due for disposition). I was using JobChain tasks to do this, and making use of FINALIZE to clean it all up at the end of processing. It all worked well but I abandoned it in favor of Simple tasks. The JobChains all had to run MAP and REDUCE in order to get to FINALIZE on the parent task. Running REDUCE (which wasn't actually doing anyting for me) was taking hours becuase I end up with right around 1 million tasks. I ended up replacing the work FINALIZE was doing with another agent that either performs the cleanup or ends.

Cheers...