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

Add early exit for "fatal" errors like wrong usergroup, not valid yet, not valid anymore, etc. #23

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

Schrank
Copy link
Member

@Schrank Schrank commented Nov 14, 2019

Add early exit for "fatal" errors like wrong usergroup, not valid yet, not valid anymore, etc.
fix broken HTML
fix date format for magemail (hopefully)
Cleanup

Closes #22

Add early exit for "fatal" errors like wrong usergroup, not valid yet, not valid anymore, etc.
fix broken HTML
fix date format for magemail (hopefully)
@Schrank Schrank requested review from lfolco and sprankhub November 14, 2019 11:05
if (!$message) {
return '';
}
$message = '<li class="promo_error_item">' . $this->_helper->__($message, $params) . '</li>';
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be the default behaviour? Doesn't _formatMessage always generates invalid HTML by putting text directly inside the ul without having a li?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, because the nested messages come with container already back. But we have the problem, that we try to translate the already nested stuff. So in theory we should refactor all that, so that we have arrays with the messages, then we translate everything and then we format it with html. But I don't have the right mind currently to do that properly and test it.

Copy link
Contributor

@lfolco lfolco left a comment

Choose a reason for hiding this comment

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

Since we're adding the new <li> elements, can we apply them to the additional messages? I updated the tests that do not have the additional messages to reflect the new elements, but the additional messages are still contained directly within <ul> elements.

Also, would be great to have some tests for the new show-stopper behavior.

@lfolco lfolco self-assigned this Nov 16, 2019
@Schrank
Copy link
Member Author

Schrank commented Dec 2, 2019

I have not forgotten, and read the comment - will take care of that! Soon(ish) :-/

@Schrank
Copy link
Member Author

Schrank commented Jan 13, 2020

Sorry @lfolco that is now a lot, but I gave my best, fixed a bug, cleaned up a lot, and added at least one test for the show stopper

@Schrank
Copy link
Member Author

Schrank commented Jan 13, 2020

@sprankhub you can review either here or on the company repo 😅

@lfolco
Copy link
Contributor

lfolco commented Feb 7, 2020

Sorry for the delay, it's been a crazy holiday season and then some. Will review this weekend!

@lfolco
Copy link
Contributor

lfolco commented Feb 8, 2020

These changes don't work for conditions. For example, on the improvements branch:

image

On the master branch:
image

This is for a rule setup like this:

image

There are a ton of changes in this branch, too many to figure out what exactly is going on, but over half of the of the tests fail:

image

Any chance you can break this PR up into smaller PRs that don't change so many things?

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.

show stopper - don't add more errors after certain things happen
3 participants