Bug #53975

BeLog: Exception when time input fields are empty

Added by Ernesto Baschny almost 6 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Logging
Target version:
Start date:
2013-11-26
Due date:
% Done:

100%

TYPO3 Version:
6.0
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

If you go to "Info>Log" or "Admin>Log" and select "Userdefined" time range and then leave one of the input fields (start or stop) empty and click "Set", you end up with this exception:

Exception while property mapping at property path "":PHP Catchable Fatal Error: Argument 1 passed to TYPO3\CMS\Belog\Domain\Model\Constraint::setManualDateStop() must be an instance of DateTime, null given, called in .../html/typo3_src/typo3/sysext/extbase/Classes/Reflection/ObjectAccess.php on line 215 and defined in .../html/typo3_src/typo3/sysext/belog/Classes/Domain/Model/Constraint.php line 273

When you are in this situation and go to the module again, even changing the Time Select Box to "Undefined" you still get this error (probably because the empty input fields are hidden but submitted again).

And empty input field in start/stop should remove this specific limit.

Associated revisions

Revision beb80664 (diff)
Added by Steffen Müller almost 6 years ago

[BUGFIX] Allow empty values in start/stop filter of belog

One can limit records in the backend log module to a custom period
of time using the "User defined" mode and a start and stop field.

Leaving these fields empty is now supported in the corresponding
domain model setters by adding default values to the DateTime
arguments.

Resolves: #53975
Releases: 6.1, 6.2
Change-Id: I944322bb3747a29fab33c3d32e17dd070c7cb6db
Reviewed-on: https://review.typo3.org/26723
Reviewed-by: Markus Klein
Tested-by: Markus Klein
Reviewed-by: Wouter Wolters
Tested-by: Wouter Wolters

Revision 2620cb5a (diff)
Added by Steffen Müller almost 6 years ago

[BUGFIX] Allow empty values in start/stop filter of belog

One can limit records in the backend log module to a custom period
of time using the "User defined" mode and a start and stop field.

Leaving these fields empty is now supported in the corresponding
domain model setters by adding default values to the DateTime
arguments.

Resolves: #53975
Releases: 6.1, 6.2
Change-Id: I944322bb3747a29fab33c3d32e17dd070c7cb6db
Reviewed-on: https://review.typo3.org/26728
Reviewed-by: Steffen Müller
Tested-by: Steffen Müller

History

#1 Updated by Steffen Müller almost 6 years ago

This could be solved by adding NULL as a default value for the DateTime argument.

#2 Updated by Gerrit Code Review almost 6 years ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26723

#3 Updated by Steffen Müller almost 6 years ago

@Ernesto Why did you set "TYPO3 Version" to 6.0 for this issue? 6.2 + 6.1 is also affected and 6.0 has reached EOL.

#4 Updated by Gerrit Code Review almost 6 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26723

#5 Updated by Gerrit Code Review almost 6 years ago

Patch set 1 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26728

#6 Updated by Steffen Müller almost 6 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#7 Updated by Ernesto Baschny almost 6 years ago

Thanks a lot for fixing that!

@Steffen, the "TYPO3 Version" is the lowest version where this issue appears. Important to know when thinking about which releases to consider backporting.

Of course the backport itself should consider the backporting rules that are in place at the time the fix is merged into master (which can be years later the report was made...).

Since this applies not only to 6.2, target version was set to "next-patchlevel", whichever this will be at the time the fix was created.

#8 Updated by Benni Mack about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF