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

Bill-to Name and Ship-to Name trancated to 20 characters in backend #7279

Closed
yumicom opened this issue Nov 2, 2016 · 21 comments
Closed

Bill-to Name and Ship-to Name trancated to 20 characters in backend #7279

yumicom opened this issue Nov 2, 2016 · 21 comments
Assignees
Labels
bug report Component: Checkout Fixed in 2.1.x The issue has been fixed in 2.1 release line Fixed in 2.2.x The issue has been fixed in 2.2 release line Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Release Line: 2.1

Comments

@yumicom
Copy link

yumicom commented Nov 2, 2016

Preconditions

Magento ver. 2.1.2
php version 7.0, MariaDB 10.1

Steps to reproduce

Input firstname longer than 20 characters on Checkout shipping step

Actual result

Go to backend Sales-Orders and check Bill-to Name and Ship-to Name. Both names trancated to 20 characters!

@olysenko
Copy link

Hi, thank you for your report. Internal ticket MAGETWO-61553 was created

@olysenko olysenko added Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development develop labels Nov 29, 2016
@heldchen
Copy link
Contributor

heldchen commented Feb 22, 2017

any progress on this? got a complaint today from a customer. it is not only affecting the backend, but also the transaction mails and our order export to the erp

@heldchen
Copy link
Contributor

the reason for the truncating is that the mysql field definitions for quote_address do not match their counterparts in sales_order_address... and it's not just the firstname & lastname fields! sales_order_address has mostly 255 chars length set, whereas quote_address uses some rather short lengths for several important address fields for no particular reasons...

SolsWebdesign added a commit to SolsWebdesign/magento2 that referenced this issue May 16, 2017
Bill-to Name and Ship-to Name trancated to 20 characters in backend
Compared the lengths of firstname, middlename and lastname of table "quote_address" with those of "quote" (255, 40 and 255 resp.) and of "sales_order_address" (255, 255 and 255) and with sales_order (128, 128 and 128) and choose to go with 255, 40 and 255 since these are used in "quote" as well and these are the values I know from Magento 1.9 as well. The other values are a bit inconsistent. Tested.
SolsWebdesign added a commit to SolsWebdesign/magento2 that referenced this issue May 22, 2017
Bill-to Name and Ship-to Name trancated to 20 characters in backend
Compared the lengths of firstname, middlename and lastname of table "quote_address" with those of "quote" (255, 40 and 255 resp.) and of "sales_order_address" (255, 255 and 255) and with sales_order (128, 128 and 128) and choose to go with 255, 40 and 255 since these are used in "quote" as well and these are the values I know from Magento 1.9 as well. The other values are a bit inconsistent. Tested. Updated setup version of the Quote module to 2.0.5, moved all updates into a single if statement.
@ishakhsuvarov
Copy link
Contributor

Closing, as issue is fixed in the develop branch with the linked PR and commits.

@ishakhsuvarov
Copy link
Contributor

Reopening, as fix for 2.1 is not available yet.

@ishakhsuvarov ishakhsuvarov reopened this May 29, 2017
@veloraven
Copy link
Contributor

I'm closing this issue as it was fixed in develop and there are no plans to fix it in ver. 2.1 or 2.0 for now.

@korostii
Copy link
Contributor

korostii commented Jun 20, 2017

Hi @veloraven,

I'm closing this issue as it was fixed in develop and there are no plans to fix it in ver. 2.1 or 2.0 for now.

That sounds as if 2.1 and 2.0 branches are effectively abandoned and will only receive security fixes in the future.

Can you confirm that starting from now there will is no support period for 2.1 planned whatsoever, despite the fact that 2.2 isn't even out yet?
That would also mean that the most modern branch safe for production use is... 1.9.x (as all the others either don't receive all the necessary fixes or weren't released yet). Not sure if that's funny or sad.

@yumicom
Copy link
Author

yumicom commented Jun 20, 2017

