As part of Gerrit plugin development my requirement is to provide a "button" which should invoke certain operation on a Gerrit change but not all the Gerrit-user-groups should be able to see "that button" on the UI page. Only approved groups should be able to hit that button.
Any help would be appreciated! Thanks :)
I suggest to take a look at the sources of other plugins. For example, the Checks plugin, registers a custom Administrate Checkers permission (1, 2) and in (3) it checks whether a user has this permission granted for a change in that context (via the backend, like any other Gerrit ACL). The frontend (PolyGerrit) displays some options/buttons conditionally based on that permission in (4), but of course the backend should be authoritative for the check to perform the action.
Hope this helps a bit!
The example I gave is for PolyGerrit and should work for ~ 3.0 & upcoming 3.1.
Don't hesitate to get in touch via the mailing list in case you need some more help for specific questions.
Related
I would like to add a button (or a link) in the Gerrit change UI.
The purpose for this button is to extend the Gerrit UI for a specific copyright review by external reviewers (not part of the regular development team).
The idea is that clicking on this button would show up a dialog with options for severity level for the change (Trivial, Low, High). The user would select an appropriate level, and proceed further. It should then send an email with severity level and changes in the review to a predefined list.
I have added a custom label in the Gerrit review UI. The external reviewer can then give either -1 or +1 on the review.
Is this kind of customization possible in Gerrit UI?
I have looked at answer from gerrit-add-a-new-button, but couldn't find a definite answer.
Can someone provide a more detailed answer?
I use Gerrit normally for reviews, but don't know the advanced customization features associated with it.
Thanks for help in advance.
I am running Azure DevOps 2019 RC1 with an Inheritance Collection and a new Agile project.
I have a requirement that when a user creates a work item (task/issue), they must automatically be added as a follower of this work item. How can I achieve this? I have look in the rules for the work item under process customisation but it doesn't appear to be possible this way.
We are using the tickets to track issues. Whoever discovers the issue raises the ticket. The basic requirement is that anyone who raises a ticket should be automatically notified of its progress, even though they are not responsible for the development or testing.
Currently the work around is telling the user that when they create an issue they must click the Follow button, but it is easy for them to forget and then lose their updates. It seems like a very simple customisation so maybe I'm missing the obvious.
Thanks
I think you can't auto follow things currently, but you can add notification setting that will send automatically emails when work item is updated. To do this, go to Project Settings > Notifications page and create new subscription. Select "Work/A work item is changed" and put "Members of ... team by role" in Deliver to selection. Set roles to "Created by" and untick the "Skip initiator".
Your problem would be addressed precisely with the feature requested in the official Azure DevOps' feedback platform here:
479189 - Automatically follow work items I interact with
(That page also mentions workarounds, including per-team one answered here, and a per-person alternative. See this comment. The shortcoming of both is that they don't allow to you to unsubscribe for selected tickets.)
Experience with Jira is based on what I have seen from clicking through the project. There is no knowledge transfer as all people who knew this customized system left over a year ago.
As for the Atlassian PDF guide, it is not able to assist because the feature to add users and manage the users in Jira have been removed. An external LDAP system is where the users are managed.
I can view the User Browser and see users and do some editing of a profile and even delete the user from a navigation link in the footer.
But the real question at hand is, what do I need to do in order to
A. Assign users to an Organization Role that only allows them
1: A view only mode of the users in that Organization
2: View the details of the user and that users permissions/roles given
I've been looking for a few days now and just keep running into brick walls.
Thank you.
The upgrading of the system to the new version is not an option due to the extensive undocumented modifications made to Jira. It has been tried 3 times in the past 2 years without success.
I am answering based on JIRA 5.2 and higher experience.
Only place to see list of users is User Manager and you need to be JIRA admin to access it. So it's not a solution for you.
I searched for addon doing this but no luck. Moreover your JIRA is too old to be supported by addon providers.
The same story with JIRA REST API. Looks like for JIRA 4.1 you need to use JIRA REST 1.0 (current is 2.0) and I can not find docs for it.
I believe it's possible to write the addon to accomplish what you need but again it's not smart to invest in obsolete JIRA.
The most right solution is still migrate to the newest version of JIRA. Maybe you need abandon the undocumented changes or rewrite them into JIRA addons. It will not be easy and it can be costly but looks like you do not have too many options.
Task has been abandoned.
No answer to bad implementation and poor engineering practices when one is to continue to follow them.
I'd delete the post entirely but I'd rather give credit to the few that tried to provide some insight. Thanks again.
I've been reading some feature request-style threads in Atlassian's own JIRA install on how to disable (not remove) users in JIRA, and their suggested solution involves a series of UI actions. For the number of users that our organization supports, this needs to be automated with the rest of our employee account provisioning logic.
I've been looking in the JIRA database and found the membershipbase table, but simply removing records from here WHERE USER_NAME="$username" doesn't seem to have a completely successful outcome. When I go to the User Browser in the Administration section and look up that user, groups still appear for the user.
Does anyone have any experience with this that could point me in the right direction on any other tables I need to modify?
Thanks in advance,
-aj
Maybe you should take a look at Atlassian's Crowd. Even if you don't use SSO, it may help you to integrate with your existing infrastructure for handling authentication and authorization (i.e. groups) centrally. It also provides an administrative frontend that is designed for the corresponding tasks.
You could have a look at the EditUserGroups.setGroupsToLeave() method. As far as I remember, users need to be in the jira-users group to log in. So, if you remove this group from the user, it may be effectively what you need (not delete but deactive user acount).
If this does not help, I'd look into the source code of JIRA (which is available for all types of licenses afaik) to see which tables are modified by the above method.
I am using Jira for organizing user stories for my project on Agile approach. When I tried to close a user story it shows the status as ' Resolved', rather than 'Closed'.
Can someone help me how to change the user story status to closed?
Please post your suggestions and help.
Its a bit hard to answer such a vague question - so if you can ellaborate a bit on the customization you have done in your JIRA instance, it can help.
Some pointers:
JIRA is using workflows to manage the flow an issue can use.
The default workflow that comes with an installation of JIRA is called "jira" and looks like this: https://confluence.atlassian.com/display/JIRA/Configuring+Workflow
Depending on the customization of your JIRA installation, you can either change the workflow to go from Open to Closed when you use the "Resolve" operation.
If you are not the JIRA administrator, different workflow transitions can have various properties and conditions and validators set on them, for example checking for permissions. So if you are a user that does not have permissions to do a certain transition - you can see if you can change it via the permissions administation panel, or again - in the workflow validations.