I received this error after upgrading Prestashop when I try to update the stock in Back Office for specific product.
There is Ajax Request which goes to fail when submit save button.
I found an answer to my question
The problems with updating stock appear on products with no principal category.
Even if you you choose more categories, you need one principal checked.
Related
I am using Shopify Admin REST API for item and inventory sync and I am not sending inventory_quantity field in variants API, but I received following email from Shopify few days ago. I am also sending correct location_id when creating fulfillment and it is created successfully in Shopify.
The location_id field is now required when creating fulfillment and
refund requests.
Inventory_quantity and inventory_quantity_adjustment
can no longer be set on the product variant.
Deprecated in 2019-10 and support will be removed on July 1, 2020
I wanted to know if the email above is a generic email sent by Shopify to all developers? or am I doing something wrong here?
Ignore it if you're sure that you don't use these deprecated attributes anymore. I think they recently introduced this notification system which sends warnings to developers if they detected any deprecated calls in the past. They just alert you, they don't scan your app code so they don't know whether you fixed the issue or not. I was getting similar warnings despite that I was sure that the issue had been fixed earlier.
Anyway, to get peace of mind, go to the Apps area in your Shopify Partners account. The table that lists all your apps has now the API health column showing the status of your apps in terms of deprecated calls. You will see a warning (orange dot) if they detected any deprecated calls in the past 30 days. The warning is provided with some additional information like the last time the issue was detected and the deadline to fix it to, example. You can get more details about the deprecation by clicking on to the warning.
If it's a private app, just check your code again for using the deprecated attributes mentioned in the email.
You will want to check the new Inventory Level and Inventory Item endpoints in the Rest API. With a variant's inventory_item_id and a location ID, you can update inventory.
Clearly you can no longer just set a variant's inventory level. That went the way of the DODO this year.
I updated the specific price for a product correctly in Admin, but when going to the front shop product page, it still shows the original price. When i add product to cart, then it shows the correct specific price. I am using prestashop 1.6.0.14. Is there someone else who has this issue or knows how to solve it?
You need a fresh version of the files product.tpl and/or product.js. I just solved this by trial and error :). It wasn't an upgrade, I moved a ps site from one server to another, specific price on product page wasn't displaying (was actually there, but hidden, I saw that by mistake on Edge). So, I replaced those two files and it works. Good luck!
Before I ask my question I want to give you a quick overview about the topic.
I got a sharepoint list (SP 2013) which has content approval feature enabled. For this list you can choose who should see the draft versions of an item. Most logic option here is to let the author and all approvers see the draft. Now imagine that an item has been approved and now again edited. There is a version that is draft (because it needs to be approved again) and a version that had been approved before.
Here comes the tricky part :-). I fetch the items of that list via REST api. My query includes "_ModerationStatus eq 0" which means that I only fetch approved items. Users who are not allowed to see drafts automatically get the last-approved version of the item, although there is a draft version waiting to be approved. Users who are allowed to see draft versions see (I would expect something different here) NOTHING! So instead of fetching the last-approved item, the query has no result for users which are able to see drafts. Now if I perform the query without "_ModerationStatus eq 0" these users see the draft version while others (not allowed to see drafts) still see the last-approved version.
So finally my question is: Is there any chance to change this beaviour? I want SP to return the last approved version for ALL users via REST api. If these users open the SP-list itself they sure should see the draft. So it is only about the rest api.
I don´t think that this is possible (did not find anything to change this) and I thik the REST api just mirrors the behaviour of the native view behaviour of the SP-list-view itself.
Thank you in advance!
regards
Ben
Here are two possible solutions for this problem:
Create a second list and let a workflow create or update items on this list whenever a new or updated item has been approved on the main list.
A: Worklist -> New or changed Item -> Workflow -> Create or update item on List B: Productionlist
Use the unique ID of items to check if an item does already exist on list B.
You can read about the second possible solution here: https://sharepoint.stackexchange.com/questions/116921/distinguish-between-approved-and-not-approved-items-rest-api
With OData__ModerationStatus it is possible to get the approval status for each item that your request fetched via REST. So you could probably place a flag DRAFT to any not approved draft versions to let the author and all approvers know that this is not an approved version.
Of course it is possible to get the last approved versions for each item but that will cause a need for additional requests and validation etc.
Hope this helps :)
Just use the following,
http://WebAppUrl/_api/web/getfilebyserverrelativeurl('/RelativePathToFile')/MajorVersion
Example:
http://contoso.com/_api/web/getfilebyserverrelativeurl('/_catalogs/masterpage/css/main.css')/MajorVersion
That returns the recent major version published
I have a webshop and im almost there, but I have a number of items for purchase which are downloadable content. I fixed so when a user has paid they are redirected to my pdt.php where they get a receipt, Now I written code for also displaying content if the item-id are == something. Now I wanna make a sandbox/test-purchase of all products that are downloadable ontent which are 28. I can create 28 buttons and have the id 1-28 but that seems stupid. How can I do this easier?
Check out the cart upload command method of sending transaction data to PayPal. It's similar to standard buttons except that you'll include all items in a single form.
Alternatively, if you're familiar with web service API's I'd recommend using the Express Checkout API. This gives you more freedom over your checkout and provides more advanced features as well.
on my website I sell unique items. I have programmed it so that on the selling page, users can select any amount of these items, and it calculates the cost. The key is that I only have 1 of each of these items. So I need the shopping cart system to not allow the payment to go through unless it is available.
I've been searching for a good quick/easy/cheap solution and can't find one. I don't expect this site to make a lot of money (the transactions are a few bucks), so I didn't want to need a ssl certificate.
The only way I know of not needing an ssl certificate would be to use paypal or google checkout. However, I do not think there is a way of using these services and making paypal's server run a script to check how many are available on the site. Any solution?
Thanks
I was thinking about it more, and I think the problem is that once the user gets to the paypal payment screen, I have no control. I guess I could do something like they click the buy it now link, a php script updates it to sold, then they go to the paypal screen, but then they might not continue the purchase...
If you use PayPal Website Payments Standard (using a cart rather than 'Buy Now' Buttons) then you could use IPN or PDT (see the paypal docs here) to get PayPal to call back to you with the status of the payment.
The work flow would then be to set status to reserved when the item is added to the cart, and then wait for the IPN/PDT call to come back with the payment status, and mark the item as sold.
You would still need to check and reset to available any item that had been reserved for longer than say 2 Hours. (You could do this before serving a page to a user so that they have the latest availability and you don't need a cron job or long running process)
If you could provide a little more information about how you have implemented ur shopping card, it would have been more easier for other to assist! If you are using any ecommerce solution then it should be there already in the track inventory section. But Provided that you have implemented d shopping cart manually, why don't you add little bit of codes that checks the inventory status first before letting your customers check out?