What I want:
I have created a script in the Script Editor that makes your first
line item in a cart free. I want this script to execute once per customer.
My question:
What is the syntax to limit a script to execute once per customer
through the use of the Script Editor app?
Business use case:
Without adding this functionality to my script, a customer could
checkout with 1 item free... but then they could begin shopping again
and checkout with a new cart with the first line item free again... that
means they could get 10 free items from 10 different checkouts.
Thanks for your time and thoughts!
P.S. Script is in Ruby. Also, Setting up a discount code won't work for my use case.
UPDATE
Thank you for your responses. I will be attempting these suggested updates this week and will post my results soon.
UPDATE 2
So the below suggestions and marked answer were all spot on except for one detail. The script editor keeps on running into some type of error even though the described syntax below is correct. Another stackoverflow answer suggested to use '&'.
So I ended up doing something like this:
customer = Input.cart.customer
if customer&.tags&.include?("gift_received")
...
end
This works for me. Thanks again for all your answers!
Any kind of solution could only work if Accounts are required
otherwise you can't track the history of orders.
There are two possible solutions
You create a flow that assigns a tag to a customer when they receive a gift. You check for the tag : Input.cart.customer.tags.include?('gift_received') and don't apply the discount.
If your case is just 'Gift on the first order' you can just check Input.cart.customer.orders_count > 0 and that's it.
Um. You can always just assign a little tag to the customer. For example, if they received this free item, give them a tag on their first order. Now, if they try and fool you nine more times, check for that tag. If they have it, remove the item from checkout. Boom. problem solved.
I have created a script in the Script Editor that makes your first line item in a cart free. I want this script to execute once per customer.
The best way is to flag customers using tags. You can use Shopify flows to add tags to orders containing free gifts to mark customers as the customers who received already free gifts. This will be better than checking Input.cart.customer.orders_count > 0 because it will give you more visibility in the orders & customers panel.
The approach mentioned by #Fabio Filippi is the best however it needs to be secured:
You create a flow that assigns a tag to a customer when they receive a gift. You check for the tag : Input.cart.customer.tags.include?('gift_received') and don't apply the discount.
Business use case:
Without adding this functionality to my script, a customer could checkout with 1 item free... but then they could begin shopping again and checkout with a new cart with the first line item free again... that means they could get 10 free items from 10 different checkouts.
Nothing prevents the user from creating a new account so you need to consider some verification logic that will be assigning the gift_received tag after the customer is validated.
If you want to avoid fraud I would consider using both (note that in this case we are checking if customer already bought something in the past) Input.cart.customer.orders_count > 1 and Input.cart.customer.tags.include?('gift_received') OR Input.cart.customer.tags.include?('gift_received') and Input.cart.customer.total_spent > Money.new(cents: 1000). This way you can have "eligible for gift" kind of logic. There are many ways to approach it.
Related
I want to create Make,model and year type work in open cart.I am new to open cart and don't know which one suite my work.Since model depends on make and similarly year depends on model value.So keeping in mind that i am unable to select which one i select for my work.Hopefully someone get my point.this type of work done in extensions but i want to do it by my own.So want to know filter will be best or attributes for this kind of work.Thanks
There are plenty of affordable options in the opencart extension store as well as codecanyon
http://www.opencart.com/index.php?route=extension/extension/info&extension_id=3621
is the one I use, love it. Developing this for yourself will be a ton of work and likely be buggy if you're asking for help here. There are many variables to consider, which is why I always advise you purchase a tested and true extension.
Here's what I'd like to do with Lift: I want to build a dynamic shopping cart, with lines able to be added and removed via AJAX calls. The total needs to be wired to the specific lines. Each line would include a number, the length of time for a lease, and a calculated price based on that, so I would have to add wired cells on each addable/removable line as well. So it would look something like this:
Number Length of Lease Price Remove?
(AJAX Textbox) (AJAX Dropdown Select) (Plain Updateable Text) (Ajax Checkbox)
(Another Row)...
+ Add
Total: ______
The problem I'm running into is that I can find resources to build a static page that displays all of this via Wiring. Using the Lift Demo site, I can pull up code that will let me add new lines, but it doesn't seem to me to be conducive to removing lines (this in general is one of my frustrations with Lift at the moment: a "little extra detail" to change from a tutorial ends up requiring me to completely change tacks and spend hours more at work and research, and I want to figure out how I'm probably approaching these problems wrongly!). Alternatively, I can use CSS selectors to dynamically create content, but I don't know how to effectively wire these together.
In addition, all of my attempts end up creating 2-3 times the amount of code I would have written to simply do some JQuery updates on the page, so I suspect that I'm doing something wrong and overcomplicating everything.
What resources would people recommend to set me on the right path?
These are your best resources for learning Lift:
Simply Lift
Lift Cookbook
Lift in Action
For any specific questions, I highly recommend you join us at the Lift Community Google Group. It is the official support channel for Lift. Although a few of us occasionally help out here at Stackoverflow, the best Lift help can be found there.
Please consider the situation where a product has extra SKU parts in it's custom options. The product may have a SKU product and the custom option has option, the end result will automatically be product-option.
Now go into the admin and attempt to order this product with a custom price, the custom option becomes an 'additional option' and the extra -option is missing. My store (enterprise 1.8) needs these SKUs to be intact but I need help making a fix for this. I expect I will have to override Mage_Adminhtml_Model_Sales_Order_Create at some point and that's OK.
I've googled this problem until my fingers are numb but cannot even find mention of it let alone a confirmed fix. Please point me at the cause of the problem.
This was hard to track down because it seemed intermittent. I'm answering myself in detail because I don't want anyone else to go through the same ordeal.
The problem stemmed from custom options which both added a custom SKU and contained a colon in their title. If you look closely in the following picture you can just see two colons in "Colors::Black" - the first is the option's name, the second is added by Magento. When updating the order it attempts to parse the custom options back from that text box and the extra colon throws a spanner.
The other bad thing is because Magento cannot read the custom option back that particular option gets dropped. In this case it's a required option, which leads to a warning message.
Since the option is missing so is it's SKU part. Other custom options are not affected which clouds the issue. The simple answer to all this is to just avoid colons.
Currently Magento has a problem with the way it handles mass actions. It returns a bit of JS that contains EVERY db id for the current collection and filter, regardless of pagination. This is to support the 'Select All' vs. 'Select All Visible' option in the grid header. This isn't such a problem when you have a smaller number of records, but if you have 850k records (orders in this case) it becomes a serious problem.
My question is, does anyone have an elegant solution to this problem?
I can think of several solutions, each with its own drawbacks, but I'm hoping someone has solved this in a simple manner that works as an add-on module. Paid or Open-Source solutions are both welcome suggestions.
Clarification:
I'm looking for an elegant/drop-in solution to the problem of 850k+ records using the grid widget in Magento. The stock Magento code makes the bone headed decision to return the id for every record that is matched by the current filter, even if they are not being displayed. This is not about offline processing of records, it's about using the grid widget for daily admin tasks.
One possible solution would be to store the results of the filtered search in a temp table and return a reference to the search result. Then you could change it from using the actual ids on a 'Select All' to using a specific callback for the action using the reference. This would preserve the current behavior.
So, to ask again, does anyone have a good solution to this already created?
I'm running heavy operations from within a shell script. I have a generic iterator (in my case products, but can be done with everything else), and I only implement a class that does the action on the product. My product_iterator shell script takes care of looping over the products, while processing only x products at once (to avoid memory leaks).
Well, the least invasive solution to the problem is to turn off the 'Select All' option for grids with large numbers of records. This is easily accomplished by extending the grid class and adding the following code:
protected function _prepareMassaction()
{
$this->getMassactionBlock()->setUseSelectAll(false);
return parent::_prepareMassaction();
}
I think that fbmc has the right general approach. Clearly, even if you did find a way to send back all 850k records, the framework would have a heart attack attempting to deal with them all. Run the logic in a shell script if this is what you need. For some jobs, you may even need to run them in batches or move down to actual SQL logic.
Unfortunately, some parts of the framework were not made to handle this kind of scale. You've found one of them.
Hope that helps!
Thanks,
Joe
Recently i have written an article about 'Adding new mass action to admin grid in Magento',
Hopefully you will like it:
http://www.blog.magepsycho.com/adding-new-mass-action-to-admin-grid-in-magento/
It describes the two way for adding Mass Action
1> Extending Grid Layouts _prepareMassaction() method
2> Using event: core_block_abstract_prepare_layout_before (more upgrade proof way)
Thanks
Regards
I've long thought (but never practiced for some reason) that a dropdown menu that is dynamically generated and only contains one item, should automatically select that item. This would opposed to the typical approach that I've observed where a blank entry is made at the top and you still have to interact with the menu to make the single available selection.
An example is when I login to my online banking and select "View Paper Statements". I've only got one account so the next step in the process is to present me with a dropdown where I have to select that single account to proceed. In this case, by implementing the solution above, it would take one less click to select the account and proceed to viewing it. Even better in this case would be to eliminate the dropdown menu step altogether and go right to the statement.
Can you think of a case where auto-select of a single item would produce undesirable results?
Can you think of a case where auto-select of a single item would produce undesirable results?
Yes - any case where the user has the option not to select any option.
In your bank account example, pre-selecting the only value makes sense. But if you have e.g. some kind of form where users can provide voluntary information, they will need the possiblity to leave that field blank or otherwise give a possible incorrect answer.
So it really should depend on the nature of the data in that dropdown whether pre-selection is a good idea or not.
I completely agree, in the case you describe. But there are times where you want to force the user to make a selection actively -- e.g., when the value of the field is somehow optional or additive.
In your case, without selecting an account, there's probably no useful way to proceed, so automatic selection does make sense. But for example, an application I'm working on allows the user to specify a number of descriptive fields (movie metadata, basically -- title, release year, genre, etc.), many of which are optional, and some of them are represented by drop-down menus. Allowing the user to leave the default selection blank lets him tell us, effectively, "I don't want to use this field," so we leave it blank, and the data remains clean.
Just one example, although you're right -- in your case, I can see how that'd be annoying. :)
If there is truly only one possibility you shouldn't ask a user to decide between Option A. (Bad grammar to illustrate the point)
If the field can be left blank, it's not an option with a single answer. Instead you have a choice between Option A "meaningful data" and Option B "".
Iif list has blank option but the form does not allow that to be blank, it's a choice between Option A. (Bad grammar to illustrate the point)
Sometimes you want the user to explicitly select an option, even when it's the only option. If the option is selected automatically, the user may never even realise it, even though they may not be happy with the result.
For example, I'm reviewing my savings account on my internet bank site. Then I go to set up a payment. As it happens, I'm not allowed to make payments from my savings account, so the payment form automatically selects my only other account. If I don't notice this then I will end up making the payment from my other account when I was expecting to use my savings account. If I had known, I wouldn't have made the payment at all.
Perhaps this is slightly contrived. But unless you can be certain that the user will be happy with the (only) choice, you should ensure that they choose it explicitly.
I agree. If there's only one item in the dropdown and it's required that the user select something, then just default to the single item. I can't think of any negative effects of this (but I'm certainly not a UI expert)
What I like to do in this instance depends on a few factors.
If the dropdown is a required field and ends up with only one item due to dynamic generation, I try to avoid displaying it as a dropdown entirely. I end up showing it as an uneditable text field instead (or not displaying it at all if it isn't necessary). Why make it even look like it's a choice when it isn't?
If the dropdown is not required, then it makes total sense to display a blank choice in addition to the single value.
If it's REQ and there's a single record/value .. I'd try and change the control to a Display field rather than the Drop Down.