I have set up two referral credit rules.
All acting users get 7 default credits every time they trigger the event mq_app_open
Referred acting users get 10 default credits every time they trigger the event mq_app_open
mq_app_open is a custom event that I am recording on app open.
I can see that rule 1 is getting applied but can never get rule 2 to be applied.
What actually does "Referred acting users" actually mean?
I think the issue probably relates to the fact that when I open the app from a (universal) deeplink I see two events
open
mq_app_open
For each of Session Referring Branch Link ID, Session Referring Click ID and Session Referring Link URL are all null.
Oddly, when I let the app go into the background and then the foreground again I see the following events
open
referred session
For these two events Session Referring Branch Link ID, Session Referring Click ID have values but Session Referring Link URL is null.
I am not sure why any of these values are null when it would seem they should all reference back to the link url that was clicked on.
Alex from Branch.io here:
Referred acting users is a rather confusing way to say 'users who take action and open the app after clicking on a Branch link'. We should probably adjust our terminology to make this a bit clearer. For most purposes, you can think of this as Referred users.
I am actually not certain why rule 1 is working but rule 2 is not. Possibly there is some conflict with having two rules applying to the same user from the same event — you could try refactoring the rules so that Referring users get 7 points and Referred users get 17.
Those session parameters should be coming back with values, assuming a link was clicked. We probably need to do a bit more debugging to see what's going on — would you mind submitting a ticket to the Branch integrations team so that we can dig into the code and the backend config of your specific app?
Related
Hi i'm actually working on a report system for my social network, i want to achieve something like : if a user is reported 5 times it will update a field on the user table to deactivate the user.
So if 5 row of reports is created i want to update the "activated" field
The thing is i'm working with GraphQL and Vue for the first time, my backend is in Symfony with ApiPlatform.
Should i try to query all the reports with the userId who is reported to count if there is 5 row when a user is reported and then mutate the user object to deactivate it or can i achieve this more easily on the backend side ?
So anything of importance should be done on the backend. The frontend is easily hacked and while it's good to stop normal (good) users from seeing something they're not supposed to, it's not a blocker to anyone who has even rudimentary web coding ability.
Seeing as you're talking about someone being reported, I'd recommend doing it on the backend and then make sure the frontend reflects that gracefully.
Hum it seems that the answer is that i need a reportListener and i need to listen the postPersist event, then inside this function i can check how many report there is for a user using the ReportRepository->findBy function, then i can count the row of the array return by the function and if the count is > 5 then i edit my user, persist and flush.
If you type IAM <GO> in the terminal you'll be shown the UserID, UUID, CLID etc.
Is it possible to extract this information through blpapi when using the Desktop API to connect via BBComm? I've seen references to Identity and populating that by sending an AuthorizationRequest but it appears that's only relevant for SAPI/B-PIPE.
To the best of my knowledge and after asking a couple of Bloomberg reps - this isn't possible. The best work around which I've found is: each user creates an EQS screen called their UUID. Add some filtering which causes this screening to return nothing. Then the application, upon start up, requests all possible UUIDs as EQS screens and stops when it doesn't get back an error - that's the UUID.
This is a dirty, dirty hack and, granted, this only works if you have few distinct users using your system. You don't want to ask may users to create such a screen and probably don't want to iterate over thousands of EQS screen names.
There is a "SID report" which is provide together with monthly invoices from Bloomberg which contains the UUIDs for users - this can be used to look up existing users but when setting up a brand new account you have to manually copy this information out of the terminal.
I have set up SpecFlow to execute a number of Selenium tests to test a website. This all works fine!
I am just considering if there might be room for some optimization on the structuring of the SpecFlow features.
All the scenarios in a specific feature should use the same login. This is something I have hardcoded in the StepDefinition using the [BeforeScenario()] hook at the moment, since I don't really wan't pollute the scenarios with login info. It isn't relevant for the test.
But at the same time, I would like to remove the hardcoded part, and move this into my feature.
My question is two part.
Can I specify login credentials in my feature description. Sort of like a Given:
Feature: As a user I want to be able to see my ongoing orders, and interact with them.
Given I am logged in with username abc and password xyz
Scenario: See list of ongoing order
Given I place an order
When I navigate to MyOrders page
Then I can see at least one order in the list
Is this good practice?
Does it make sense to do it like this, on the feature level I mean. The scenarios are not dependent on a specific order, and they would execute faster if I didn't need to log in for each scenario.
Thanks for your input.
For steps that are common to all scenarios in a feature you can use Backgrounds:
Feature: As a user I want to be able to see my ongoing orders, and interact with them.
Background:
Given I am logged in with username abc and password xyz
Scenario: See list of ongoing order
Given I place an order
When I navigate to MyOrders page
Then I can see at least one order in the list
Too much abuse of background steps can be a bad practice because it introduces coupling between your scenarios.
Another solution is to put the login part directly into your "I Place an order" step.
This will remove all the noise about login stuff since it's implicit that you need to log in to place an order.
I'd also suggest to call it "I've placed an order" instead of "I place an order".
Given steps are usually pre-condition that describes what happened prior using the functionnality (when steps)
When I first read your post, I thought of Dan North: Who's domain is it anyway? and that influences me to think that we should be trying to write our tests so that they stick to a single knowledge domain. As you talk about specific users and navigation and orders in a list, well its very like the example he gives in that your specification is crossing domains. This kind of leads me towards almost making your specification less specific, i.e. its not about navigating and checking a list, do you have an order or not!
Scenario: See list of ongoing order
Given I am logged in with username abc and password xyz
And I place an order
Then should have at least one order
I wanted to give you another example link, to a post I cant find, which talks about the benefits that a team has got by actually defining some example users and what value that gives their testing. So in your business domain you might have a user called Jack who will have placed a large order in the system, and another prospective client Jill with no orders. In this way tests such as
Given I am Jack
When I search for my orders
Then I will find 1
Given I am Jill
When I search for my orders
Then I will find 0
can guarantee that you are only testing your Search functionality, and less about getting the setup in place.
I'd also suggest that you have a look at Liz Keogh: Acceptance Criteria vs Scenarios who asserts that more general broad definitions are less valuable than very specific examples. (It is Specification By Example after all :-) )
So to answer your question, I think having the specified user is a good thing, but doing it how you are doing it is heading a very complicated route.
The scenario examples that are given are completely not in line with the Feature.
Feature: As a user I want to be able to see my ongoing orders, and interact with them.
Background:
Given I am logged in as John Doe
Scenario: This is taking to long
And I have placed an order more than 29 days ago
When I navigate to MyOrders page
Then I can see my order in the list
and I am able to cancel it
Scenario: Track package
And I have been notified my order has been send
When I navigate to MyOrders page
Then I can see my order in the list
and I am able to navigate to the postman's site and see its status
Scenario: Review item
And I have received my package
When I navigate to MyOrders page
Then I can see my order in the list
and I am able to review the item
Scenario: Contact Seller
And I have placed an order two weeks ago
When I navigate to MyOrders page
Then I can see my order in the list
and I am able to ask the seller what is going on
As you can see the When and the Then is starting to duplicate itself and you might want to consider tucking those away.
I am new to Clickbank.
I want to try out the API for the same.
But I am stuck in between.
Can anyone guide me through the steps to successfully create a product.
I am getting some errors
You must make a test purchase before submiting this request.
A footer disclaimer is required for all Pitch and Thank You pages.
Also wanted to know, like how can I setup the sandbox account?
Please help me out.
Thanks in advance.
This question was asked a very long time ago but I just happened across it and know the answers.
First, however I think anyone starting on ClickBank, technical or otherwise, will benefit from the following: https://www.clickbank.com/launch-checklist/
Now, to answer the question(s):
Test Purchase:
• Can't do this without creating a product first
• To create a product you do the following:
Login to the account
Click: Vendor Settings -> My Products
On this page locate the list of ADD NEW buttons & Click Product
The product editor pretty well walks you through the process
AND now for the test purchase.
That process is described here: https://support.clickbank.com/hc/en-us/articles/360036958431-How-do-I-test-a-payment-link-
Footer/disclaimer:
This is what is known as the ClickBank Trust Badge currently, (not sure about 9years ago).
It's a little element that you copy and paste into your webpage, after configuring what you want it to look like & where you want it to be, from the available options.
To find and set it up:
Login to the account
Click Vendor Settings -> My Site
Scroll down to the section with the title "ClickBank Trust Badge - Injection Code"
If you like the default setup you can copy what's in the Javascript Snippet field
If you want to change where it's located and colors click the Configure Settings button (not going to describe everything here as it's pretty straight forward as well)
ClickBank APIs
Last, you mentioned wanting to use the ClickBank API, which I happen to know very well. However, the documentation for it is also actually pretty good so let me start off with that:
General ClickBank API documentation
Additionally each APIs primary endpoint is self documenting. Additionally this documentation tends to be the most relevant for a programmer
Example of self documenting endpoint: https://api.clickbank.com/rest/1.3/orders2
So, it's worth noting the following that are required to use the API:
You must have an HTTP header of "Authorization" and it must be set to both of the API keys for an account.
Both keys refers to the API- "Clerk Key" as well as the DEV- "Developer Key"
Enter them both, separated by a colon ":" as the value of the Authorization key with the DEV- key first (DEV-A23478C...:API-IA23456...)
You must also use the correct HTTP request type for the query you are wanting to make (the only two that are utilized are GET and POST)
Examples:(NOTE: ACCOUNT_NAME_HERE is the ClickBank "nickname" or account name)
Single transaction: https://api.clickbank.com/rest/1.3/orders2/RECEIPT_NUMBER_HERE
List transactions by date range and specific account: https://api.clickbank.com/rest/1.3/orders2/list?vendor=ACCOUNTNAME_HERE&startDate=2021-12-11&endDate=2021-12-14
Count of transactions by date range: https://api.clickbank.com/rest/1.3/orders2/count/?vendor=ACCOUNT_NAME_HERE&startDate=2022-01-01&endDate=2022-01-01
Monetary value of transactions by date range: https://api.clickbank.com/rest/1.3/quickstats/count/?account=ACCOUNT_NAME_HERE&startDate=2022-02-01&endDate=2022-02-10
Sending shipping data for physical products (POST): https://api.clickbank.com/rest/1.3/shipping2/shipnotice/4NVXUFNW?item=2&date=2018-08-14&carrier=UPS&tracking=1NH323452345WODFS&comments=Test%20again%20comment%20with%20spaces10%20receipt=4NVXUFNW
I'd been looking at using the Rally API to create an app to do some simple auto-ranking stories based on specific criteria (at the request of / to help out a couple of our Product Owners) in a drag&drop workspace.
I did this by adjusting the "Rank" properties of the sequence of stories (I made sure to keep the rank values within the same overall min / max range as prior to the auto-reorder). I made a call to the API to update each story's rank individually (in quick succession).
Testing the app, I found that sometimes after running the auto-ranking app, some screens (such as the kanban board) would tell me that "drag and drop re-ranking is disabled for manual rank workspaces" (and the kanban would no longer let me drag & drop, although other screens such as the backlog would still let me drag & drop, and the workspace settings were still set to drag & drop). Deleting the stories, or reordering them on the backlog screen would return things back to normal.
After trying a few ideas to solve this, I figured perhaps if I was updating the Rank on a number of stories in quick succession, the back-end might be getting confused with these (potentially several / concurrent) requests. Introducing a delay between each story's API call has seemed to avoid the problem, and to speed things up, I now update a story's rank in the API only after the previous story's rank update has invoked the "updateComplete" function.
Do the assumptions in the last paragraph above make sense based on the backend ranking? Is there any Javascript API call to update multiple stories at once? (Otherwise I'm quite happy with the solution of only calling the API "update rank" after the prior API "rank update" call has returned ok).
That sounds like you discovered a possible issue with the backend ranking. The warning you were getting stems from the board trying to figure out which type of workspace you are in (manual or dnd rank). Since that setting is not currently available via WSAPI the board tries to figure it out based on its data and sometimes gets it wrong.
Currently there is no fully supported/documented way to adjust the ranks of items via WSAPI. The Card Board component in the App SDK uses special rankAbove and rankBelow query string parameters during update calls (which you can see in Firebug or the Chrome dev tools).
How are you currently setting the Rank values?