I would like to implement simple workflow system inside the Bestpractical RT.
My approach is:
Participant (RT user) creates or is given Workitem (Ticket) inside the Business Process (Queue)
OnResolve scrip checks change Ticket status to Open and change TicketOwner to next Participant.
OnReject scrip changes Ticket status to Open and gives it back to previous Participant.
My questions are:
- Is there good scrip examples to manipulate statuses?
- How can I debug scrips?
- How to disable built-in scrips for queues?
I read that it is possible to create a module for RT with actions which can then be called from scrips, but cannot find good documentation/examples. Please advise if you have one.
And the last question, how to enable developer mode in RT?
Thank you very much in advance,
Alexei
I'll assume you're running an RT version 4.0.x.
For the workflow you described, you probably want to create new tickets for each phase rather than having tickets set to resolved, then re-opening them. You can create new tickets in scrips to do this. You can also create link relationships between them like Depends On or Parent Child.
You can find user-contributed samples of various conditions on the RT wiki. You'll see a bunch of debug output for scrips if you turn on debug mode in your logging config. You can also put warn statements in code to see additional output in the RT logs. To disable scrips, edit the scrip and set the Stage to disabled. These built-in scrips are global, so if you want to set them per-queue, you can create scrips under the queue configuration to make them queue-specific.
The best examples of actions and conditions are the RT code itself. You can find documentation at the bottom of the main documentation page. From there, you can look in the lib directory in the RT code to see how the actions and conditions are implemented. It's generally easier to get started creating actions and conditions by selecting User defined and using the text boxes on the scrip edit page.
You can set devel mode in the configuration file. Make use you set these in RT_SiteConfig.pm, not Config.pm. You'll also want to set you log levels to debug.
Related
I am using the scriptrunner plugin for Jira.
Is it possible to add a condition to a transition using scriptrunner?
Currently, my condition is in a script which I have manually added to the workflow.
But I was wondering if there is a way to do it automatically?
I was looking through documentation on: https://docs.atlassian.com/
I came across this method:
replaceConditionInTransition which is a method of WorkFlowManager.
But I'm unsure on how to use this.
Any help would be appreciated.
Conditions as any another scripts can be added from file system. You can store scripts in any VCS (bitbucket, github, gitlab, etc) and automatically deploy them to Jira server file system through any CI/CD system (teamcity, jenkins, bamboo, gitlab, etc).
So, as result process will be looks like. 1. commit changes in you script to vcs 2. wait a bit for auto deploy (e.g. triggered by commit) 3. done. As additional you can write any script/service/etc for commit these changes automatically if needed.
Also look at script roots it's helpful way which allows reuse any of script fragments through helpers classes.
It's rather conceptual answer basically because implementation is depends on environment, but I hope that you get at least one more point of view to solve this task.
I think that using the Java API to modify Jira workflows is pretty tough. You could dig around in the workflow editor to see how conditions are added there. Remember that you have to do this in a draft workflow and then publish it, which takes some time in large projects
I like the idea of replacing a script file as easier, if it can be done when no issues are transitioning
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
I am using Folder plugin and AD groups to control access to folder. This morning a team can't access their project anymore and later I found the AD group assignment in Assign Roles has been changed to wrong groups. Is there a way to find out which id did it? We only have a few admin ids.
Jenkins does not appear to keep an audit trail by default, as stated in this post on cloudbees.com, the folks that develop Jenkins.
The relevant lines:
Many Jenkins users look for a recommend a strategy for keeping an audit trail. This article is supposed to be a gap filler until more comprehensive compliance capabilities in JE/JOC are developed.
There are two open source plugins that enable you to track “WHO did WHAT?” in Jenkins:
...
The first plugin listed is Audit Trail Plugin which looks to provide exactly what you are seeking.
The description from the plugins page:
Keep a log of who performed particular Jenkins operations, such as configuring jobs.
This plugin adds an Audit Trail section in the main Jenkins configuration page. Here you can configure log location and settings (file size and number of rotating log files), and a URI pattern for requests to be logged. The default options select most actions with significant effect such as creating/configuring/deleting jobs and views or delete/save-forever/start a build. The log is written to disk as configured and recent entries can also be viewed in the Manage / System Log section.
I spent a few minutes looking through Jenkins various xml and log files, but could not find a log that contained something useful (username and/or timestamp). In this case it seems user auditing isn't built into Jenkins as of yet. Unfortunately it appears that you might not be able to determine who made those changes after the fact.
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.
I am new to iOS development. We are using SVN for code repository.
I wanted to know whether there is a way to set some rules on code check in? i.e. suppose we have a code guideline and we want everyone in the team to adher to it religiously. We can set some rules via which automatically it can be found out whether the person has followed the guidelines or not.
Something like TFS check in policies?
You can use on server side the so called "hooks".
Most important is the pre-commit-hook
You can found them on the server inside the repository in the directory hooks
You can place any executable there and it will be called during commit. There is a svncommand called svnlook which you can use to look directly into the transaction to be committed.
In each repository there is one example for each hook SVN provides. These templates showing a sample implementation with some meanigful bash script.
more infos about hooks