Does anyone have a nice example of integration between HelpSpot and Fogbugz?
We're using HelpSpot as our customer facing software and ticket management, and then if a developer needs to work on a ticket the data will be pushed to Fogbugz.
Obviously we can use the Fogbugz push API that Userscape provides, but this only allows you to specify the title of the incident in Fogbugz. Ideally I want to share title, assigned to, category and status in a two-way integration.
Do most people just use emails between the two programs, or has anyone come across a nice third party app?
Thanks in advance!
I think you might get better help with this on the dedicated FogBugz StackExchange website.
The FogBugz API example in the HelpSpot docs can be modified to do what you want. What you can do is specify you're own format for the push box text. So have staff put the category on line one, a note on line 2, etc and then parse it in the FB push file and set it as needed.
For the HelpSpot --> FogBugz way: as far as I can see, the provided FogBugz push implementation is only an example which you can extend and customize to your needs.
If you look at the push function in RequestPush-FogBugz.php there are the parameters sending to FogBugz. You can set additional data in here (request attributes are specified in the HelpSpot documentation and FogBugz fields are specified in the FogBugz API documentation).
Of course you have to provide the mapping between users and other metadata (or e.g. use the exactly same usernames in FogBugz and HelpSpot).
Related
I am trying to apply roles for several users using the projects/:project_id/users/:user_id endpoint.
Roles are correctly assigned to each user, however the services associated to that roles are not applied at all.
As I see in several other sources, it seems to be a known limitation and I would like to know if there is any workaround I can use.
I can see that from the web interface, when a rol is selected a call to a /project_users/:project_id/update_member is invoked where a list of roles and services are posted and works as intended. Is there perhaps any undocumented endpoint I can use?
As you already found out, unfortunately, it is a known limitation, which we hear repeatedly. We can easily understandable use case in setting a project users. Sadly, we do not have a workaround. Here is a ID for the wish:
ACSADMIN-530 (was HQ-3034): “API wish: adding users beyond Docs”
Sorry for not being helpful here.
I'm using Wix as an e-commerce solution and the way I understand it, I can only add code (not edit current code) to make specific changes to the site. The one change I want to make is to have the ability to authorize/capture PayPal payments at a later date for all the products I am selling.
I've read through the PayPal authorization/capture documentation here but am still confused for my specific use case considering the only button I have is a "Check Out with Paypal" once customers have added products to their cart as opposed to "Buy Now" or some of the other button options available.
Is there a way to easily integrate authorize/capture in this case and if so, can someone help me out with how? Hoping I can make one change no matter how many different products a customer is purchasing that allows me to either capture all or part of the entire purchase amount and void the rest.
I've scoured the internet, but don't feel like anything I've come across is directly applicable. See here and here. The latter link makes it look insanely easy, but again I think the problem lies in the fact that I'm using Wix and can't directly edit existing code.
If anyone can provide directions/code necessary to implement this I'd be extremely grateful. Thanks so much in advance!
Note: It appears Wix integrates with PayPal Standard and all I need is the "Basic Authorization" capability, NOT "Order Authorizations."
The latter link makes it look insanely easy, but again I think the problem lies in the fact that I'm using Wix and can't directly edit existing code.
You've nailed it. It would be that easy, just add the parameter paymentaction=authorization when redirecting to PayPal, but Wix needs to provide a way for this to happen.
Many shopping carts -- especially those that integrate via an API rather than Payments Standard -- have a checkbox in their settings to toggle on authorization mode vs. immediate capture (sale) mode. The reason API-based integrations are much more likely to implement such a setting, is that an API is needed for the shopping cart to be able to capture the authorization at a later point in time. API-less integrations (like payments standard) cannot do the capture themselves (because this requires an API call), and so with standard you'll always need to log into www.paypal.com for the capture later on.
Anyway, there's probably no way forward unless Wix provides you with one.
Wix could well be using an API integration rather than the HTML-only Payments Standard, but the problem is the same: the API needs to specify 'authorization' (instead of 'sale'/'capture'), and from their lack of documenting the feature it does not appear Wix has implemented this.
Most shopping cart/platform providers do support authorization and capture, so you could make the feature request to Wix, and/or consider switching providers if it's a must-have.
On a general note, using authorization and capture adds complexity to payment processing, and the capture is not guaranteed to be successful. You can get a successful authorization and then have the payment fail when you try to capture it (happens in a certain % of cases, when funds are no longer available or the card decides to decline). So in general, you use immediate sale/capture at checkout time (not authorization) unless you have very specific and well-defined business needs to not be capturing up front (and refunding in the case of exceptions).
Setting up an API with Azure API management. We've created 2 products, one that requires subscription and one that don't. We did this as vi have a single API where we want some of the operations to required subscription and others where we don't. Is this possible in a single API or do we need to create two APIs? The issue with 2 APIs is that any prefix ala "/api" needs to be different, and we want it to look like a single API
This is not possible, unfortunately.
As stated in the documentation subscriptions only apply to Products and individual APIs.
Se this UserVoice suggestion where "Operation Visibility" is suggested.
Greetings from Denmark ;-)
/rasmus
Is there an automated way to create a change log using TFS 2010 and the version history of the files? I'd like to pull in all the comments that were entered for each changeset either between a label (or a specific date) and the current version, or between two labels (or two specific dates).
Try using http://tfschangelog.codeplex.com. this tool allows users to generate release notes against given set of changeset range. It extracts information in XML format for all the changesets within a given range along with associated work items. It then uses XSLT 2.0 to translate output from XML into HTML. This way, users can use apply their own logic for filtering, styling, reporting format, etc.
Hope this is useful.
Are you asking
Is there a tool already that does all of this for me?
OR
Can I automate this process?
If #1, my answer is "I don't know, but I would check CodePlex and the Microsoft TFS downloads on MSDN" for this type of tool.
If #2, there are web services you can use to query TFS. They don't have the "give me all changes between X and Y date or A and B release", but you can get information on changesets, work items, etc. As you would be creating a document, good check in note discipline is mandatory to get a coherent document, unless you just want to know what was actually changed in code, which I think is overkill.
Are the APIs mature enough to easily automate to create version 1.x changes are type of documents? My answer is no, but your mileage may vary.
The tf.exe command line tool with give you the history or more or more items between two points in the history where those points can be specified by date, label or changeset number.
Eg.
tf history /version:C5~C8 MyClass.cs
See the help on MSDN: http://msdn.microsoft.com/en-us/library/yxtbh4yh.aspx
Here is a simple CLI app that does just the job. It returns a changelog as text.
https://github.com/sandrock/tfchangelog
According to the sources, it enumerates changesets and outputs the comments in the terminal.
I want to use Pivotal Tracker for a new project but I don't know how to use it with Mercurial to make it easy to go from one tool to the other.
What workflow do you use to link user stories/feature in Pivotal Tracker with your DVCS (Mercurial/Git)?
Thanks in advance for your advices.
If someone is still looking for an answer, there exists a service which allows mercurial users to connect to pivotal tracker using a syntax like [#story_id finished] in their commit messages. Bitbucket allows for this integration as well.
Links: https://bitbucket.org/proppy/hgpivotal/src/tip/hgpivotal.py
Note from Pivotal Tracker on the format:
The minimum commit message string that will allow Tracker to associate
a source_commits POST with a story and create a comment is a single
story ID enclosed in square brackets: '[#12345678]'. A more typical
message, indicating that one commit completes two stories (which need
not be in the same Tracker project), might look like this: 'finally
[finished #12345678 #12345779], fixes client/server integration
glitch'
If an included story was not already started (it was in the "not
started" state), an update to that story from /source_commits that
doesn't contain any other state-change information will automatically
start the story.
To automatically finish a story by using a commit message, include
"fixed", "completed", or "finished" in the square brackets in addition
to the story ID. You may use different cases or forms of these verbs,
such as "Fix" or "FIXES", and they may appear before or after the
story ID. Note: For features, use of one of these keywords will put
the story in the finished state. For chores, it will put the story in
the accepted state.
In some environments, code that is committed is automatically
deployed. For this situation, use the keyword "delivers" and feature
stories will be put in the delivered state.
You should use Post-Commit Hooks to link the two tools:
The Tracker API supports integration with post-commit hooks of Source Control Management (SCM) systems such as Subversion, Git, etc.
When a commit is made to the SCM, a trigger can call the Tracker API to add a story comment with the commit ID, author and message. It can also optionally change the story state.
Those hooks exists for Git, and should be written for Mercurial.