You are viewing limited content. For full access, please sign in.

Question

Question

Assign Rights + Create Shortcut = "Failed to initialize document. Access denied. [9013]"

Workflow Laserfiche Version 9 Business Processes
Updated September 22, 2015
asked on September 21, 2015

I have a Workflow to allow sharing a file(s) between two departments: 

  1. Department A selects the file(s), starts the Business Process
  2. Workflow assigns Browse and Read rights to Department B
  3. Workflow creates a shortcut to these files in Department B's folder

 

Shortcuts are created successfully and the rights are set to the actual files, however Department B users still get the Access Denied error message when opening the shortcuts. 

 

What else do I need to do? Do I need to adjust the rights on the parent folder of these files too?

0 0

Answer

SELECTED ANSWER
replied on September 22, 2015

Your screenshots show that your are using the Assign Rights activity on the document, not the folder. So it looks like the activity is applying the option under "if this entry is a folder, apply rights to" to all entries regardless of type. That's definitely a bug and we're looking into it.

However, since you're not dealing with folders in this case, leaving that option to its default value will not have an impact on your security on other entries because documents can't have subfolders or child documents, but it will fix the current issue on the document.

1 0

Replies

replied on September 21, 2015

- Are there any security tags assigned on the document that Department B doesn't have? 

- Check the document's effective rights for someone in Department B, make sure the Read right isn't being denied elsewhere.

0 0
View 7 previous replies
replied on September 21, 2015

Thanks Robert.

The document's Effective Rights actually show nothing as "granted" for that group, whereas the Access Rights have the Browse and Read allowed, with the scope is set to Document Only.

I've attached a screenshot of the Workflow step - should I be changing the scope?

 

2015-09-21 12_53_35-Rights Options.png
2015-09-21 12_53_35-Rights Options.png (38.03 KB)
0 0
replied on September 21, 2015

That looks correct to me, I think one of the parent folders is denying those rights.

0 0
replied on September 21, 2015

The parent folders are not denying anything.

We don't have Everyone or Department B in the permission list on the parent folders. Do we need to add a Browse or Read right for that group on the parent folder level, not just on the document?

0 0
replied on September 21, 2015

The document needs to have Read allowed in at least one place and not have Read denied anywhere up the tree. It could be one of the user's other groups that have read denied on a folder somewhere up the tree.

0 0
replied on September 21, 2015

We do not use the Deny right anywhere in our repository (to avoid things like this). The group is a rights trustee anywhere "upstream".

This is end effect of our workflow, setting the Browse and Read rights for the intended group:

And the corresponding effective rights:

 

If I change the security to This entry only, it works.

Ideas?

0 0
replied on September 21, 2015

Could you reset the Assign Rights activity to the default of "this folder, subfolders and documents", re-publish and re-run the workflow and then check again, please?

0 0
replied on September 21, 2015

Yes, I can try this; however, these folders might contain files that should not be shared. Would changing to the default setting result in sharing unintended files?

0 0
replied on September 21, 2015

Yeah, that's the problem. "Documents only" means "documents in this folder or subfolder", you want to set it to "This entry only"

0 0
SELECTED ANSWER
replied on September 22, 2015

Your screenshots show that your are using the Assign Rights activity on the document, not the folder. So it looks like the activity is applying the option under "if this entry is a folder, apply rights to" to all entries regardless of type. That's definitely a bug and we're looking into it.

However, since you're not dealing with folders in this case, leaving that option to its default value will not have an impact on your security on other entries because documents can't have subfolders or child documents, but it will fix the current issue on the document.

1 0
replied on September 22, 2015

Thanks Miruna! The default setting certainly does work and your explanation about the security makes sense. 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...