After reading more closely the help, I decided to upload another image, this time showing global project permissions. There is no per-project permissions.

I think your screenshot shows exactly the situation described in the help.. your project is not accessible to the group for all authenticated users (I think it's called "authenticated", if I remember correctly).

Do you mean that the group (the second row on the matrix authorization strategy screenshot) needs to be granted the same permissions as the user who has the most permissions?

No, I mean add a new row for the group called "authenticated" that grants job read permission.

Thank you. It works now.

My only comment is that the documentation could be clearer. It says "...the source project must be accessible to all authenticated users;..." May I suggest instead something like "you must have a group called 'authenticated' and grant the Job Read permission to this group". What confounded me is that I did have the Job Read permission granted for all the users and the group defined in the screenshot, so to me, I was not missing anything. Maybe the error message could say something along these lines as well. Thank you for the help.

Hi I wish to reopen this bug since it is actually a bug for a different reason, namely that the use has access to the selected job if he doesn't use dynamic project name, but hard codes it instead. The fact that one must enable read access for specifying a project via a dynamic variabe vs. specifying it in a hardcoded fashion indicates there is a bug in copy artifacts which should forbid the access unless the authenticated group is added with read permissions for jobs. (This is a very badly documented feature, and has caused me no end of trouble)

I think that really relies on JENKINS-16956.

I see what happens in Jenkins:

• Why it happens only when using a build parameter for the project name ?
  • This is for the access check in building is performed only when using a build parameter.
  • If not using a build parameter, the access check is considered performed when saving the configuration.
• Why the access check fails?
  • Access check is performed twice:
    1. By Jenkins (Jenkins#getItem()). The authentication token is SYSTEM. (Jenkins.getAuthentication())
    2. By Copy Artifact plugin. The authentication token is an anonymous authennciated user.
       • I think this is expcected to work when configured with "Logged-in users can do anything".
  • The latter check fails in this case.

I have following two ideas:

• Do access check with an authentication token of a user who triggered the build.
  • This works for projects whose builds are tirggered manually.
  • This does not work for projects with scheduled builds, or SCM polling builds.
• Add an option to ignore access permissions.
  • This should be designed to work only when the copiee project is configured to allow it.

I sent a pull request for the former change: https://github.com/jenkinsci/copyartifact-plugin/pull/24

For the latter idea, I will work in JENKINS-20398.

Code changed in jenkins
User: ikedam
Path:
src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
http://jenkins-ci.org/commit/copyartifact-plugin/6f920cde153c03383271b0a1435528f21c723a88
Log:
[FIXED JENKINS-14999] Check permission to the project to copy from by the user triggered that build.

Code changed in jenkins
User: ikedam
Path:
src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testPerProjectPermissionTriggeredByUser/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testPerProjectPermissionTriggeredByUser/users/admin/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testPerProjectPermissionTriggeredByUser/users/test1/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testPerProjectPermissionTriggeredByUser/users/test2/config.xml
http://jenkins-ci.org/commit/copyartifact-plugin/46540cc88dee2ecc56ede5c389b48e4f89d1c539
Log:
JENKINS-14999 Add a test for per-project per-user permissions.

Compare: https://github.com/jenkinsci/copyartifact-plugin/compare/f468296f905b...46540cc88dee

As described in https://github.com/jenkinsci/copyartifact-plugin/pull/24 , we should resolve this issue using QueueItemAuthenticater.
Above commits are merged by some accidents, and should be reverted.

Code changed in jenkins
User: ikedam
Path:
src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testPerProjectPermissionTriggeredByUser/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testPerProjectPermissionTriggeredByUser/users/admin/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testPerProjectPermissionTriggeredByUser/users/test1/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testPerProjectPermissionTriggeredByUser/users/test2/config.xml
http://jenkins-ci.org/commit/copyartifact-plugin/ce20ba90919582a0c6cc3b262f7d6cbbb7b36f5e
Log:
JENKINS-14999 Reverted unintended merging of #24. I'll handle this problem using QueueItemAuthenticator instead. Reverted 6f920cde153c03383271b0a1435528f21c723a88 and 46540cc88dee2ecc56ede5c389b48e4f89d1c539 .

Sent a pull request https://github.com/jenkinsci/copyartifact-plugin/pull/26 .

Code changed in jenkins
User: ikedam
Path:
src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
http://jenkins-ci.org/commit/copyartifact-plugin/84594eccc100d1ac6e77703aa7b53b963fccf97a
Log:
[FIXED JENKINS-14999] The authorization of builds are considered (when used with QueueItemAuthenticator). QueueItemAuthenticator is available from Jenkins 1.520.

Code changed in jenkins
User: ikedam
Path:
src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testQueueItemAuthenticator/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testQueueItemAuthenticator/users/admin/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testQueueItemAuthenticator/users/test1/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testQueueItemAuthenticator/users/test2/config.xml
http://jenkins-ci.org/commit/copyartifact-plugin/c0cde9aa27bc9f74c41d549ca28f737f3f648819
Log:
JENKINS-14999 Added tests for supports of QueueItemAuthenticator. As it works only with Jenkins >= 1.521, it is commented out for now.

Code changed in jenkins
User: ikedam
Path:
src/main/java/hudson/plugins/copyartifact/CopyArtifact.java
src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testQueueItemAuthenticator/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testQueueItemAuthenticator/users/admin/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testQueueItemAuthenticator/users/test1/config.xml
src/test/resources/hudson/plugins/copyartifact/CopyArtifactTest/testQueueItemAuthenticator/users/test2/config.xml
http://jenkins-ci.org/commit/copyartifact-plugin/0be74e3ba5ce6ac1e3d92e7c5bfaebce2e54a4b9
Log:
Merge pull request #26 from ikedam/feature/JENKINS-14999_SupportQueueItemAuthenticator

JENKINS-14999 Support for QueueItemAuthenticator

Compare: https://github.com/jenkinsci/copyartifact-plugin/compare/78fb29a1087c...0be74e3ba5ce

Fixed in Copyartifact 1.29

Code changed in jenkins
User: ikedam
Path:
src/test/java/hudson/plugins/copyartifact/CopyArtifactTest.java
http://jenkins-ci.org/commit/copyartifact-plugin/ec41cbdd914d33d606734b8f36460efc25913af4
Log:
Merge pull request #60 from ikedam/feature/JENKINS-14999_EnableTestsForQueueItemAuthentication

JENKINS-14999 Enabled tests for QueueItemAuthenticator

Compare: https://github.com/jenkinsci/copyartifact-plugin/compare/47e05f2703db...ec41cbdd914d

Hi,

The issue reoccurs with Jenkins core 1.596.2 and copy-artifacts version 1.35.
Tested it with any of the parameters and I still get same issue.

It seems like now you need to give special permissions at the source job to allow specific jobs to copy artifacts.

In Jenkins ver. 1.609.3 with Copy Artifact Plugin 1.36.1 I hit this issue. As a workaround if I set Permission to Copy Artifact - Projects to allow copy artifacts to * the problem is resolved.

But this is still a bug. It should not behave differently depending on whether the job name is hard coded or comes from a parameter.

I have this same issue.

Jenkins ver. 1.642.1
Copy Artifact Plugin ver 1.37
CloudBees Folders Plugin ver 5.1

On the upstream trigger job,
I have explicitly set "Permission to Copy Artifact - Projects to allow copy artifacts"
for the full downstream job name including Folder-Plugin's foldername "FOLDNER_NAME/DOWNSTREAM_PROJECT_NAME".

But this still causes the error on the downstream job:
ERROR: Unable to find project for artifact copy: FOLDER_NAME/DOWNSTREAM_PROJECT_NAME
This may be due to incorrect project name or permission settings; see help for project name in job configuration.

If on the upstream trigger job,
I have explicitly set "Permission to Copy Artifact - Projects to allow copy artifacts"
for the full downstream job name to wildcard '*',
then the problem solved.

After some further combination of trials,
I found out that "Permission to Copy Artifact - Projects to allow copy artifacts" must set to a project name without FOLDER_NAME.

This resolves the problem too.
However,
there's a misleading warning "Unable to find project:"
when set the upstream job "Permission to Copy Artifact - Projects to allow copy artifacts"
to a DOWNSTREAM_PROJECT_NAME only without FOLDER_NAME.

I'll create a separate JIRA ticket for that.

created JENKINS-33257 for the misleading warning

I'm still getting this in 1.3.7 / Jenkins ver. 1.651.1

19 May 2016 - still having same issue. Rick's suggestion didn't work for me.