If a user is editing any job, all jobs accessible to that user lose their downstream build triggers to jobs that are inaccessible to the editing user.

Example:
1. Jenkins is using a project-based security model (e.g. project-based matrix or role strategy plugin)
2. There are two users, Admin (full access) and User (restricted access).
3. There are three jobs, U (upstream), D (downstream), and E (edit).
4. Give User read-only access to job U and read/config access to job E. Give User no permissions for job D.
5. Admin adds a downstream build of job D to job U. This association is invisible to user U1 despite read access to job U.
6. User edits job E

Expected result
Job U is not affected.

Actual result
The build trigger of job D is removed from job U despite User neither having editing permissions to that job, nor actually accessing that job.

Workarounds
Use parameterized build trigger and check [x] trigger without parameters

Notes

• Something similar would probably happen when User is editing job U despite nobody expecting removal of the invisible association, but there's at least some connection between User's action and the removal of the association.
• Classified as blocker, since this issue is difficult to track down (even with e.g. job config history plugin), bypasses Jenkins security, and can break a lot of job upstream/downstream associations for no apparent reason.