Unfortunately there’s no way I will have time to try and reimplement your app. If you could make a jsfiddle or a stripped down version in a public repo I would be happy to try and take a look at some point but I’d recommend you invest some time in debugging practice anyway.
Debuggers are an invaluable tool in any language, javascript included. Most of the tools and methods you use are very similar to those in the IDE for any language (breakpoints, stepping, etc) so if you take some time to learn good debugging practice it will help you in any language/framework.
I’m sure there are many great debugging articles out there, definitely do some google research, but the basics as they relate to Ember can be described pretty easily. Sorry if you know some of this already just figured it helps to be thorough.
First, open up the developer console. I prefer Chrome and in Chrome it’s called the “Developer Tools” under “More Tools” in the menu. If you’re on a mac you can open it with command + option + i, if you’re on Windows I think it’s usually F12. Safari and Firefox will look pretty similar but things will look a little different and names may be a little different. Anyway, once you have that opened it should look something like this:
This is the javascript console, which allows you to enter javascript commands, look at console.log debug output, etc. And of course see deprecation warnings like you see in the screenshot.
Next, click the “Sources” tab, which will show you all the code your browser has loaded for the app. You’ll want to look under “assets”, then under your project name, then go to “controllers”, then find the name of your controller and click that file. It should open up the controller code in the pane to the right like this:
Find the function you want to debug, probably unesiOcenu
in your case, and put a breakpoint on the first line of the function (it won’t allow you to breakpoint a comment or whitespace so it has to be a “logical line”). To place a breakpoint, just click the line number corresponding to that line on the left and it should make a little blue arrow over that line number. It should look like this:
A breakpoint is basically a way of telling the debugger “when you hit this line, pause (or “break”)”. Then you can analyze what is in the declared variables and you can step through the function line by line until you figure out what’s going wrong.
Next you’ll want to trigger the breakpoint that you set. To do that, you just need to trigger the action that you set the breakpoint in by clicking in your app. Once the breakpoint is hit, the app execution will pause and the debugger will look like this:
The “current line” has a blue bar across it, and of course since the app paused at the breakpoint, the “current line” is the line with the breakpoint. This is where the fun part starts. On the right part of the debugger pane you should see some buttons that look like this:

From left to right they are: “continue” which unpauses your app execution, “step over” which is probably the most useful button at least for starters, “step in” and “step out” which are used to dive into function calls and back out of function stacks, and then a couple buttons for removing and disabling breakpoints. The first two buttons are probably the only ones you’ll use for starters: “continue” and “step over”. Essentially if you “step over” a line, you’re just advancing one line in the current function.
So let’s step over a couple lines and see what happens. In my example here I pressed the “step over” button three times, which executed the first three lines of the function.
As you can see the blue bar representing the “current line” is all the way down below the ugly comment (which the debugger ignores). What you also might notice, and which is the cool part, is that I can see what’s in the variables that were defined in the first three lines, for example it actually shows me that “orderStatus” is “Open”. Further, if you hover your mouse over a variable, it will show you the value in a little popover kinda like this:
In this case, ‘self’ is a complex object (it’s the controller itself) and I can see all of the properties and functions defined on that object when I hover over it. It’s very powerful and can let you look at code exactly as it’s running. It definitely beats using alerts or console.logs. What you’ll want to do is, starting with your action, put a breakpoint at the top and then step through the entire function, looking at all the variables and trying to figure out where the bug is occurring. Note that any code in a “then” block is actually another function and it is run asynchronously, so to debug that you’ll also want to put a breakpoint in the “then” block and then hit “continue” to let the app continue running until it hits the “then” block.
Anyway, hope all that can help get you started. I can’t emphasize enough how important good debugging practice is (and again that applies to any programming language and framework). It will help you tremendously in being able to debug issues like the one you’re seeing and it takes a lot of the guesswork out.