I've been expecting a stable version of Magento 2 for more than a year (((

@lazyguru
Copy link
Contributor

@veloraven I'm curious as to why this is not being back-ported. Both 2.0 and 2.1 are still inside their support windows for bug fixes. This is a bug fix. Seems only logical that it should apply.

@ishakhsuvarov
Copy link
Contributor

@lazyguru @korostii Reopening again, since there is still no released version where the fix is available.

Currently all the capacity of Magento teams working on 2.1 is busy with items of higher priority, so we can not provide information regarding the ETA for this fix.
Please feel free to submit a Pull Request with the backport or upvote this issue to raise it's priority.

Thank you for collaboration

@ishakhsuvarov ishakhsuvarov reopened this Jun 21, 2017
@korostii
Copy link
Contributor

Hi @ishakhsuvarov, thanks a lot for reopening the issue and for your informative response!

@lazyguru
Copy link
Contributor

Thanks @ishakhsuvarov! I think it is more than fair to ask for community to PR or be patient until you guys get to it.

@lazyguru
Copy link
Contributor

I have submitted a PR for backporting this to 2.1. I've started working on the 2.0 backport but it is complicated by an index update that happened in another commit. I'm trying to track down where that happened to see what the best way to approach this might be. However, since 2.0 is EOL in November, it may not be as relevant to backport this fix to it? (not sure if there is demand for it)

@okorshenko
Copy link
Contributor

Hi @lazyguru
Your point is valid for 2.0. We are not processing PRs to 2.0 branch due to EOL.
Thank you for PR to 2.1. I will take it

@okorshenko
Copy link
Contributor

Let me clarify, 2.0 is still supported. But it will be EOL according to the schedule in November

@magento-team magento-team added Release Line: 2.1 Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development bug report Component: Checkout develop labels Jul 31, 2017
@magento-team
Copy link
Contributor

Internal ticket to track issue progress: MAGETWO-69230

@magento-team
Copy link
Contributor

Internal ticket to track issue progress: MAGETWO-70077

@magento-engcom-team magento-engcom-team added Release Line: 2.1 2.1.x Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development bug report Component: Checkout Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed Fixed in 2.1.x The issue has been fixed in 2.1 release line Fixed in 2.2.x The issue has been fixed in 2.2 release line labels Sep 11, 2017
@korostii
Copy link
Contributor

Hi @magento-engcom-team,

I think something went wrong here. It's a bit strange seeing both acknowledged and G1 Failed on the same issue. Could you please double-check this when you have some spare time? It would be a pity to have some valid issues dismissed by accident.

Thanks in advance.

@orlangur
Copy link
Contributor

@korostii acknowledged is from

olysenko added acknowledged develop labels on Nov 29, 2016

while G1 Failed is added automatically. I really doubt every comment like your one https://github.com/magento/magento2/labels/G1%20Failed may be replied :)

Basically, this issue seems to be fixed in latest 2.1.x even though the bug report was not formatted well.

@korostii
Copy link
Contributor

G1 Failed is added automatically
Yes, I know that.

Let me rephrase my point: Gate1 is buggy and it shouldn't even touch the issues which are already acknowledged. (I'm not saying this exact issue needs attention, I'm saying the code performing G1 needs to be adjusted)
No need to check formatting if we already agree that this is (or was, in this case) a valid issue.

This exact issue is lucky to be fixed already, but it would be most unfortunate to get some other acknowledged issue like it filter out for the same reason.

@orlangur
Copy link
Contributor

@korostii ok, got your point now. I didn't check the workflow changes details yet, but to me it looks like acknowledged was not managed properly and could be ignored now, all existing issues will be simply rechecked and retriaged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Component: Checkout Fixed in 2.1.x The issue has been fixed in 2.1 release line Fixed in 2.2.x The issue has been fixed in 2.2 release line Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Release Line: 2.1
Projects
None yet
Development

No branches or pull requests