Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove any whitespace from a promo code. #1796

Merged

Conversation

eric1234
Copy link
Contributor

There is no legit reason to have spaces in codes as the user would have to duplicate the spacing when they entered the code during checkout.

I have gotten real world cases where a store admin has inadvertently included a space before/after the code (due to a copy/paste error), as well as space within the code (due to font size making it hard to
see the space).

I considered putting a validation in place to correct the user rather than silently modifying their code but we are already silently modifying by downcasing the code. Even after being told of a spacing problems,
some users might have difficultly determing where the space is or understanding the error message. In the interest of just doing what they likely mean, I think silently modifying is the lesser of two evils.

@@ -39,4 +40,8 @@ def usage_limit
def downcase_value
self.value = value.downcase
end

def remove_excess_whitespace
value&.gsub! /\s+/, ''

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unexpected token error
ambiguous first argument; put parentheses or a space even after the operator

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume the "ambiguous first argument" is indicating I should add parens. So gsub!(/\s+/, '') (under the idea that somehow that is clearer).

Is the unexpected token error referring to the safe navigation operator? Is this a project decision (compat with older Ruby) or just hound not knowing the more modern syntax?

Copy link
Contributor

@jordan-brough jordan-brough Mar 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's compat with older Ruby. Solidus currently only requires Ruby 2.2.2 so we can't use the safe navigation operator.
https://github.com/solidusio/solidus/blob/1a556fb/solidus.gemspec#L15

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have a validation for code presence so I don't think we need to consider nil values. Also I think we should use self.value = value.strip (not bang method and not worry about internal whitespace). Open to others' thoughts on that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you guys regarding the internal whitespace. I will say I have had a real world case where the admin put whitespace in the middle and couldn't see it because of the small font size. The question is how far do we go to make it fool proof since there is always a bigger fool?

We do know whitespace should never be in a code so doesn't seem to hurt to remove it. The person who pays my paycheck is the one who added the whitespace so if you prefer strip I'll just have to do a local override.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think .strip can be enough for fixing the main issue (whitespace before or after). Each store will be able to override the method easily if needed.

@@ -39,4 +40,8 @@ def usage_limit
def downcase_value
self.value = value.downcase
end

def remove_excess_whitespace
value&.gsub! /\s+/, ''

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unexpected token error
ambiguous first argument; put parentheses or a space even after the operator

Copy link
Contributor

@jordan-brough jordan-brough left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a good addition, but I left a couple thoughts.

@@ -39,4 +40,8 @@ def usage_limit
def downcase_value
self.value = value.downcase
end

def remove_excess_whitespace
value&.gsub! /\s+/, ''
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have a validation for code presence so I don't think we need to consider nil values. Also I think we should use self.value = value.strip (not bang method and not worry about internal whitespace). Open to others' thoughts on that.

Copy link
Member

@kennyadsl kennyadsl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eric1234 sorry for the late response, I think we can carry this on if you have time to change code following the strip suggestion.

@@ -39,4 +40,8 @@ def usage_limit
def downcase_value
self.value = value.downcase
end

def remove_excess_whitespace
value&.gsub! /\s+/, ''
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think .strip can be enough for fixing the main issue (whitespace before or after). Each store will be able to override the method easily if needed.

Copy link
Contributor

@mamhoff mamhoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine. strip would work as well, and is potentially less intrusive. However, this works as well as strip, and I'm worried we're bike shedding here. I think this can go in as-is. @jordan-brough @kennyadsl ?

@kennyadsl
Copy link
Member

Talking with @mamhoff he convinced me that the current version is good enough to be merged. Having promo codes with spaces inside is not a documented feature so we should not care that much about it.

Copy link
Contributor

@jhawthorn jhawthorn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be done.

Users shouldn't enter a value and have it changed without them noticing. An admin might really want to enter "SAVE MORE" as their coupon code. If we don't want to allow it, that's fine, but it should be done as a validation (or using html5 form inputs/JS) rather than surprising users.

I'm also concerned that this could modify existing values in the database if for any reason a promotion_code was saved.

TL;DR I'd prefer a validation or a JS/html change instead.

@eric1234
Copy link
Contributor Author

eric1234 commented Oct 5, 2017

The last paragraphs in my original PR message explained why I opted for silently modifying over explicit validation. I saw it as the lesser of two evils but that is a bit of opinion. If you guys prefer validation then go ahead and close the PR.

Copy link
Member

@tvdeyen tvdeyen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think strip is ok, but I don't see any reason why we should not allow whitespace inside the code.

end

context 'with extra spacing' do
let(:code) { ' new code '}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Space missing inside }.

end

context 'with extra spacing' do
let(:code) { ' new code '}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Space missing inside }.

@eric1234
Copy link
Contributor Author

eric1234 commented Oct 9, 2017

I didn't expect so a small little change to make so much discussion. To get this thing closed and move onto more exciting things I have updated the PR to strip so that spaces within a code are supported.

I also went ahead and combined it with the existing downcasing method to reduce the clutter.

As if you should merge this or use @jhawthorn validation version (or both) I'll leave that up to you guys. I prefer the system just do what they mean rather than having the user try to remove characters they cannot see but understand if you prefer it the other way.

Regardless the PR is updated so it is ready if you do want to merge. If not then feel free to close.

@mamhoff
Copy link
Contributor

mamhoff commented Oct 9, 2017

Hey @eric1234 thank you, very nice work (and yeah, this has generated a lot of discussion).

Would you mind merging the three commits into one (and removing the code nazi language)?

Thank you again for your patience and hard work.

There is no legit reason to have spaces in codes as the user would
have to duplicate the spacing when they entered the code during
checkout.

I have gotten real world cases where a store admin has inadvertently
included a space before/after the code (due to a copy/paste error).

I have also gotten cases where the admin has accidentally put spaces
within a code and could not tell because of the small font. After
discussion it was decided we will not remove these due to the
possibility that some stores may want spaces in their code.

I considered putting a validation in place to correct the user rather
than silently modifying their code but we are already silently modifying
by downcasing the code. Even after being told of a spacing problems,
some users might have difficultly determining where the space is or
understanding the error message. In the interest of just doing what
they likely mean, I think silently modifying is the lesser of two
evils.
@eric1234 eric1234 force-pushed the clean_whitespace_on_promo_codes branch from a847aff to 7c01d19 Compare October 9, 2017 11:02
@eric1234
Copy link
Contributor Author

eric1234 commented Oct 9, 2017

K, squashed and rebased to master. My frustration with overzealous code linters removed. :)

Copy link
Member

@tvdeyen tvdeyen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine now

@jordan-brough jordan-brough merged commit 52653ae into solidusio:master Oct 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants