What is the meaning of "Waiting for revision" status in nature's manuscript tracking system? We recently received decision on our manuscript, which we initially thought is rejected. However, the current status of the manuscript is "Waiting for revision".
Can someone please explain what it means?
regards,
Eliza
Related
On our DNN portal (version 7.3.4) we are using Live Articles module - for posting articles/news. When new article/news is published, subscribed users get notification email about that.
Few days ago we and all the subscribers have received such an email but no article/news was really published at all - last published one was half a year ago, which is correct.
So why did we get that email notification?
I went to check Database DNN logs and found out that:
The article was really created - it was a generic "Welcome to Live Article".
I guess it was created through workflow, because there are events in table LiveArticles_Workflow about that article which indicates there were three steps taken - "Content Approval", "Content Staging" and "Direct Publishing.
By ModuleID I see that it was created in module that doesn't even exist in our DNN - ModuleID is way to high.
Does anybody had such an issue before?
Is it possible that module was updated or something (but not by us) and that's why we've get such a notification?
I thank you all in advance for help.
Have you tried to contact the vendor? In this case it is Mandeeps. They have a support area there, and a knowledge base that could help you.
One of our users is getting an error when they attempt to make a purchase and I'm trying to identify why this is occurring.
The message returned from PayPal is:
<Errors xmlns="urn:ebay:apis:eBLBaseComponents">
<ShortMessage>Transaction refused</ShortMessage>
<LongMessage>This transaction cannot be completed because it violates the PayPal User Agreement.</LongMessage>
<ErrorCode>13122</ErrorCode>
<SeverityCode>Error</SeverityCode>
</Errors>
This product is working for other users, just not him.
Obviously it's violating the User Agreement but I'd like to identify why.
UPDATE
The users that are affected by it seem to all have one or more of the following: a non-UK email address, a non-UK PayPal account or a non-UK payment source.
We've not had a resolution yet, but have directed several users to contact PayPal directly. The feedback we've had is as follows:
"I tried with another paypal account, that failed too, despite being able to use both PayPal accounts to pay for other services."
"PayPal are aware of the error message, but they simply cannot explain why it's happening. After an hour on the phone with them today, they seem incapable of tracing the reason for this error."
Needless to say we've got some very frustrated users.
I had similar problem... Title of our item we were selling was:
Inc. Special Offer: <<Famous author>> eBook for only 10.00$
When we changed the title to something more descriptive, everything was OK
Did you open a ticket with MTS or call the Business Support line? If you did open a ticket can you please give me the ticket number? I'll take a look at it.
It may be something that you need to address with Business Support though.
I had this same error coming back for one of our customers and I had the same issue as #knagode with my product name.
For some reason "Dark Havana" in the product name set this off and produced this error. If I ever hear back from Paypal on why this phrase is not acceptable, I will circle back and edit this response.
It turns out that the value in "PaymentDetailsItem - Name" was one part of the problem. We didn't have any special characters (or so I thought) in there, just "product name: person name". When I spoke to PayPal support their response is as follows:
"I have checked it, it's a combination of many things that we cannot disclose.
However removing the ":" before the name PAYMENTREQUEST_0_NAME should work.
Can you send PAYMENTREQUEST_0_NAME=xxxx USER NAME
Instead of PAYMENTREQUEST_0_NAME=xxxx : USER NAME"
Once I had removed the ":" from that field, it started working again...bizarre!
This error still gets triggered with non-UK PayPal accounts but happens less frequently now.
For any others investigating this issue please be aware that PayPal has filters in place that looks for globally specific geographic terms. If any terms used in the product description trigger the filters, the transaction could be refused. In our case, we are online rug retailer with many of our products ranging across the traditional rug spectrum. We found that any rug with the term "Persia" in the title were being refused due to economic sanctions against nation states associated with that term.
The filters are not geographic only and other controversial terms could also trigger the filters to refuse the transaction. In one instance, we had a rug with "Confederate" in the product description that also triggered the filters.
I'm determined to get this algorithm (if you want to call it that) figured out over the weekend and I think I'll need the help of cron jobs or maybe clockwork.
Here's my logic:
When adding a book, it needs to be stuck in a "queue line" or "queue status" and will only be "published" at the top of the week. At the top of the week, if no book has been "queued", add a new "published" book & make the form available again (the form will get hidden once a book has been queued to publish next). When I say top of the week, I mean that a book must be published every 7 days, going from the date the user's account was created.
To give some background, I'm creating an app where users are encouraged to read one book per week over the course of 2013 (yeah this thing has to launch by Monday!). They are able to add a book that they're going to read the next week and change the status of that book to 'read' once they read it. If they don't change the status to 'read' within 7 days of adding it, it automatically gets moved down the line and displays as 'unread' and the new blank book gets added (like what I explained above).
The whole adding of books and changing the status to read/unread is already complete. I'm just looking for help setting up the 7 day incremental book adding and "queue line".
Some insight into my code:
I have a books controller & model that belongs_to a user. My user model has_many books.
I'm adding and displaying the users' books through the user show view.
I'm sure there are things that I'm leaving out that will help better explain my environment, so just ask me :) Thanks!
I don't think you need a chron job for this.
What I would do is add a status to each book of read/unread. And then write a method in the model that checks on page load and modifies the view or controller data for display.
Rails/Ruby has some nice date/time helpers where you can say date1 <= 7.days.ago.
Is there any reason why this approach won't work?
I'm using HP QC to manage defects (just started) and had a question regarding the various defect status types....
We have:
New - new defect
Open - ??
Active - defect is being investigated
Fixed - dev team have issued a fix-need retest
Ready For Test - self explanatory
I know there are other status' but I'm not entirely sure of the meaning of open in particular...
I.e in what instances is a defect open
In a well organized defect management system different (user)roles are defined.
Each step in the process is maintained by a certain role.
Open means that the defects is checked by a senior and can be assigned or picked up by a solver.
For example:
A developer/tester logs a defect -> status becomes new.
The developer/tester can't change the status to open/active or whatever. The defect just sits there waiting.
A testmanager (or defect coordinator/senior tester) checks the defect. (completeness, validity, duplicate etc). When the defect is ok, he changes the status to open. He can also assign a solver.
When a solver starts on working on the defect, he changes the status to active. Everyone can see who is busy working on this defect (investigating or solving).
Solver fixes defect and changes status to fixed.
Testmanager collects all fixed defects and assigns testers to them. Status change to Ready for (re)test.
etc.
I am one of the web developers for a small-but-growing e-commerce site. It is now getting about 150 orders per day, and a lot more on Cyber Monday. This is enough volume so that the small fraction of users who have hard-to-reproduce problems are causing significant heacache. My theory is that one of more of the following are true:
The customer is on an unusual browser / OS
The customer experiences a network glitch
The payment gateway takes too long to return a response
The customer somehow hits escape or the back button during a critical moment in the ordering process
The customer closes their browser
The customer's browser just refuses to navigate to the next page
The end result of these problems is usually that a customer unknowingly gets their credit card charged, and often attempts to place a second order. In that case a refund has to be issued on one of these duplicated transactions.
Although I would like to convince my client that there will always be a "normal" percentage of orders that have "weird" glitches, I don't know what "normal" is.
My question is therefore:
In your experience as an e-commerce developer,
what is your observed rate of these glitches?
Alternatively, if you can point me towards statistics, that'd be helpful, too! I haven't been able to find any.
Thanks!
ps. I know that it would be ideal to fix the root cause of such problems, but I simply have not been able to reproduce the problem, even after submitting hundreds of test orders.
You know the old saying - "If you have to ask, you can't affort it"?
It applies here.
It's very likely that your problems would be caused by the reason you listed above - apart from any bugs in your code, of course.
But is that a good enough explanation for your client? As the application traffic increases these problems are likely to increase as well.
You may need to implement a more robust process that can handle unexpected problems, so that customers are not charged unless you have captured their order or they are notified by email that their order completed / something went wrong / what action they should take.
edit:
Your question is when to stop improving the website. I think this depends on the level of service (read: time) you want to give to your client vs their expectations of what they have paid for.
How you deal with it forms part of your business strategy, but my approach would be to very honestly show them a list like this with time estimates to fix each item. Ensure they understand the diminishing returns that each of these fixes achieves. Give them something for free, and charge them for anything else. Negiotiate with them; give them a KPI or performance target that you guarantee to meet. It's important that they understand the costs involved in designing a near-perfect transactional system.
Rather than guessing, I'd try to assert how the errors are raised, build a simple form where users can leave you the browser they used, system specs (maybe) and the steps to reproduce the defect that araised.
Then with that information you can debug your app, make unit tests and fix these bugs, or reduce them to a form where they won't impede your users from buying stuff at your site.
Usually it is just one or two people with weird cards or weird browser/OS combo that cause all the headache, while all "normal" people proceed fine.
You better switch to a gateway that supports background processing (customer always stays on your checkout page while order info is packed into XML and posted to the gateway, and it instantly responds with any errors) - this will at least eliminate navigation problems for dummies.