Let assume that I have several changes in review state in Gerrit.
Can I be notified (via email) when "merge conflict" appears on one of my changes?
Have a nice day,
Adam
You can't receive this information by e-mail (unless you wrote a script to automate this task using REST) but you have other good options:
Search field
You can use the Search feature to search for the following:
owner:username AND status:open AND NOT is:mergeable
This will show your open changes with conflicts.
My Menu
You can add a menu entry for the search showed above at Settings > Preferences > My Menu adding the following URL:
#/q/owner:username+AND+status:open+AND+NOT+is:mergeable
Related
I created a webhook for "Jira / Microsoft Teams" integration.
We need to get updates on anything happening on "bug" issues (creation, updates) into a Teams channel.
We created this JQL:
project = General AND issuetype = bug AND status changed
But this is just for the status and does not support anything else (creation, updates in other fields etc.)
Unfortunately I cannot use the checkbox options either because I have no way to choose the equivalent of issuetype = bug there.
I assume that the only way is JQL but I cannot find a way to describe "report all changes in the bug", plus I did not see it working even for the status change I reported above.
Is there a solution to this?
Thank you.
UPDATE: If I combine both like that, it seems to partially work. Partially because changes in the Description are not triggered, etc. How can these be triggered too? (i.e. EDITS in Description, etc.).
A colleague sent me a Gerrrit code review "draft" (I suppose via "refs/drafts/master" instead of "refs/for/master") and then left on holiday. Without downloading the patch and submitting it myself, how can I promote his draft to a full regular code-review so I can approve it & submit it for merging?
I think this is a similar question, but it's for git-review, not Gerrit. Also I'm interested in doing it from the Gerrit web GUI if at all possible. And I don't see a "Publish" button on my Gerrit web GUI for that draft. (And currently it doesn't say anything about merge conflicts, as long as I hurry....)
If I click on the "Patch Sets" link in the top right of the GUI, this is what I see:
In the top left it says "Change 58358 - Draft", and in the middle of the window it shows this:
Only the change owner can publish a draft patch set. Using the UI's cherry-pick option as described in other answers won't work because the cherry-pick implementation preserves the draft status on the new change or patch set.
As far as I know the only way to force the change into NEW state is to manually download the commit and push a new patch set using refs/for/master instead of refs/drafts/master.
Note that if you're not rebasing the change onto a new parent at the same time, you might need to slightly edit the commit message to make gerrit accept it. Otherwise it'll reject with no new changes.
If your colleague add you as reviewer, you can. You can cherry-pick this commit.
Click on download link at the right-top corner, and there are aliases for commands above.
But as you updated your question, you don't want to check out and manually push or cherry pick to master branch. You can use cherry-pick\merge button on ui, if you are confident in this mr, and it should be on master branch. Also you can publish this commit for other reviewers.
p.s. updated (you can cherry-pick, merge, publish via UI)
Do the following procedure:
1) Go to the draft change page
2) Click on Cherry Pick button
3) Write "master" in the Cherry Pick to Branch field
4) Adjust the Cherry Pick Commit Message if needed
5) Click on Cherry Pick Change button
It'll be created a NEW CHANGE cherry-picked from the draft change. Go to the new change page and follow the regular Gerrit process (review, approve, submit). The original draft change can be abandoned or deleted.
I want to prevent my users from logging work once an issue gets to a particular status. How can I accomplish this?
I have a post-function in my workflow that sets the Resolution, but the "Log Work" item in the More menu still shows up.
I don't see in the Project or System administration any options about it.
You can accomplish this by setting jira.issue.editable to false in the properties of the status in the workflow.
Find the active workflow that applies to the issues you wish change. This is most easily done by either: going to the 'Workflow Schemes' admin page, then clicking on the Workflow link in the row applying to the issues' project and issue type, or clicking View Workflow in the Issue View.
To edit the workflow, you will need to either create a copy of it (if using the default jira system workflow) or edit the draft of the workflow.
In the Workflow Editor, for the 'Closed' step, click View Properties (in Text mode) or Properties (in Diagram mode) to see the step properties.
Editing issues in the selected step is enabled by default, or you will see a jira.issue.editable property with value true. Either create the value or chang the property value to false.
Publish your draft workflow, or if editing a copy, activate the workflow by creating a new workflow scheme associated with the edited workflow, and then associating it with your project.
Reference: https://confluence.atlassian.com/jira/allow-editing-of-closed-issues-138704.html
In my implementation of JIRA, I have a custom field called Developer which gets populated automatically (username) whenever someone move the JIRA from Open to Fixed state. Now I want something similar for the Fixed to Reopen transition. That is, whenever the tester changes the status to Reopen, it should go back to the Developer or the Project Lead (in case the field isnt populated as the custom field can be overridden).
I tried to implement a post function, but there isn't a way where I can use OR criteria. Or is there a way?
You can do a Post Function on the transition using the Script Runner plugin if its a self-hosted JIRA instance which will allow you great flexibility in the logic to fill the target field in.
I finally managed to find a workaround for this.
Download the Workflow Enhancer for JIRA plugin (FREE). You would also need JIRA Suite Utilities (I had it installed already for some other customization)
In the Fixed to Reopen transition, add a Post Function and use Copy Value From Other Field to update Assignee from Developer field
Then add another Post Function underneath this where you need to use Universal Post Function. Here make the boolean condition as {Assignee}=="" and select Choose post function to execute: as Assign to Lead Developer
Publish the draft.
The goal we'd like to achieve is allowing a customer to view a read-only dashboard which would display the status of only that customer's issue(s). This could be a default dashboard assigned to/associated with a particular group. Is there a way to configure a dashboard to accomplish that?
Thanks in advance for whatever help you can provide!
The edit permission is controlled by the permission scheme used by a project that issues are in. So to make the displayed issues read-only you'll need to decide which JIRA projects the issues come from and change the permission scheme for all those projects.
To create a read-only dashboard, you must edit the workflow (Project/Administration/Workflows/Scheme:Edit) in the (Flash-based) Workflow Editor.
I suggest that you start by cloning the default workflow and making changes to the clone (rather than editing the default).
There will be items in a "Global Transitions" list. By default, all members of the "users" group will have the power to execute these transitions (even if you have altered your project's Permissions Scheme to prevent read-only users from creating issues or comments, for example).
1> Remove all of the items in the "Global Transitions" list
There will be items in a "Statuses" list. The "Resolved" status is an implicit part of the "Done" global transition, so it needs to be added to the workflow.
2> Drag the "Resolved" item from the "Statuses" list to the workflow.
Creating a transition involves selecting one of the 3 buttons, grouped with the mouse-pointer button, on the upper left corner of the Workflow Editor.
3> Select a transition type (Straight Line, Polygonal Line, Bezier Line) using the above buttons.
4> Click (and release) on the starting point of the transition (for example, "In Progress"). An arrow will appear under the mouse pointer.
5> Click (and release) on the destination point of the transition (for example, "Done"). You will be prompted to give the transition a name (the text that you enter for this name will appear on a button, in classic issue views, that performs the transition), such as: "ChangeToDone".
The new transition is now available to everyone, unless you lock it down with some conditions:
6> Click on the gear-like button (to the right of the transition name) and select "View Conditions".
7> Click on "Add a new condition to restrict when this transition can be performed".
8> Select a condition (such as "Only Assignee Condition"), scroll to the bottom of the list, and click the "Add" button.
Now you should have a workflow transition that can only be performed by users who meet the required conditions.
Repeat the above steps to craft conditional transitions between all of the statuses that you use in your project.
To use your new workflow scheme with your project, click the "Switch Scheme" button (Project/Administration/Workflows/Scheme) and then click the "Associate" button.
Once the association process is finished, sign-in as a user that does not satisfy any of the transition conditions. You should be unable to perform transitions when signed-in as this user.