Currently I am working on a Jira project and in that project I have built a workflow. The workflow runs with a single issue and runs successfully.
This workflow mainly consists of 2 parts. In the 1st part, the authorizations are set and approved. In the 2nd part some assignments are being conducted according to the authorizations that have been set in the first part.
This workflow works well but I have been asked to implement this project with 2 different workflows which will be run by 2 different issues.
So my question is, how can I migrate data from the first issue to the second issue? Somehow I need to transfer the authorization info to the second issue so that the second workflow will be able to run.
Thanks a lot.
Once the authorization is complete you could change the issue type to a type which uses the second workflow. If you want to retain the authorization record, you could clone the first issue and then change the issue type of the clone.
A late respond: I achieved this by using the sub-task mechanism. I also used post-functions in the workflow which made me able to get the authorization data from the first issue.
Related
[Disclaimer: I'm not sure if this kind of question is accepted here as it is about a piece of software deployed already. Rest assured I didn't drop any confidential information. Also do tell me if I violated any rules in SO by posting this so I can take it down immediately]
I have a working Learning Management System web application and I recently received a bug report about a button not showing. After investigating, I have proved that the user was not using the web app as intended. When taking an exam, he was opening multiple tabs to exploit the feature that informs him whether the answer was correct or not. He then will use this information to eliminate the wrong answers and submit all the right answers in another tab/window.
I'm using Rails 4.2. Is there a way to prevent multi-tab browsing? I'm thinking like if a user is signed in and he attempted to open a new tab of the webapp, he should see something like "Please use one tab" and all the features/hyperlinks/buttons are disabled.
Here's a screenshot of how I proved he was using multiple tabs. Notice that there are multiple logs of the same attempt # because the current implementation allows saving a study session and resuming later (this is the part that's exploited). The opening of multiple tabs searches for the most recent attempt session and continues from there. This is also the reason why most of the sessions don't have a duration value -- the user only finishes a study session for one tab (by clicking a button that ends the study session). The system cannot compute for the duration because the other sessions don't have an end timestamp.
-
This is what a single-tab user looks like:
This is more of an application misuse issue more than a bug.
You should add protection not only from multi tab, but for multi browsers aw well, so it can't be purely FrontEnd check.
One of the solutions could be using ActionCable to check if a user has an active connection already and then act accordingly.
Another, for example, generate a GUID in JS and pass it with every answer. If its different from previous answer, it means user opened a new window.
But of course the solution would depend on your current architecture, without knowing how do you currently organise client-server communication it's hard to give exact and optimal solution.
I found an answer here. I just placed this js in the application view to prevent any extra instance of the website.
Thanks for everyone who pitched in.
I have a web application with Rails 4 where you have to log in to use it. Now I want a demo version of this app. By demo version I mean a version that has all the features of the original app but without the login. And all the demo data should (and can easyliy) be deleted from time to time (either automatically or manually).
With the original app up and running I want to implement the demo version with the least effort. Ideally I can use most of the original code without any changes. But changes to the original code on the other hand will be available in the demo version without any extra work.
My first idea was to implement the demo version just in the cache/session so if the session is expired, the data is deleteded as well. I canceled that idea due to the deep integration of ActiveRecord in the original app. I would have to re-code all the demo classes and/or build some abstract parent classes and so on.
The second idea was to simply use the original app but to add a flag to each demo account so that they can be distiguished from all the regular ones. I hesitate with this idea because I'm afraid to blow up my database (i.e. the tables that I use for the original app) with demo data leading to lower performance and higher cost/risk of wrong interpretations when evaluating the app data (e.g. how many accounts where created yesterday).
Do you have any ideas how to realize such a demo version in an elegant way?
Smart approaches welcome!
You can have a Guest user account, and a before action in ApplicationController that checks if the current application is in demo mode (specifiable through a custom config) and automatically logs in the user.
You can use a cron job to delete the demo data. Whenever is a good solution for managing cron jobs in ruby.
for automated fake data creating use whenever and faker gems. Faker will generate fake data. Whenever for cron job. And after every demo session it will clear the mock data.
take these point : session, cron, fake seed data
I moved by mistake a issue from not started to DONE. Is there a way to move back the issue?
I would rather let it "in progress".
The answer is yes, but you may have to customize your workflow to add a transition from the DONE status to another status. Make sure to clear the resolution using a post function so that your issue key is not marked with a strike through
Yes! Or no, or maybe :)
It depends on your issue type's workflow, but you can usually re-open the issue and set it to in-progress.
This, of course, may also be dependent on
What version of JIRA you're using
If you're using GreenHopper/JIRA Agile
If you have a custom issue workflow/lifecycle
What your user permissions are.
Any additional details about your JIRA instance might be helpful! Is it a hosted ( ala Atlassian on-demand ) or on-prem, etc.
I have a custom field called "Detailed Status" in the issue page. After an issue is verified by testers, they will change the value of this field to "Ready for Deployment". After we deploy the latest code to the server, this should be changed to "Verified after Deployment".
At the moment, after every deployment there will be at least 10-15 issues which will require a developer to manually go to each issue and change the value of the custom field to "Verified After Deployment"
Is there a way I could automate this?
I went through the documentation - I found out the option to do a Bulk Edit but my project architect wouldn't hear of any manual intervention at all.
Event listeners wouldn't serve the purpose would they, since deployment is not a Jira event but an external process. Could this be done using a script ? By directly doing an update on the JIRA tables or so ?
Sorry for sounding very vague and ignorant, since I am quite new to JIRA customization. Any pointers would be appreciated. Thanks.
There is a REST API that can be used by a script to update the custom field in the issues.
Start with http://jira-python.readthedocs.org/en/latest/
or
https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Example+-+Edit+issues#JIRARESTAPIExample-Editissues-Examplesofupdatinganissueusingfields.
Sounds like your QA takes action during the Dev process (on Dev/Test/Stage environment(s)) to verify the issue has been resolved, and again after the deployment to a Production environment. If this is true, you could modify your workflow to allow for status & transitions to automatically set the field via a Post Function.
If QA hits 'Pass', it sends the issue forward in the workflow where that action updates the field "Detailed Status", and if they hit 'Fail/Reopen' it sends it back to Dev along with the corresponding status you want on that custom field. This would meet the mandate of no manual intervention.
There are several free plugins that can accomplish this, and streamline your workflow so that it mirrors your development practices.
I've been looking for a way to have a user acknowledge a
ticket after it has been assigned to them. I don't know if
this is a built in feature or if there is a plugin that
will create a state/button for a user to accept a ticket
after it has been put in there queue. I would expect to
see something like this from the ticket window around
workflow or start progress but no amounts of digging
through configuration settings has turned anything
relevant up.
Does anyone know about this added functionality in JIRA?
Much thanks.
I did this by a custom workflow step. After an issue arrived to an assignee (with status New) he/she should move it to another step (with status Open). Until he/she does it, the issue is considered as not noticed/reached the assignee. Also I have had a report showing issues with New status for more than a predefined period of time.
I'm not aware of a ready-made plugin which performs similar task (perhaps, I should dig into my posts on Atlassian answers to discover some clues for other solutions).
As #Stan says above, a custom workflow is the way to implement this. The workflow functionality in JIRA is very flexible and as a result has a bit of a learning curve, but Atlassian's documentation is pretty good. Post back here if you need help.