I created a document to represent what I see with my config file to show differences. Some of the items may not be resolved, but anything you can do to help would be greatly appreciated.
Not picking up all the user stories but have selected to get all
Missing links
Missing Epics (doing some research, it seems that the Epic Was migrated unparented; it is probably related to the issue with missing links, which is happening for almost all items
Bugs have different fields (Description and Acceptance Criteria not migrated or not showing up)
Description merging with Acceptance Criteria
Attachments not coming and tried everything to have them come over even if when they are way under the limit
History of comments not migrated
Status not migrated
Tests not associated with User Stories
Some test cases were not migrated
Load Tests were not migrated
Test Runs not migrated
Migrated from: https://github.com/nkdAgility/azure-devops-migration-tools/issues/632
Yes, start with a fresh copy and see what falls out.
You can remove the old ones using:
{
"ObjectType": "WorkItemDeleteConfig",
"Enabled": false,
"QueryBit": "AND [System.WorkItemType] NOT IN ('Test Suite', 'Test Plan')",
"OrderBit": "[System.ChangedDate] desc"
},
Missing Epics (doing some research, it seems that the Epic Was migrated unparented; it is probably related to the issue with missing links, which is happening for almost all items
There was a bug with links that have now been resolved, but it seems that you need to migrate those items again.
Bugs have different fields (Description and Acceptance Criteria not migrated or not showing up)
If you have different fields on the source and target then you need to add a custom set of field maps.
Description merging with Acceptance Criteria
Do you have a field map that merges them?
{
"ObjectType": "FieldMergeMapConfig",
"WorkItemTypeName": "*",
"sourceField1": "System.Description",
"sourceField2": "Microsoft.VSTS.Common.AcceptanceCriteria",
"targetField": "System.Description",
"formatExpression": "{0} <br/><br/><h3>Acceptance Criteria</h3>{1}",
"doneMatch": "##DONE##"
},
This is the example field map that is added to the template config.
Attachments not coming and tried everything to have them come over even if when they are way under the limit
History of comments not migrated
Status not migrated
Tests not associated with User Stories
This is likely related to the previous issue and clearing the items should resolve it.
Some test cases were not migrated
Only things within scope for the WIQLQueryBit are migrated. I would check the scope and see if they are excluded. Test Cases are just Work Items.
Load Tests were not migrated
There is no way to migrate load tests, you will have to do these manually.
Test Runs not migrated
There is no way to migrate Test Runs.
Related
I'm building a REST API powered SPA application and I'm trying to decide on the best way to deliver "global options" via the API. By global options I mean an assortment of random fields that relate to the application as a whole rather than being associated with one specific model, for example brand logos and contact details that need to be accessible from multiple locations within the app.
Something like Wordpress would store these in an options table and access them via a php function using the option name, however since this is a REST API I'm not sure how I would go about accessing/updating multiple options without making lots of requests for each one.
I know a lot of projects just use a json file to store this data, but it specifcally needs to be editable via a CMS and served via the API. The following are two methods that have come to mind, but none of them feel like complete solutions:
1: An options table with one generic endpoint that takes a query string specifying which fields you want to access. This works for getting data, however updating data seems to get a bit messy and the only way I can think to do this is by sending an object of key/values pairs to bulk create or update the options:
GET: example.com/api/options?pick=logo,contact_phone,contact_email
POST: example.com/api/options
{
contact_email: "info#example.com",
contact_address: "123 Test St"
}
PUT: example.com/api/options
{
contact_email: "info#example.com",
contact_address: "123 Test St"
}
2: Breaking fields into groups and storing them as a json field in a "pages" table, this solves the creating and updating issues but breaks down when you have fields are used in multiple locations, and they aren't really pages so it's not very REST like.
GET: example.com/api/pages/contact
POST: example.com/api/pages
{
name: "contact",
values: {
email: "info#example.com",
address: "123 Test St",
}
}
PUT: example.com/api/pages/contact
{
values: {
email: "info#example.com",
address: "123 Test St",
}
}
I also need to take into account the issue of access permissions, for example the logo field would be accessible to the public, but the user support contact number would only be accessible to logged in users. With the first example you could have an extra permission column for each option, but this wouldn't work for the second option.
I've been googling but have failed to find any good information about this topic as REST schemas/documention generally only deal with concreate entities, so any insight into how this is achieved in real world applciations would be great!
Cheers,
Cam
I'm finding conflicting information on creating one time use deep links.
expire desktop_url generated through branch SDK after one time use
The documentation on "type" says "Must be an int. Set to 1 to limit deep link to a single use. Set to 2 to make the link show up under Quick Links while adding $marketing_title to data. Does not work with the Native SDKs." (https://docs.branch.io/links/integrate/)
I created a link using the included JSON with a POST to https://api2.branch.io/v1/url.
{
"branch_key": "*********************",
"data": {
"entityId": "282fd3da-5200-45f4-80a2-4f3a1c36bff6",
"$link_exp_date": 1567271700000
},
"type": 1,
"feature": "test_feature",
"tags": []
}
I expected the URL to be available for one time use. However I am able to successfully use the link multiple times until it expires. And retrieving the link using GET https://api.branch.io/v1/url doesn't return any properties that indicate the link was used.
Even before creating a deep link and testing, you need to integrate the Branch SDK in your respective app (Android, iOS etc).
The simple way to create a deep link is via dashboard and test this when the app is installed.
I'm creating a script that goes into all tests into a test execution. I'd like to get the amount of defects for that particular test execution. Is that a way to get it using rest api?
Xray enables exporting Cucumber tests to be exported as .feature file that further can be used in your automated tests. To do so use this export endpoint
To import the automated test results back to Jira used this import endpoint
Usually APIs will be executed in conjunction with CI/CD tools, like Jenkins.
In this article you can see that the total number of defects can be view via the Jira UI.
And finally, this video shows how tests are imported and exported via the UI.
Tests can be created via API as well, see here.
I think it all depends on your testplans. When those contain all tests you should be able to execute the test via the endpoint rest/raven/1.0/api/testexec/<testExecution>.
Maybe it will be good to ask the very same question in the atlassian community.
Sorry for not being able to fully answer your question, but I think you now should have some things to read :)
There is one way that is more straightforward.
You can make use of the "Test Execution Defects" custom field, which is a calculated field.
Then you just need to use Jira's REST API and obtain information for the related Test Execution issue, for that specific custom field that returns an array. The number of elements corresponds to the number of defects.
Example of HTTP GET request:
https://sandbox.xpand-it.com/rest/api/2/issue/BOOK-31?fields=customfield_11802
Example of response:
{
"expand": "renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations",
"id": "20130",
"self": "https://sandbox.xpand-it.com/rest/api/2/issue/20130",
"key": "BOOK-31",
"fields": {
"customfield_11802": [
"20131"
]
}
}
Another way would be to use the JQL function "defectsCreatedDuringTestExecution ()", as mentioned here: https://docs.getxray.app/display/XRAY/Enhanced+querying+with+JQL
Then you could do a Jira REST API search call.
Example of HTTP GET search request using the JQL function:
https://sandbox.xpand-it.com/rest/api/2/search?jql=issue%20in%20defectsCreatedDuringTestExecution(BOOK-31)
I have a handful of WordPress websites that use The Events Calendar for displaying events that are open to the public.
I notice if I type a cities name and then the word event, that our website is not being pulled in to the special section that appear. Google uses its Knowledge Graph. I was looking through the source code and noticed that our sites uses JSON-LD, generated from the information used for the event, one of the methods Google talks about using, but don’t understand why our site information isn’t being shown.
These sites have been up a year and get 3k visits a month so they're being indexed fairly regularly.
I was looking through the event properties JSON-LD, and I noticed the entire event address (street, city, state zip) gets put inside the name property of the Place or Postal array (Heres a screenshot of my sites schema). When I look up other events that are pulled into Google, they list the those attributes in the address properties (Screenshot of other site’s schema).
I think because the address is put into the name property instead of the address property, that Google might not be showing the events. Has anybody else seen this happen with their sites? Or is something else wrong with the sites we set up?
Right now your events are marked up using the Google example, but I believe this is wrong:
https://developers.google.com/structured-data/rich-snippets/events
"location" : {
"#type" : "Place",
"sameAs" : "http://www.hi-dive.com",
"name" : "The Hi-Dive",
"address" : "7 S. Broadway, Denver, CO 80209"
}
2019 edit: The markup and URL above have since changed and match what is expected from the testing tool.
In order for your sites structured data to match that other event you have a screen shot of, you will need to adjust your JSON-LD to the way it's presented on schema.org, which uses PostalAddress and narrows down a little bit more:
https://schema.org/location (and https://schema.org/PostalAddress) - Click the JSON-LD example tabs
"location": {
"#type": "Place",
"name": "Withworth Institute",
"address": {
"#type": "PostalAddress",
"addressLocality": "Seattle",
"addressRegion": "WA",
"postalCode": "98052",
"streetAddress": "20341 Whitworth Institute 405 N. Whitworth"
},
"url": "wells-fargo-center.html"
}
I can't say for certain if this is the primary reason for your issue but I do think you should follow the schema.org approach either way. Even the Structured Data Tool per your screenshots seems to indicate that it's looking for postalAddress even though Google doesn't use that in the example.. perhaps that article is outdated.
I can confirm that a migration to JSON-LD from inline RDFa style schema, which validates 100% using their new rich snippet validator tool no longer shows Review stars in search results. They've also taken away the ability to see stars validate using old style RDFa schema validation.
This could be an issue with the search team not talking to the developers responsible for the structured data and schema tools, rolling out disjointed feature upgrades. Their recommended use of JSON-LD will likely have a negative impact on display in search in the near term if you'd like to see additional meta data populate in search results pages.
If meta data in search results is a firm requirement you could roll off your JSON-LD module and use a module with the older RDFa or microdata implementation inline in your HTML. Hopefully this will be remedied soon.
Let's say I have a plugin Foo in osclass. In that plugin we register a hook for when an item is posted. According to the osclass hooks documentation the only hook that is run when an item is posted is posted_item.
But as far as I can tell from looking at the code this is run after the initial item data has already been validated and stored in the database. What if a validation of some plugin specific code fails and I would like to show the user an error message and present him with the form again to give him/her the chance to alter this information? Much like if you try to submit a new item but don't fill in one of the base information like description for instance.
I can't seem to find a way to do this. Only workaround I find to avoid the item being posted despite containing invalid plugin specific data, without editing the main osclass code, is to delete the posted item again in the posted_item hook callback function of my plugin. This feels extremely cumbersome and also requires every other plugin to check that the item still exists to make sure they don't save data connected to an item that is now deleted.
What I would like, and wonder if I have missed, is a hook that is run when an item is posted but before it's written to the database and have the ability to generate "errors" that would cause the item to not be posted and the user redirected back to the form with the "error" displayed just like for the basic item information.
Anyone have a solution I have missed? This feels like a very important part of plugins and without it posted items could become very fragmented.
A user on the osclass forums (teseo) told me about the undocumented hook pre_item_add that can be used.
<?php
function cust_my_plugin($aItem) {
osc_add_flash_error_message('My plugin has a complaint.');
$pItem = new CWebItem();
$pItem->redirectTo( osc_item_post_url() );
}
osc_add_hook('pre_item_add', 'cust_my_plugin');
?>
He also sais
The only bad news is that you can't merge your plugin validation
process with that of the core script, so if the ad had an error
related to your plugin and other errors, it would be rejected twice,
one by your plugin, the second by the core script. I couldn't see any
workaround for this little issue.