-
-
Notifications
You must be signed in to change notification settings - Fork 585
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
Allow to hide zero tax rows via plugin #3484
Allow to hide zero tax rows via plugin #3484
Conversation
… no tax is charged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @LiaraAlis 👍
I found many small things that I would like to smooth out, mostly block names which should be consistent between export and invoice templates.
My review is only for the first template, can you adapt the other ones accordingly with the same changes (search and replace should work if you used the same names).
Should we also add a empty |
@kevinpapst Can you please check my comments above? After that I can complete your change requests. 😁 |
You know what, I am a little afraid of the merge problems that will show pushen merging this PR. I see three options how to move forward:
I know this is annoying, but I try to keep the changes as small as possible currently to avoid further merge issues. |
I totally understand this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I really love your input in the PRs and hate being a pain in the ass... but I have to reject this for now. Can you re-target the changes to #2902 instead and ONLY apply the minimum necessary changes here.
I am fine with the blocks for the tax = 0 change, but everything else doesn't feel right.
The problem are the pretty generic block names which might to layout issues in existing templates. I searched through the library of my customers templates and found some duplicates already eg block items
.
I simply cannot guarantee that these new blocks will not lead to some weird BC breaks, which should be avoided at all cost.
So my proposal:
- target the v2 branch (the three comments are for it)
- add only the tax=0 change only in this PR
<!--mpdf | ||
{% block pdf_footer %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be reverted.
If someone used this block (for some weird reason) to render HTML instead of mpdf tags, then this change will break their templates. Also (just a personal preference) I think it is better to create self-containing blocks.
And I am not sure what happens if someone has overwritten these blocks and then they end up with two opening mpdf tags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What exactly do you mean with "self-containing blocks"?
{% endblock %} | ||
mpdf--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above
</head> | ||
<body> | ||
<!--mpdf | ||
{% block pdf_header %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we do the same here and create self-contained blocks with the start/end mpdf tag starting inside the block.
I go with you. But I suggest that we go back to the start and think carefully about the topic how the templates in v2 could be structured to make it consistent across all invoice and export templates. For this, to make my plugin better, I need a change for the subtotal and VAT row and also a block before the payment terms. Can we do this? And a off topic question: |
👍 Yes, sure. I am fine with the tax related changes. And agree with everything else. More eyes and brains that work together usually end in a better result. |
@kevinpapst I've updated the PR and reverted all the changes that added blocks. So only the change about the tax is left. |
Yes please 👍 I tried to get proper information online but I could only find out that you can add a Honestly: no company ever complained, so I kinda think that this row is no trouble for VAT registered companies. This PR is a never ending story, I am sorry about that! But it is a sensitive topic... We should probably add a method I will look at it later and send an update. |
#3510 😁
You have not to sorry about that. You are right, I also thought about this and searched. But I cannot find anything about this.
I like the idea. I think this way is the best to lower the risk. |
I've added the property to the (already tested locally with my plugin) |
Codecov Report
@@ Coverage Diff @@
## master #3484 +/- ##
============================================
- Coverage 91.77% 91.76% -0.02%
- Complexity 7878 7880 +2
============================================
Files 742 742
Lines 23760 23764 +4
============================================
Hits 21806 21806
- Misses 1954 1958 +4
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was a long journey, but I like where it brought us 😄
Thank you @LiaraAlis 👍
Description
This PR adds some twig blocks in the invoice templates. Additionally it hides subtotal and tax rows in the table when no tax is used.
For more information see original PR: #3480
Types of changes
Checklist
composer code-check
)