We are current using a work item called "fix" to bugs that are discovered before production, and using test plans. The work item "bug" is used only for bugs that are found already inproduction. Is it possible to manage the Azure test plans to change the "bug" creation to a "fix" creation (already as a child of the originary US would be great).
The point is related in the help article: https://learn.microsoft.com/en-us/azure/devops/test/run-manual-tests?view=azure-devops#create-or-add-to-a-bug
I was not able to find more information.
Thank you very much in advance!
I was expecting to be able to change the item, but I couldn't.
Related
We run a classic JavaScript app on multiple tenants on SharePoint online. The app uses the Microsoft.SharePoint.Client.Search.Query.KeywordQuery to search for documents within the site collection where the app is installed. On one of the systems we get the error:
Microsoft.Office.Server.Search.SubstrateSearch.SubstrateSearchException:
Remote executors failed, local failback not allowed.
Despite the specific words in the error message, I was not able to find any documentation about its meaning. When I copy the search string used in the SP search field the search works. Any clues what could be the cause?
Any developments on this? We just started seeing this same error in one dev environment but not another, despite running the same code.
I have the exact same problem, but if I include "-contentclass:STS_ListItem_DocumentLibrary" in the keyword query it works, but since i need items from document libraries this wont help me.
We have only seen this issue one one environment, I am not sure how to fix it. It looks like it is having issues with document libraries specifically, unless i include a some text it also should search for (besides the keywords). If i didn't know any better i would almost say it was some kind of overflow, but that just seems far fetched, and we do have limits on the query anyway.
Update:
Subsequently if I wrote a keyword for a specific library like ListId:73C91192-89CD-4C06-A322-388CEAE456ED instead, it also works
we just recently started to see this same issue.
In our case we were using a Classic SharePoint Online site, with the search web parts on it. The search results web part had a number of different Hit-highlighted managed properties that it was trying to bring back. One of these properties was "Topic". I checked the search schema and for some reason, this managed property had disappeared. Removing this property from the search results web part fixed the page and search results web part.
No one had touched our search schema in a long time so this property had simply disappeared. Definitely seems like search schema updates are causing issues.
Hit-highlighted properties
Does anybody have some usefull information or pointers on this issue? We just came across this issue on one tenant for one specific user. We have a multi-tenant app that executes a search query looking for document libraries with 3 conditions:
We do use the ContentClass:STS_List_DocumentLibrary condition as we are looking for document libraries
External content specifier: "-isexternalcontent:1"
Generic search term: just a single word
As mentioned we get this error on one tenant when one specific user executes it. I can't reproduce it with other user accounts. Since we are providing a multi-tenant SaaS we are afraid this will start popping up for our customers..
We have a solution deployed in a tenant which consists of flows and powerapps application. The flow in the solution has a trigger point of whenever an item is added or modified in SharePoint list. That flow is not getting triggered even when an item is added to the list or modified. But if we make a copy of the flow outside the solution it is working. Have you guys faced any issue like this?
Did you try deleting the trigger and re-adding it. If not please try that
We have an existing issue with the Audit Setting on individual entities. When a managed solution is deployed from Dev environment to another, the 'Enable Audit' setting is turned off after the deployment (while the imported CRM soultion has the Enable Audit turned on for the corresponding entity). This only happens for a few entities.
Does anyone have any idea why this might occur ? and is there a way to fix this ? Please assist.
Thanks
Rajesh
This is one of the managed solution "gotchas" in crm 2011. Importing a managed solution that contains those entities will effectively turn off Auditing.
For verification, more info take a look here: http://blog.sonomapartners.com/2011/09/some-assembly-required-unmanaged-solution-gotchas.html
Quote: "What we found is that the Enable Auditing in the following areas checkboxes are transferred from one environment to another, without needing to select any of the system settings for export. However, the Start Auditing is not. When documenting the steps to perform a deployment, make sure that manually checking this important box if you are performing auditing on any of your entities is one of those steps."
So you will have to make sure start auditing is enabled on these entities manually. I assume you would be able to automate "start auditing" using a C# Console App as well if automation is an important part of your deployment process.
So, to clarify, when exporting the managed solution, it seems like the following line is transferred:
Here's a work around for this problem that I found here:
Simply open up the managed solution zip and edit the setting for IsAuditEnabled to read 1. After that zip up the solution again and import at will.
A bit of manual work but it should work. Also, make sure going forward you remember to do this. If Auditing is turned off you will lose all Audit Data for the entity...
I've been playing around with the new "Websites" feature of Azure (which I believe is still in beta), but I've run into a problem. I've got two subscriptions associated with my account - one for personal use, the other for my company. And of course, I'd like to be able to specify which subscription is used when I create a new website. But when I try to create a website, it always picks my second subscription, and never gives me a chance to specify which one I'd like to use. Nor can I figure out how to move the website to a different subscription after I've created it.
I've walked through this several times now, and I can't spot any place where I can specify which subscription to use. Is this just a beta glitch? Or have I missed something?
I ran into the same thing, called MS support. Switch back to the standard portal to make this change.
To get to the old portal hover over the green "preview" button at the top. This doesn't seem to work in Chrome for me, just IE.
Do take a look at my response on MSDN Forums for a similar question there: http://social.msdn.microsoft.com/Forums/en-US/windowsazurepurchasing/thread/d9624b03-1d6c-484a-9fa8-8548c35a9d4f/. Basically you would need to activate this feature for each subscription separately since it is in preview mode.
The SharePoint install is a SP2010 install on a 2008 R2 server. Everything is fully patched. I am running the SP Designer on the SharePoint Server directly.
I have a workflow which is intended to send an email when a new document is created in a custom list. I have deliberately kept the workflow very simple in order to illustrate this problem.
After creating this single step workflow in SP Designer, I click "Check for Errors" and SP Designer reports "The workflow contains no errors".
I then click "Publish" but the Workflow Error dialog is displayed with the message
Errors were found when compiling the workflow. The workflow files
were saved but cannot be run.
Clicking the advanced button reveals more information:
Could not publish the workflow because the workflow configuration file
contains errors
Any suggestions gratefully received
I'll share what fixed it for me - deactivating all workflow features at the site collection level (that is, Workflows, Three-state workflow, Publishing Approval Workflow) and then reactivating the features. I was then able to publish my workflow. This post helped, not sure whether this only works for 365 though, but it's sure worth trying first if you are considering a reinstall.
after googling for quite some time, i think it's an authentication issue. How is your SharePoint set up? Do you use HTTPS for authentication? If so check out this article.
I know this error message from sharepoint. I got this by dealing with multiple lookup fields refering to other lists. Even when I check the worfklow for errors SharePoint says that its all fine but i can't publish it at all.
Try to build a new Test-Site on your Site Collection. Build a Custom Document Library, leave it standard and then set up a new simple workflow just sending a mail.
Fill out the needed fields in mail only using simple values. Send to your mailadress, simple mail subject and simple mail body.
Set the workflow to run only manually.
Try to publish the workflow.
When this is working, then compair to your existing workflow and change your values by trail and error.
After doing a clean install of the OS and SharePoint, workflows are working flawlessly. I can only conclude that the problems were caused by left over registry settings from MOSS 2007. Thanks for the suggestions that people made.
This could also happens if you chage the URL of the web application, all you have do is click the Design button from the library itself.
when changinf the URL from http://server/Site to example: http://server.xx1.net/site, and you try to publish it tries the old url.
what helped in my situation is changing from start workflow automatically to manually.some times answers for critical situation is very easy. hope it helps, many thanks
I ran into this problem and after digging for days and folks suggesting to rebuild the servers, disabling and re-enabling site features, remove previous workflow versions, etc. and trying everything except rebuilding the servers (not practical for clients production environment). I decided to try some tests and found that this issue was only happening on one particular list no matter how simple or complex the workflow was... And when I would check the box for start automatically on item create (or when item changed) it would fail to publish and give the error above, but if I published it with just manually start worked fine. Finally after deleting views and some more testing, I discovered that there was over 240+ columns in this list (I did not create it...) and 50+ workflows set to run on create... Thankfully I have a test environment I built out for the client so I sync'd the Site Collection database back to test environment from Production re-ran my tests and got same error... So what resolved the problem and what was the ultimate cause of the problem, there was to many columns defined in the list and I had to delete several columns to publish the workflow in the test environment. This actually issue translates into the there is a limit in SQL Server on how much data the list can store each type of column takes up so much space read more about it here:
https://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#Column
So what I did in production was worked with my client to determine how to break up the list into multiple lists and have relationships between them, thus moving some of the columns and data to another list (Think database/list normalization)... I hope this solution helps someone.