I'm trying to remove the Email entity from an unmanaged solution but on export the entity is added back into the solution and included as part of the export.
I can remove it from the solution fine, save and publish customizations and see that Email is no longer part of the solution. However, when I export the solution irrespective of whether I perform another publish, the Email entity is been added back into the solution and gets included in the unmanaged export. I can successfully remove PhoneCall and Task.
The only dependency on Email is from account which would be resolved on import as the target solution obviously contains Email.
Any ideas as to why I would be seeing this behaviour? Assuming it's not a "feature" any suggestions on how to resolve this would be appreciated.
This issue was related to a Case Creation Rule. We have a rule in the solution that creates the Case from Email and removing this custom rule prevents the reintroduction of the Email entity into the export.
I've reproduced this in a separate solution so I believe this is a bug in the new Case Creation Rules added in SP1. I don't think you'd ever want entities being added to the export without your knowledge on export. They should just be defined like all others as a missing dependency.
Related
I'm a tester and my manager has add new team project to the TFS and add my user and a developer user for this team project, when I've tried to add any type of work items the list of "Assigned To" shows all the users correctly, except for the "bug work item" only, I can't assigned to any user and shows that it is not in the list of supported values.
how can I solve this problem?
First, make sure the work item that you're manipulating currently in a state that has a valid transition to New. Otherwise, you will not be able to save the changes.
If you have customized the bug work item type. According to sounds like a rule in the bug workflow or field.
If you run the [witadmin exportwitd] command and export the bug work item type, look for the Assigned To Field and look at the rules on the field. Also take a look at the section and look at the rules for the transitions.
Also take a look at this similar question on TFS2015 Bug/Task unable to assign it to someone else than the user that creates it, try the suggestion mentioned in the link:
needed to give the relevant global top-level permissions for everyone
to view stuff
Just run the below in order to grant the needed rights :
tfssecurity /a+ Server FrameworkGlobalSecurity GenericRead
> "[DefaultCollection]\Project Collection Valid Users" ALLOW
> /collection:http://tfsserver:8080/tfs/DefaultCollection
Ok, I have a workflow built in SharePoint 2010, built in SharePoint Designer. It is set up to begin whenever a new item is created. The library is also set up to create new items based on email attachments. So the goal is for users to email the attachments to the library and the workflow takes over.
The workflow only works for me. The other people attempting to use it are listed as Full Control in the permissions. They are using the correct email address, and the library is creating the new items based on the attachments. The problem is that the workflow keeps saying error occurred.
The error says something about some columns needing different types of data, but when I email to the library it goes off without a hitch.
I am completely stumped as to what could be different about them sending the email instead of me.
Sorry I got kind of long winded, and thanks in advance for any help.
The system account is not allowed to initiate workflow on its own. There is a powershell that you need to run to enable system account to run workflow. Also try impersonation in workflow.
Here found it.
stsadm.exe –o setproperty –propertyname declarativeworkflowautostartonemailenabled –propertyvalue yes
Not sure what was wrong with it, but I just deleted it then rebuilt it and now it works. Don't think I did anything different so I'm not sure.
Does anyone know how to create a branch using the VSO Api. The documentation for Branches doesn't include a "create".
I have been experimenting with doing it via the ChangeSet Api without much success.
This is TFVC, not Git.
Just as what you see in "Branches" page, there isn't any way to create branch with the Rest API. And mostly, you can only read/get the information with the Version Control API for now.
I would recommend you to use Client Object Model Reference if you want to manage the Version Control programmatically. To create a branch, use the "CreateBranch()" method in Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer class.
The REST API apparently does allow one to create branches.
The confusion is that people think that this would be a PUT operation on the Branches endpoint of some kind.
It is not.
In the REST API, a branch is just one more kind of change that is checked in as part of a changeset.
It took me a long time to discover this, myself; and I was using the old SOAP API in the belief, shared by everyone else it appears from what I can find in Q&As on the WWW, that this wasn't part of the REST API.
Of course, using the SOAP API prohibits using .NET 5, because the assemblies only come for .NET Framework.
An abandonware API on an abandonware runtime is not a satisfactory way to talk to source control. ☺
The terrible Azure DevOps documentation gives no clue as to this, except for 1 obscure not-even-a-complete-sentence hidden in a minor class: "List of merge sources in case of rename or branch creation."
The only other clue is what appears in the JSON, from a get changeset changes, that describes the changeset of an already-made branch.
The (also abandoned) Azure DevOps sample code does not contain examples for even deleting an item, let alone branching.
Changesets are checked in via the changeset creation endpoint.
The individual change is a TfvcChange in the changeset's list of changes where:
the version control type (which is a set of flags) contains the branch flag; and
the merge source for the change specifies the source item and the range of changeset numbers.
Branching an entire tree appears to be a matter of branching the directory and all of the files and directories in the directory.
In C♯ or PowerShell, this is a TfvcChange with a VersionControlChangeType of Branch, in a TfvcChangeset passed to TfvcHttpClientBase.CreateChangesetAsync().
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.
We've been using Trac for a while now for our developers only. However we are now opening it up for our (internal) clients. We have a project listing page (based on the default one that comes with Trac). What we'd like to do, is display more information about the project than what is currently available.
I have searched google and here, to see if I can find how to get more information. There seems to be a variable called $project which has .name, .description and .href as attributes.
Is there somewhere, a list of the attributes available? Or perhaps a different solution altogether that will allow us to display more information on the project list page. Such as the number of open tickets etc.
As far as I known, you can use $project.env as well. It is an object, which provides a number of attributes:
$project.env.base_url
$project.env.base_url_for_redirect
$project.env.secure_cookies
$project.env.project_name
$project.env.project_description
$project.env.project_url
$project.env.project_admin
$project.env.project_admin_trac_url
$project.env.project_footer
$project.env.project_icon
$project.env.log_type
$project.env.log_file
$project.env.log_level
$project.env.log_format
More detail is available at env.py
On the project page customization page there is not much variables, indeed. Looking at the source code there is also trac.version, trac.time, but that's all. There is also project.env that may hold more information. I do not have a multiproject setup at hand, so you might be interested to see for yourself what variables are available with TracDeveloper plugin. It dumps variables if enabled and you add debug=true in the URL.