[JIRA] (JENKINS-62172) PluginManager.installPlugin() is failing with invalid crumb issue
Title: Message Title
A. Jard updated an issue
Jenkins / JENKINS-62172
PluginManager.installPlugin() is failing with invalid crumb issue
Change By:
A. Jard
Using PluginManager.installPlugin() in test to install a very specific version of a plugin is broken with:{code:java}java.io.IOException: Failed to upload plugin: HTTP/1.1 403 Forbidden{code}I know that this method is deprecated, but I don't see any replacement to install a specific (old) version of a plugin. {color:#172b4d}{{@WithPlugins()}}{color} is installing a newer version, and same behavior for{{{color:#172b4d} PluginManager.installPlugins(){color}}}.I have reproduced it with a test, I am going to push a PR with that test just after, I can try to fix it but I am not sure on how to add the crumb to the HTTP request so any hint or help are welcome there.If you think that this method can be replaced with something else as a workaround please tell me also.I know that I can disable the crumb verification as a workaround but I wish to have it working fine with the crumb enabled. PR is here https://github.com/jenkinsci/acceptance-test-harness/pull/572
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
[JIRA] (JENKINS-62172) PluginManager.installPlugin() is failing with invalid crumb issue
Title: Message Title
A. Jard created an issue
Jenkins / JENKINS-62172
PluginManager.installPlugin() is failing with invalid crumb issue
Issue Type:
Bug
Assignee:
Oliver Gondža
Components:
acceptance-test-harness
Created:
2020-05-06 08:48
Priority:
Major
Reporter:
A. Jard
Using PluginManager.installPlugin() in test to install a very specific version of a plugin is broken with:
java.io.IOException: Failed to upload plugin: HTTP/1.1 403 Forbidden
I know that this method is deprecated, but I don't see any replacement to install a specific (old) version of a plugin. @WithPlugins() is installing a newer version, and same behavior for{{ PluginManager.installPlugins()}}. I have reproduced it with a test, I am going to push a PR with that test just after, I can try to fix it but I am not sure on how to add the crumb to the HTTP request so any hint or help are welcome there. If you think that this method can be replaced with something else as a workaround please tell me also. I know that I can disable the crumb verification as a workaround but I wish to have it working fine with the crumb enabled.
[JIRA] (JENKINS-60266) Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER
Title: Message Title A. Jard commented on JENKINS-60266 Re: Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER Updating description to match the name agreed on Jep and google group discussion (from CONFIGURE to MANAGE). CONFIGURE should not be anywhere anymore. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203254.1574682467000.7403.158080229%40Atlassian.JIRA.
[JIRA] (JENKINS-60266) Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER
Title: Message Title A. Jard updated an issue Jenkins / JENKINS-60266 Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER Change By: A. Jard I create this Jira to follow the work in progress about "Sensible permission" related to the JEP that is in draft status for now and can be found here [https://github.com/jenkinsci/jep/pull/249]The main goal is to have a new permission called `Jenkins. CONFIGURE MANAGE ` to allow management of Jenkins. All sensible or security related items are restricted to `Jenkins.ADMINISTER`.The draft PR with this new permission implementation is [ https://github.com/jenkinsci/jenkins/pull/4374 ] Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit
[JIRA] (JENKINS-60694) JellyTestSuite fails with timeout issue on Windows runner because it uses HudsonTestCase instead of JenkinsRule
Title: Message Title A. Jard created an issue Jenkins / JENKINS-60694 JellyTestSuite fails with timeout issue on Windows runner because it uses HudsonTestCase instead of JenkinsRule Issue Type: Bug Assignee: Oliver Gondža Components: jenkins-test-harness Created: 2020-01-08 13:36 Environment: Windows agent on kubernetes jenkins-test-harness-2.57 and above with jetty version greater than 9.4.6.v20170531 Priority: Minor Reporter: A. Jard The test class TestInjection generated by maven-hpi-plugin fails to run the test suite with a timeout exception when updating jenkins-test-harness from 2.56 to 2.57 on Windows agent. The same mvn install command run on a Linux agent run fine. After investigation, the reason is that JellyTestSuite is based on HudsonTestCase, and HudsonTestCase does not work on the Windows agent with a jetty above 9.4.6.v20170531. Between jenkins-test-harness-2:56 and jenkins-test-harness:2.57 jetty version has changed from 9.4.5.v20170502 to 9.4.22.v20191022. Setting jetty version to 9.4.6.v20170531 in maven dependencies with jenkins-test-harness:2.57 (and above) solve the issue. JellyTestSuiteBuilder should be updated to use JenkinsRule and not the deprecated HudsonTestCase. https://github.com/jenkinsci/jenkins-test-harness/blob/0e0ec3c9ccbe6314d488faa248e2f50f312f3cad/src/main/java/org/jvnet/hudson/test/JellyTestSuiteBuilder.java#L138 Link to maven-hpi-plugin code that generate the TestInjection class: https://github.com/jenkinsci/maven-hpi-plugin/blob/master/src/main/java/org/jenkinsci/maven/plugins/hpi/TestInsertionMojo.java
[JIRA] (JENKINS-60579) Impossible to have an invisible property on View that is persisted on save
Title: Message Title
A. Jard updated an issue
Jenkins / JENKINS-60579
Impossible to have an invisible property on View that is persisted on save
Change By:
A. Jard
DescriptorVisibilityFilter is not used to filter properties that are displayed on the View edition.The same method View.getApplicablePropertyDescriptors() is used both to filter displayed properties on UI and to filter properties that are saved with the View.The only way to *not show a property in UI* is to use ViewPropertyDescriptor but then the property is not persisted and *is removed when the users edit view* and save it.{code:java}@Extensionpublic static final class DescriptorImpl extends ViewPropertyDescriptor {@Overridepublic boolean isEnabledFor(View view) {return false;}}{code}*That means that it's not possible to have some hidden properties for View that are persisted.*This method is used in jelly to filter properties: [https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/View/configure.jelly#L55]And it's also used in View to filter properties that are persisted: [https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/java/hudson/model/View.java#L1012]I looked at Job configuration, a specific method based on DescriptorVisibilityFilter is used in jelly. [https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/Job/configure.jelly#L51]So this code should work for View when a plugin need to have an invisible property:{code:java}@Extensionpublic static final class DescriptorVisibilityFilterImpl extends DescriptorVisibilityFilter {@Overridepublic boolean filter(Object context, Descriptor descriptor) {return false;}}{code}I already did a test that show this issue it's on that PR: https://github.com/jenkinsci/jenkins/pull/4404I propose to add a new method in View to filter properties that use DescriptorVisibilityFilter to filter properties visible on UI and use it in View/configure.jelly. I will do Rule test to reproduce the code modification issue and the proposed correction are done in the same PR : [https://github . com/jenkinsci/jenkins/pull/4404]
Add
[JIRA] (JENKINS-60579) Impossible to have an invisible property on View that is persisted on save
Title: Message Title
A. Jard updated an issue
Jenkins / JENKINS-60579
Impossible to have an invisible property on View that is persisted on save
Change By:
A. Jard
DescriptorVisibilityFilter is not used to filter properties that are displayed on the View edition.The same method View.getApplicablePropertyDescriptors() is used both to filter displayed properties on UI and to filter properties that are saved with the View.The only way to *not show a property in UI* is to use ViewPropertyDescriptor but then the property is not persisted and *is removed when the users edit view* and save it.{code:java}@Extensionpublic static final class DescriptorImpl extends ViewPropertyDescriptor {@Overridepublic boolean isEnabledFor(View view) {return false;}}{code}*That means that it's not possible to have some hidden properties for View that are persisted.*This method is used in jelly to filter properties: [https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/View/configure.jelly#L55]And it's also used in View to filter properties that are persisted: [https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/java/hudson/model/View.java#L1012]I looked at Job configuration, a specific method based on DescriptorVisibilityFilter is used in jelly. [https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/Job/configure.jelly#L51]So this code should work for View when a plugin need to have an invisible property:{code:java}@Extensionpublic static final class DescriptorVisibilityFilterImpl extends DescriptorVisibilityFilter {@Overridepublic boolean filter(Object context, Descriptor descriptor) {return false;}}{code}I already did a test that show this issue , I will link the it's on that PR to this JIRA : https://github . com/jenkinsci/jenkins/pull/4404 I propose to add a new method in View to filter properties that use DescriptorVisibilityFilter to filter properties visible on UI and use it in View/configure.jelly.I will do the code modification in the same PR.
Add Comment
[JIRA] (JENKINS-60579) Impossible to have an invisible property on View that is persisted on save
Title: Message Title A. Jard assigned an issue to A. Jard Jenkins / JENKINS-60579 Impossible to have an invisible property on View that is persisted on save Change By: A. Jard Assignee: A. Jard Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203704.1577183535000.15332.1577183700066%40Atlassian.JIRA.
[JIRA] (JENKINS-60579) Impossible to have an invisible property on View that is persisted on save
Title: Message Title
A. Jard created an issue
Jenkins / JENKINS-60579
Impossible to have an invisible property on View that is persisted on save
Issue Type:
Bug
Assignee:
Unassigned
Components:
core
Created:
2019-12-24 10:32
Priority:
Minor
Reporter:
A. Jard
DescriptorVisibilityFilter is not used to filter properties that are displayed on the View edition. The same method View.getApplicablePropertyDescriptors() is used both to filter displayed properties on UI and to filter properties that are saved with the View. The only way to not show a property in UI is to use ViewPropertyDescriptor but then the property is not persisted and is removed when the users edit view and save it.
@Extension
public static final class DescriptorImpl extends ViewPropertyDescriptor {
@Override
public boolean isEnabledFor(View view) {
return false;
}
}
That means that it's not possible to have some hidden properties for View that are persisted. This method is used in jelly to filter properties: https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/View/configure.jelly#L55 And it's also used in View to filter properties that are persisted: https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/java/hudson/model/View.java#L1012 I looked at Job configuration, a specific method based on DescriptorVisibilityFilter is used in jelly. https://github.com/jenkinsci/jenkins/blob/d1502bffe8b5d530d31a4d697f064b79a5cab081/core/src/main/resources/hudson/model/Job/configure.jelly#L51 So this code should work for View when a plugin need to have an invisible property:
[JIRA] (JENKINS-60266) Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER
Title: Message Title A. Jard updated an issue Jenkins / JENKINS-60266 Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER Change By: A. Jard I create this Jira to follow the work in progress about "Sensible permission" related to the JEP that is in draft status for now and can be found here [https://github.com/jenkinsci/jep/pull/249]The main goal is to have a new permission called `Jenkins.CONFIGURE` to allow management of Jenkins. All sensible or security related items are restricted to `Jenkins.ADMINISTER`.The draft PR with this new permission implementation will be proposed soon, I will update this Jira when it's done.Feedback are welcome, you can also see the announcement on the dev list: is https:// groups github . google. com/ forum jenkinsci / #!topic jenkins / jenkinsci-dev pull / lThSifB8G4k 4374 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins
[JIRA] (JENKINS-60266) Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER
Title: Message Title A. Jard updated an issue Jenkins / JENKINS-60266 Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER Change By: A. Jard I create this Jira to follow the work in progress about "Sensible permission" related to the JEP that is in draft status for now and can be found here [https://github.com/jenkinsci/jep/pull/249]The main goal is to have a new permission called `Jenkins.CONFIGURE` to allow management of Jenkins. All sensible or security related items are restricted to `Jenkins.ADMINISTER`.The draft PR with this new permission implementation will be proposed soon, I will update this Jira when it's done. Feedback are welcome, you can also see the announcement on the dev list: https://groups.google.com/forum/#!topic/jenkinsci-dev/lThSifB8G4k Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop
[JIRA] (JENKINS-60266) Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER
Title: Message Title A. Jard created an issue Jenkins / JENKINS-60266 Add a Jenkins.CONFIGURE permission to be able to configure Jenkins without ADMINISTER Issue Type: New Feature Assignee: A. Jard Components: core Created: 2019-11-25 11:47 Priority: Minor Reporter: A. Jard I create this Jira to follow the work in progress about "Sensible permission" related to the JEP that is in draft status for now and can be found here https://github.com/jenkinsci/jep/pull/249 The main goal is to have a new permission called `Jenkins.CONFIGURE` to allow management of Jenkins. All sensible or security related items are restricted to `Jenkins.ADMINISTER`. The draft PR with this new permission implementation will be proposed soon, I will update this Jira when it's done. Add Comment
[JIRA] (JENKINS-58571) It's possible to use renameTo for AbstractItem that has name NOT editable.
Title: Message Title A. Jard updated an issue Jenkins / JENKINS-58571 It's possible to use renameTo for AbstractItem that has name NOT editable. Change By: A. Jard The “isNameEditable” value is not checked before doing the real rename action on the renameTo method: [ https://github.com/jenkinsci/jenkins/blob/38e94d197e65af66da67afdc5ebb5d8c0fcf3377/core/src/main/java/hudson/model/AbstractItem.java#L353 ] The rename method can lead to very bad issues if it’s used with item that must not be renamed, the “isNameEditable” must be check before doing any rename action.I am doing did a PR with a unit test and a code change, I will update this JIRA just after changes and unit tests: https://github . com/jenkinsci/jenkins/pull/4122 Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200722.1563538638000.16388.1563539640066%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58571) It's possible to use renameTo for AbstractItem that has name NOT editable.
Title: Message Title A. Jard created an issue Jenkins / JENKINS-58571 It's possible to use renameTo for AbstractItem that has name NOT editable. Issue Type: Bug Assignee: Unassigned Components: core Created: 2019-07-19 12:17 Priority: Major Reporter: A. Jard The “isNameEditable” value is not checked before doing the real rename action on the renameTo method: https://github.com/jenkinsci/jenkins/blob/38e94d197e65af66da67afdc5ebb5d8c0fcf3377/core/src/main/java/hudson/model/AbstractItem.java#L353 The rename method can lead to very bad issues if it’s used with item that must not be renamed, the “isNameEditable” must be check before doing any rename action. I am doing a PR with a unit test and a code change, I will update this JIRA just after. Add Comment
