- 18 3月, 2014 5 次提交
-
-
-
由 Oleg Nenashev 提交于
The fix allows to explicitly disable automatic page refreshes in the @view extensions. Resolves https://issues.jenkins-ci.org/browse/JENKINS-21190Signed-off-by: NOleg Nenashev <o.v.nenashev@gmail.com>
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
- 17 3月, 2014 7 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 15 3月, 2014 6 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
The intent of this test is to make sure that a floating User object without any storage returns false from canDelete() method. The earlier change made User.impersonate() to actually check if the user is a valid, so to make this test case work where it does "user.impersonate" and "user2.impersonate2", I'm creating valid accounts for these two users. Now what that means is that user2 is no longer a floating flyweight storage-less User, so it breaks the assumption of the "User should not be able to delete because he is not saved." assertion. To make this test case work, I'm introducing the 3rd user that is storage-less, and using it for the test.
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
由 Kohsuke Kawaguchi 提交于
These tests weren't using a SecurityRealm that recognizes these user names
-
由 Kohsuke Kawaguchi 提交于
-
- 14 3月, 2014 10 次提交
-
-
由 Jesse Glick 提交于
There seems to be no way to export this over the REST API without incurring serious performance penalties.
-
由 Jesse Glick 提交于
Fix terminology used in BuildTrigger conditions
-
由 Harald Albers 提交于
Added some missing German translations
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 phoenix384 提交于
-
由 phoenix384 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
So far none of them are real regressions but just that I needed to update tets
-
由 Kohsuke Kawaguchi 提交于
Now that User.impersonate() actually checks if the user is valid, User.get("user").impersonate() is expected to fail. Use a DummySecurityRealm to make this user a valid user.
-
- 13 3月, 2014 5 次提交
-
-
由 Jesse Glick 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 12 3月, 2014 7 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
See javadoc for discussion why this possibly redundant use is desirable
-
由 Kohsuke Kawaguchi 提交于
I think the cleanest place to do this is as a filter of UserDetailsService. The problem is that SecurityRealm defines loadUserByName method, which AbstractPasswordBasedSecurityRealm overrides
-
由 Kohsuke Kawaguchi 提交于
So ApiTokenFilter no longer needs to do that.
-
由 Kohsuke Kawaguchi 提交于
-