I'm developing a JIRA plugin. I want to get all visible projects for a specified user. When I use projectManager.getProjectObjects(), it returns all projects. But I want to get only projects which are visible and accessible and browse-able by specified User.
How can I do that?
You want to use PermissionManager.getProjectObjects(Permissions.BROWSE, user) (or one of the other methods with the same name in that class, depending on the exact version of JIRA you are targeting).
Related
I can use the JIRA connector with the Create a new issue (V2) action to create a jira ticket using logic apps. However, I want to put the project name in a parameter file as it will vary depending on whether the logic app is in dev or production.
The top part of the screenshot is my attempt at using a variable which comes from a parameter file. The bottom part is when I hard code the project name.
How can I vary the name of the JIRA project depending on whether it's in dev or production using the JIRA connector in logic apps?
I'm developing a grails application that uses export:1.6 plugin, but for particular reasons in some cases the result of an action using services is wrong, so I had to get in the methods of the plugin and I had to make son modifications inside the plugin, trouble comes when I want to commit it in our SVN repository (because we are working in a develop team), I'm going to update the app with the plugin modified, but when another person downloads it, the original plugin is going to be originally installed. So I thought to create a new plug in, but, do you have any another suggestion? or if the best way is to create a new plugin, how can I publish it in our Repo? oris it possible to download it with my changes?
This question is similar to this one. In your case, you are better off creating a new plugin.
I have a sizable Grails application that has a small handful of controllers and views, and a very large number of Services.
I now need to build a "reskinned" version of the same site which has its own set of views and controllers (there are some smallish differences in how the controllers work), but the exact same set of Services. One option is to move all of the services into some kind of common place via custom Grails plugins, but I'm wondering if there's another way.
What I'd like to do is have two packages in the controllers folder, com.company.sitea and com.company.siteb, with an environment variable that effectively chooses which one of those is used. Similarly, two different sets of views, each one selected based on this environment variable, but with a shared taglib.
I was unable to find anything obvious that did this, is there a plugin or a standard way of doing this (or something similar)? The idea is, I'd have one codebase, I'd build one war, but the war would be deployed in two different places, and each one of those would specify a value for a special environment variable.
We have been successfully using a pattern where we make the first application a plugin. It will be run as an application for the first use case and included as a plugin to the second use case.
If you do this (a grails application is a application and plugin at the same time), you have to exclude the plugin from starting up when it's run as an application. Otherwise the application will start it self twice: as an application and as a plugin. The "grails.plugin.excludes" configuration setting (explained here) prevents this from happening.
I have documented this special use case in this jira issue:
http://jira.grails.org/browse/GRAILS-6751
"Allow a Grails application to be used as a Grails plugin besides using it as an application"
This has turned out to be a killer feature for us in many cases. We have been able to reuse applications as plugins in other use cases and combine several separate applications to one with this feature. Of course there are some restrictions (like name conflicts) but that hasn't been a problem for us.
The most common use case is to reuse a full application and just override the views in another one. Since an existing application can be an application and plugin at the same time, there is no extra work in extracting "common parts" to a separate plugin.
To make an existing Grails application a plugin you just have to add a MyAppNameGrailsPlugin.groovy file to the root directory and add this configuration value to grails-app/conf/Config.groovy:
grails.plugin.excludes = ['myAppName'] (application name in camel case starting with lower case letter)
Mailing list discussion:
http://grails.1312388.n4.nabble.com/Dynamic-applications-extending-an-existing-application-with-Grails-tp4634094p4634202.html
Burt's detailed blog post:
http://burtbeckwith.com/blog/?p=1973
David Dawson's presentation:
http://skillsmatter.com/podcast/home/large-scale-grails-using-plugins-how-to-modularise-an-application/jd-8012
one important factor is whether both of these versions should operate on the same data? so they will be different front-ends over same database? or they will be completely separate, for example per-customer deployment?
if the first, I would go webservices way, so one app would contain business logic, and controllers working as webservices, and other app would just have different controller, "talking" to the first one
you could also combine everything in one project (both versions) and limit access to different controllers from different domains with apache unmounts
if the latter, I would also try to extract common part into a plugin
We are currently attempting to setup an instance of Jenkins as our build system for our code base. We have multiple jobs setup (all using the same depot) to build different sections of the code.
We would now like to show the submits from all users pertaining to this depot on the main Jenkins screen rather than being able to view the change lists involved with a certain build (e.g. by selecting a certain job and then the link leading to the build information, etc...). I've looked into possible plugins and the closest one I was able to find was the "All Changes Plugin". This is exactly what we would like, but this is only visible when viewing the details of a build (e.g. which CLs were used to create the build), but would it be possible to show this type of information on the main Jenkins page instead?
Thank you in advance for your help.
You could write an extension for the Dashboard View plugin to provide a portlet containing an aggregated list of changes from perforce, though if you aren't experienced with writing plugins then you might be better off using a separate repository browser such as Fisheye or P4Web to display your changes.
When a project is created in Jira, the jira-users group is added by default, which gives all users access to the project (which we don't want). I know that this can be changed manually after the project is created, but is it possible to configure Jira so that another group is used by default?
I believe to do this you go to the Administration Screen -> Project Role Browser and remove jira-users from the Default Members for the Users Role.