I need to create a condition for my camunada when I come back.
the goal is :
I validate the phone number and come back, I must be on the screen where I must enter the mail address and the mobil number.
I don't validate the phone number and come back, I must be on the screen where I can validate my phone number.
You are modelling a business process. This process has a persistent state. So whenever the process reached a user task, until you complete it, the process will wait at that user task.
This does not depend on you coming back.
Related
I am trying to create an action for the google assistant using google transactions, when I take it out of Development Sandbox to allow real orders and transactions, it will prepare the order and the receipt. Then it is supposed to check if the order will be accepted or rejected and wait for the user to say that they want to make the order, however, it waits for the user but then closes the action straight away and doesn't let the user input anything.
So, I have an App where the user needs to sign up to access the app. I'm planning to run an offer where user can order that item only once in a day. But I have the doubt that he may change login Id (if have multiple emails) and can place the order with Different ID's.
I'm thinking of registering the device with an email id:
Pros: - Not able to login with a different email Id.
Cons: - Not able to use the app on a different device ( if changed) as it may give an error email Id already registered with another device.Which leads to deregister from the previous device (Chances device may not be available).Or raise a ticket which is time-consuming. this may lead to customer loss.
Have also, read about IP tracking, Phone number, and Credit card details but not satisfied with the answers (somebody already raised for same). So what will be a good method to avoid multiple logins/sign up from the same device?
You can get the MAC adress from device using WifiInfo.getMacAddress()
I am using mixpanel user profile tracking.
1 : If a new user, say A , visit my site and go through some pages without sign-up. That time mixpanel is tracking events to a unknown profile.
2 : Then the user A, sign up in my site and placed an order.
That time mixpanel is tracking previous events and the events after sign up also to a the same profile. (mentioned in above point).
3 : Then the user comes to my site using his mobile, then he go through the pages without login
That time mixpanel track the events to different a profile.
4 : The user then logged in in his mobile and continue to place order.
Then the mixpanel track events after the login into the previous profile mentioned in the 1st and 2 nd step.
My problem is I would like to re-map the tracking done in the 3rd step also to the profile which is used to track in 1st and 2nd step
There are 2 routes
1-) Queue anonymous events: the idea would be that instead of sending Mixpanel the events when the user is still anonymous, you save them either on the device (if it's a mobile app) or on your server. Then, when the user logs in, or creates the account, you can flush the stored events since now you know who the user is. As you might realize, the downside is that if the user never logs in or signs up, then the events are never sent (unless you build a mechanism in your server to flush them in that case).
2-) You could so as you currently do, but when the person goes to step 4, and logs in, before changing the ID to the correct one, you could create a People profile with the anonymous ID, mark it with a flag that it's an orphaned profile, and save the correct ID for it. That way, you can schedule a task to look at those profiles every so often, export their events, and import them back with the correct ID. That would essentially duplicate the data for those events, but you would have the full history with the correct ID. You could also try to filter events based on the "orphaned" flag later on, but it does mean you will always have to have it mind.
I am implementing a simple server-side verification for Windows 8 IAPs and I'm slightly baffled on how to handle this. Basically what I do know is I verify the receipt using the code that was included in the example
http://msdn.microsoft.com/en-ie/library/windows/apps/jj649137.aspx
In the example, there is a AppReceipt and ProductReceipt. If I understood it correctly, having a simple IAP to buy, for example, gold in the game, I am only interested in the ProductReceipt. However, I don't understand why "AppReceipt" is included here at all. Is the initial app purchase always included in the receipt or is it an optional field?
So an unified way of making sure the user cannot "cash in" the same receipt twice would simply to save the ProductReceipt ID in the back end database? And that this would be a valid approach for both durables and consumables, of which the latter is not yet implemented?
AppReceipt is just an example that you can ignore. In most cases game will send you receipt (ProductReceipt XML) and you will have to verify it on server side.
If you look at: http://social.msdn.microsoft.com/Forums/windowsapps/en-US/8b3cf68d-897d-4a47-ace0-2c42355bf688/protecting-your-windows-store-app-from-unauthorized-use?forum=windowsstore
You will notice:
The ID of each receipt element is unique per user (and device) and you can validate it on your server to confirm that the transaction is legitimate for that user and not a fraudulent transaction. This is especially valuable when your app has its own authentication mechanism because it allows you to validate that each user that appears to have purchased your app is, in fact, a unique customer.
So if you want to, you can extract IDs from this XML.
I'm working on a project that require my application to pay the user to his paypal account when he asks it.
Here's how I did it so far:
The (logged) user goes to the Pay page that will list all his Payments (received or not)
He enters his Paypal email and his application (mine) password (for security)
The POST page get a list of all the Payments that have status="UNPAID" for that user and update the status to "WORKING" (to avoid the user to refresh the page before the whole process is done and resend the same amount of money)
We count the total amount to pay in that list (a simple for)
The amount is sent to Paypal via Paypal Adaptive Payment API (request: PAY)
The response is checked, if completed, the list status is set to "COMPLETED", if not, the list is reverted to "UNPAID" (the SQL update is made via a WHERE id IN(x, y, z) in case a second Payment request has been made during that time.
A message is then displayed to the user
But I need your help, I'm in front of one risky problem I'd like to avoid, and I would know how you would do:
If the user hit refresh on the process page, I don't want to send him twice (or more) the amount (The "WORKING" lock is here for that, but what happens if the user hit refresh before I set the lock ?)
Rare possible: what happens if the user hit f5 after the lock "WORKING" is made, but before the request to paypal, and a new payment is received. By following what I did, just one item (the new) would be get and set to WORKING, but all others previous payment would be losts
How would you do? What is the best way to make it to be 100% reliable?
Thanks for your help
Note:
The steps between 4 to 6 is made via a PlayFramework jobs, called with now() and awaiting() the result
you can:
prevent double post via JQuery
use the checkAuthenticity() method to validate the request
do a GET redirect after processing the POST (so they can't submit the same 2 times even by mistake)
do the payment processing asynchronous (see below)
For the payment, instead of calling the job, set the id's of payments in a queue (or table in the database) and a job that runs once per minute that processes that table if it has some data. When the user does the POST you redirect to a page that says that you are processing the payments and will notify if there is some issue. You can notify the user later via a UI warning using comet or via mail.
That way you don't link the request to the processing, and you won't have threading/racing issues, as well as being able to detect stale requests (payments already done) if you do a sequential processing.