Bugfix/issue 1477 #1492
Closed
Bugfix/issue 1477 #1492
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ng codes (similar to getCode() but does not generate codes). This does not change behavior at all.
…code already exists for the given day, item, timeframe and location
…rame and location reference. seems to make things easier?
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1492 +/- ##
============================================
- Coverage 41.37% 41.16% -0.22%
+ Complexity 2330 2315 -15
============================================
Files 91 91
Lines 9616 9547 -69
============================================
- Hits 3979 3930 -49
+ Misses 5637 5617 -20 ☔ View full report in Codecov by Sentry. |
…eGenerationDays parameter (the default is currently 365). Set it explicitly to self::ADVANCE_GENERATION_DAYS (like every else in these test units) which is currently 30. Before this change, the codes were generated for 365 days such that the following test would NOT trigger generation of new codes.
…s, rather than try to determine if it is necessary. This makes getLastCodeDate() (formerly known as getLastCode()) unneeded.
…s (ie 365) starting from TODAY (like comment suggests) rather than from beginning of timeframe, which could potentially be years back
…Period does not include end date by default)
…his is why DateInterval loop returned a day too much)
…world problems to be off by one here) because the timeframe begins yesterday, not today.
…ond parameter must be startDate as timestamp, not ADVANCE_GENERATION_DAYS. This correction should not change behavior, because the wrong parameter was treated just like a call with one parameter and defaults for the last three.
… value of 0 will generate a code for the reference day $date, just like getCodes() and generate(). This slight behavior change is just to make code consistent, clearer and easier to understand. It was not a bug, but a small inconsistency, and it is not covered by the tests. Since getCode() was never called with $advanceGenerationDays=0, the change will not be noticed in real world.
… render CSV) such that $advance_generation_days takes TODAY as reference instead of timeframe start which could be YEARS ago. Before this change, getCodes() without enddate would not return a code for today, when 'today' is much later than than timeframe start.
|
Zu viel hin und her hier. Siehe stattdessen #1497 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ich wollte ursprünglich nur Issue 1477 (BookingCodes können mehrfach je Datum generiert werden) lösen, bin dann auf ein weiteres Problem gestoßen. Das lies sich am Einfachsten lösen, indem die den Bezug der BookingCodes auf timeframeId und LocationId auflöst habe. Für mich ist das noch Work in Progress, ich muss noch testen und schauen, ob alles sauber ist.