The plugin step's message is Assign, postoperation (or preoperation, or prevalidation, the problem is still the same). When I debug the plugin in Visual Studio, the field "ownerid" of the preImage does not contain the Id of the old user, but the newly assigned one.
leadPreImage.GetAttributeValue<EntityReference>("ownerid").Id
What can be the cause of this problem?
AssignRequest is currently deprecated and is likely to be removed in a future release. Consider changing your plugin step to Update Message and add Owner(ownerid if looking in schema names column) as a filtering attribute for a better performance.
I believe this will remove your issue.
Related
I'm encountering a strange problem. I have a workflow which triggers when an entity is created. It has the following steps.
Step 1: Update the lookup field to link to a record in the Autonumber entity.
Step 2: Set the record number field to the value of the Counter field in the Autonumber entity.
Step 3: Increment the counter field in the Autonumber entity with the value of the Increment By field in the same entity.
I use such workflows as a means of getting an Autonumber. This worked fine until I decided to import my unmanaged solution to another organisation. In this new organisation this workflow throws the following error on Step 1.
Sync workflow 'SP Electrical Autonumber' terminated with error 'systemuser With Id = 1901130da-..... Does Not Exist'
This is odd as I'm creating the entity so the workflow is set to run as the The user who made changes to the record and I've got the System Administrator profile. Further my GUID is different to the above guid and my guid exists in the database. So I'm struggling to understand where its getting this guid from.
I've checked the Autonumber record in the first step using (Select * from Filteredcal_autonumber) and couldnt find the guid in the error message anywhere there too!
So where is it getting this guid and why is it that just this workflow is throwing this error. Other entities use similar workflows for their autonumbers and they seem to work fine. Any ideas? Or places to look would be much appreciated. I've investigated this myself a lot and only posting here as a last resort as I'm really out of ideas.
I have even deleted the entire workflow and recreated it again to see if this solves the issue. But it didnt and I'm still getting this error.
I've identified the guid to belong to the installer account from the previous organisation that I had imported the solution from. Not sure why the process is looking for this guid in the new organisation. Anyone?
Ok so glad I got to the bottom of this. This is another CRM gotcha!!!
The issue wasnt with the workflow at all. Inspite of deactivating the workflow I was still getting the error. On discussing with a work colleague we concluded that one possibility where a GUID from an older organisation might have been inserted was Visual Studio. The old organisation used custom plugins and they were held in Visual Studio. When I imported the solution to a new organisation, I continued to use Visual Studio to make changes to these plugins. I continued to deploy them to the new organisation. This made Visual Studio transfer the old guids to the new organisation.
What I should have done is, in VS when you connect to a new organisation, you need to open the RegisterFile.crmregister file that you will find in the Deploy project and set any Id='[guid here]' to Id='000000-0000-0000-0000-000000000000' so that when you deploy new fresh GUIDs from the new organisation are created and stored.
To fix my problem, I unregistered the plugins, then reset the IDs in the file as above and then redeployed the plugins! Voila! Everything works now!
We have a SonarQube 6.0 server with enabled SCM plug-in. So the REST webservice returns the author for each new issue.
While this is an important information, the person who fixed the issue is also important to me. The assignee seems to be that person, however the issues are auto-assigned to whoever created them and their assignee doesn't get changed when somebody else commits a fix. (And yes, the author should fix the issues, but often they don't.)
Things I tried:
Rerun Sonar on a project that was not changed since the SCM plug-in was introduced: the author was filled with the committer, and the assignee was only filled if there is currently a Sonar user with the same name
introduced a new issue - both the assignee and the committer where set to the committer
fixed an issue with an assignee: nothing changed
fixed an issue without an assignee: nothing changed
So from that I assume if I wanted to fix an issue, I had to manually open the Sonar Website, find the project, find the issue, assign it to me, than commit. That's not really acceptable. So I assume there is some other way for Sonar to handle that information.
How do I find out who fixed a Sonar issue?
Unfortunately, you're not going to be able to do this because:
When an issue is created, it's associated with a line in a file, and assigned to its "creator", the last person to touch that line.
When an issue closed, it stays associated to its file, but loses the line association. So there's no way to attach "praise" to a closed issue because we've lost the link between the issue and the person - the line number.
On a side note, you say something about assigning yourself issues on SonarQube before fixing them. Perhaps that was in an attempt to make the "praise" association, but there's no reason to do this.
To the issue of knowing who's not fixing their issues: you can always search by assignee (and/or creator) in the Issues interface. The Issue count and age you see there should give you some idea of what's going on.
Here's the error I was getting in VS2015: "One or more checked work items failed the transition testing due to invalid field values. Please correct the values and retry the check-in."
I had this when checking in an associated work item and flagging the item as resolved. So
Work item in in progress
Check in with this work item marked as resolved
Work item is updated to ready to test
BUT
the work item can't move into the new state as it needs additional information. In my case TFS is set to assign the bug back to the person that raised it. It was such an old bug that the person raising it had left the company and doesn't exist in TFS - hence the error.
Moral of the story - fix bugs quicker.
In my case, I was forced to do the Associate since I got the error message. When I went into the Work Item in VSTS I manually resolved it and it prompted me to set a required field. Were that required field set, the Resolve from Visual Studio would have worked.
I faced same issue while check in from visual studio.
Change the related work item as associate instead of resolve from visual studio solved my issue.
As a workaround : Create a new task/bug in your VSTS for whichever story. Then assign your check in to that work-item. That's what the error is somewhat saying... Difficult for me to decipher at first, hope this helps others.
You need to determine the task status you have created for your TASK. You should set your task state -- Development or other, You get an error because "state" is "new"
I'm using DevOps 2019 on-prem and I had 1 little update to share.
I created the Bug on the Web Portal and kept it open, added the Ticket Number for the checkin and got the above error.
EASY FIX :
Remove Ticket from Checkin
Close Ticket in Web Portal
Re add Ticket
Checkin
ALL IS GOOD.
I have several files failed to update in windows installer patch. They are dynamic link files， with file hash changes， but the MsiFileHash table “File_" has changed for each file, below is the same file in MisFileHash table:
RTM fileA:_A0FB2DAA62D356E1B64EA457014BA886 0 543212956 662074909 -1730111711 -2096793600
Patch7 fileA: _490DC427E0D9E512E96D3E9BF2B317C7 0 -1371102532 -401194406 -232195904 525972747
Maybe this causes the update failure.
So I ask, will any way to force the dynamic link component to update in patch?
Thanks
A common reason for this is that the patch broke the component rules (for example by removing a component). A verbose log of the patch install would say something about SELMGR and component removal not supported. The patch update would go into advertised mode and fail to update anything. It would be useful to post the verbose log anyway to see if there is an entry about file replacement and whether an attempt was made to replace it and what it said (and this won't be there if component rules were broken).
The other issue is more obscure but is likely to cause problems. The primary key of the MsiFileHash (File_ field) table has changed. This implies that other primary keys in the new MSI have also changed. This is relevant:
https://blogs.msdn.microsoft.com/windows_installer_team/2007/03/07/arbitrary-labels-used-as-primary-keys-must-not-be-changed-between-versions/
but the bottom line quote from there is what matters " It’s imperative that the primary keys are not changed between versions of the package. " and that's because the MSI is a relational database and changing keys in different versions of the product will lead to unpredictable effects.
There is no indication of what tool you are using to create the patch, but most of them don't typically cause either of these issues because they build the patch taking account of the structure of the RTM and the rebuilt MSI file.
When you in visual studio 2013/tfs2012 check in your work associated with A task you can either 'associate' or 'resolve' the task. Setting it to 'resolve' Will automatically move the task on the sprint backlog and the kanban board to 'Done'. This is Nice because AS A developer you only need to check in using the correct status and status everywhere is okay :-).
This does not Seem to be the case with work items of type 'Bug' - here I Can only choose 'associate' inside vs2013 and then I also need to manually Enter web access and set the bug to 'done'. So I'm kind of doing the same work twice.
Can I without customizing TFS work item types or the proces template get this bug status set to 'resolved' as it works with 'tasks' today - and how?
It's definitely possible - We use "resolve" with every bug (under the Agile template) because it saves such a lot of time. In pending changes, just associate the bug (type in its work item id, or drag and drop the bug into that area of the pending changes) and then you can either "associate" or "resolve" it. (After which the originator can verify the fix and close it)
I presume you're using a template that doesn't offer this facility - so perhaps diff your template against the standard Agile template and you may find the tweak you need to allow this behaviour. Does the template you are using support the "resolved" state on bugs? Perhaps it is missing?
If it is just that your bug template skips the "resolved" state, then it would be trivial to either rename the equivalent state (perhaps it's just not being picked up by the UI because it's not named correctly or not in the correct group?) or insert a new state using the WIT editor.
It's really not a good idea to set a bug as done on checkin. Has the coder verified that the completed output meets the definition of done? How can they hope to do that before they check in?
A bug, just like a PBI, greys set to done when a Development Team decides as a group that out is complete and that they have met ask quality bars.
In the Scrum template Bugs are product level items that confirm to the DoD. However you would break that bug down into a number of tasks at your sprint planning meeting and they can be resolved. The workflow for a bug is:
1) Bug created by tester as the result of a failing test.
2) Bug accepted into the sprint by the Development Team.
3) Bug broken down into tasks for at least coding and testing work.
4) Coder fixes the bug and resolves their Task. The checkin marks this task as Done.
5) Tester validates the Test Case that proves the bugs existence now passes. They mark their Task as Done.
6) The Development Team meets and assesses the doneness of the Bug against the DoD. If done they mark it as Done.
A bugs flow is different from a task.
A bug is raised (tester / user / Developer)
A Bug is fixed (Developer)
A Bug is Tested (built, Integrated to main build, deployed, Tested by Testers)
A bug is done (signed off by the originator)
is the general flow of a bug, TFS ALM assumes that the fixing and the testing would be done by 2 different roles.
if you want to change this to mirror the task work flow, you would have to alter the template
We also use the Microsoft.VSTS.Actions.Checkin action to transition a bug between Development and QA states. Developers can Associate or Resolve, and Resolve triggers the state change attempt. HOWEVER, if any fields are required in the transition, such as Root Cause, the transition will fail without any error message. This is unfortunate. It would be great if the bug popped open and said "Please enter this field." If required fields are filled in before the checkin, then the state transition happens as expected.