I'm trying to write a Jira script that would copy an issue from one project into another, while also using the same CustomField value. The problem is, that the customField values and options are project-specific, so it isn't a trivial task of setting the new issue's customField to the same value.
I can get an issue by it's key and I can get it's customField value, but I can find no way of finding every possible value for a customField of an issue for a given project. I've tried adapting this script: https://library.adaptavist.com/entity/update-single-select-custom-field
,but the availableOptions will always remain empty.
Related
Is there a field that exposes WHEN a work item is assigned to its current iteration?
Seems like a pretty basic thing one might like to know, but I can't seem to find it anywhere. Can someone point me in the right direction?
There is No field that exposes when a work item is assigned to its iteration.
If you want to see this value, you can go to the page of the work item.
And then click "History". What you need to find is the record of the latest iteration update.
Of course, you can also get this value through the REST API:
GET https://dev.azure.com/{organization}/{project}/_apis/wit/workItems/{id}/updates
But just like getting it by website, you need to spend some time looking for this value, and you can't apply it to queries.
If you really need a field that exposes when a work item is assigned to its iteration. You can create a new process that inherits from your current process and change the process of your project. Click this document for detailed steps.
And then, add a new field to show the latest updates of iteration. Click this document for detailed steps.
This way you can treat the iteration change time as a real field. However, the defect is that when you make changes to an iteration, you need to manually change the value of this field.
In Work order tracking application in actuals tab materials section when user clicks on New row by default the transaction type = ISSUE . I would like to change this by default to RETURN and remove issue from the look up (I was able to remove ISSUE from the lookup). This requirement should only work for PM type work orders. Hence I tried to write an automation script on MATUSETRANS.ISSUETYPE attribute launch point however it throws null pointer expection which trying to perform setValue. I tried using 2L,7L and 11L however it doesn't work.
if(onadd) ==True:
mbo.setValue("ISSUETYPE",'RETURN')
Is there any other way to do this?
We basically need to trigger the code on a field that sets after ISSUETYPE is set using the out of the box code so I tried on field like currencycode or condrate (attribute launch point) and it works like charm. You will have to use 7L though to the existing code.
Where does the code that makes a PX Formula work exist? I at first assumed it was a SQL Trigger, but I can't seem to find it there. This is why I ask....
I've added a custom field to the SO, called usrSpeedyTotalExt2. I'm trying to get that to sum the SOLine.CuryLineAmt. I added attributes to the SOLine DAC to append the follwing:
[PXFormula(null, typeof(SumCalc<SOOrderExt.usrSpeedyTotalExt2>))]
This seemed to work, but know I'm fining that the value is consistently twice as high as it should be. I've got a second field that's doing the exact same thing.
What's increasingly odd is that I had the same problem with the field, and I thought I had done something wrong so I deleted the PXFormula, created a new field and then added the PX Formula to populate the new field. As such, there shouldn't be any code populating the old field, but strangely it's populated, so there must b e some business logic that's stuck and somehow still populating it.
Any thoughts on how I track this down?
I believe that I figured out the problem...I think that the code may have been imported and published on more than one company, then published from the proper company to multiple tenants.
My fix was to go to the live company, un-publish all, then go back to the company the customizations live in and publish to the appropriate tenants. It would appear that now I'm only getting the proper totals. IDK how that might have happened, but at least it appears to be fixed.
I'm working with soapUI and groovy to do a test whether a particular value regenerates again?
I'll have a soapUI request with JSON which gives a id in the response, i should extract tat id and store it in a dynamic location so that the when i run the test case again, i should be able to compare the prev id. if it both matches then the test case should fail, if not then the new value should be added and the when the test case runs now, it should compare the prev two values.
This goes on for a min of 10000 runs. so 10000th id should compare with all the 9999th id to check for repetition. If it exists, it should fail else the test should pass.
Please help me.. Thanks in advance!
March, 2013...wow..sorry for the late answer and hopefully you were able to find an answer to this question.
I do not have access to soapUI right so i cannot offer code for this answer but off the top of my head i would say..instead of saving the value in the dynamic location store it in a test suite, test case or project level property and each time you want to compare..just read that value and compare.
I understand you are going to have to store 10000 times so instead of creating so many properties, store the values in a list or map and store that map in the properties. Every time you need to check the value, you access that property, find what you are looking for an compare.
I'll have access to soapUI tomorrow so i'll try to write some code for you.
I have a SPD workflow that is set to run when an item changes but it keeps getting triggered on new items, which is pretty annoying. I'm looking into why this is happening but I'm also looking for a way to terminate the workflow if the item is new as a temporary workaround.
I tried to compare the Created field to the Modified field i.e. if Created and Modified are the same then don't run. This didn't work, either as a date or string comparison.
Any suggestions would be much appreciated.
Store a flag in a hidden field the first time the workflow is run. Check if the flag is present, if not then it is the first time (created), otherwise it is updated.
I have faced this same issue and I solved with the workaround like this
Take created date and add 1 minute with it and assign it to a variable
Check this variable less than current time.
It done with the following assumption
a. No one try t edit the item within one minute, it created
b. Workflow will execute within one minete
In my case it was success
The comparison between the created time and modified time works on SharePoint 2010 (it is used here). Perhaps the comparison is done incorrectly or the wrong object is used to get the data from?
If said approach does not work on 2007, perhaps it may be possible to use the owshiddenversion field (directly access as property if not correctly exposed). It should be 1 for a newly created item, and > 1 otherwise. It may only be available on versioned lists, I do not recall.
Try adding a condition which compares the create date with the modified date.
i.e.: if current item:created not equals current item:modified