TYPO3 Core

Can confirm this error in TYPO3 9.5.7 and EXT:news

The same error here with a custom extension that should be able to show hidden records under some special cirucmstances.

As a workaround I created a custom AliasMapper

<?php
declare(strict_types = 1);

namespace Hirnschmalz\Custom\Routing\Aspect;

/*
 * This file is part of the TYPO3 CMS project.
 *
 * It is free software; you can redistribute it and/or modify it under
 * the terms of the GNU General Public License, either version 2
 * of the License, or any later version.
 *
 * For the full copyright and license information, please read the
 * LICENSE.txt file that was distributed with this source code.
 *
 * The TYPO3 project - inspiring people to share!
 */

use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Database\Query\QueryBuilder;
use TYPO3\CMS\Core\Database\Query\Restriction\DeletedRestriction;
use TYPO3\CMS\Core\Routing\Aspect\PersistedAliasMapper;
use TYPO3\CMS\Core\Routing\Aspect\PersistenceDelegate;
use TYPO3\CMS\Core\Site\SiteLanguageAwareTrait;
use TYPO3\CMS\Core\Utility\GeneralUtility;

class DesPersistedAliasMapper extends PersistedAliasMapper
{
    use SiteLanguageAwareTrait;

    /**
     * @var bool
     */
    protected $ignoreEnablefields;

    /**
     * @param array $settings
     * @throws \InvalidArgumentException
     */
    public function __construct(array $settings)
    {
        parent::__construct($settings);
        $ignoreEnablefields = $settings['ignoreEnablefields'] ?? false;
        $this->ignoreEnablefields = $ignoreEnablefields;
    }

    /**
     * @return PersistenceDelegate
     */
    protected function getPersistenceDelegate(): PersistenceDelegate
    {
        if ($this->persistenceDelegate !== null) {
            return $this->persistenceDelegate;
        }
        $queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
            ->getQueryBuilderForTable($this->tableName)
            ->from($this->tableName);

        if ($this->ignoreEnablefields) {
            $queryBuilder
                ->getRestrictions()
                ->removeAll()
                ->add(GeneralUtility::makeInstance(DeletedRestriction::class));
        }

        $resolveModifier = function (QueryBuilder $queryBuilder, array $values) {
            return $queryBuilder->select(...$this->persistenceFieldNames)->where(
                ...$this->createFieldConstraints($queryBuilder, $values)
            );
        };
        $generateModifier = function (QueryBuilder $queryBuilder, array $values) {
            return $queryBuilder->select(...$this->persistenceFieldNames)->where(
                ...$this->createFieldConstraints($queryBuilder, $values)
            );
        };

        return $this->persistenceDelegate = new PersistenceDelegate(
            $queryBuilder,
            $resolveModifier,
            $generateModifier
        );
    }
}

Now it's possible to do something like

    aspects:
      custom_title:
        type: HirnschmalzPersistedAliasMapper
        tableName: tx_custom_domain_model_test
        routeFieldName: path_segment
        routeValuePrefix: ''
        ignoreEnablefields: true

1st attempt to solve with #88307

This is still a problem in 9.5.20

I can confirm this is still an issue in TYPO3 v10.4.12 for records as well as pages.

Hidden records and pages aren't the issue if they are hidden by using the `hidden` field. However, if the record is hidden because of a future start date, the editor is being send to the rootpage with the `ADMCMD_simTime=` parameter from within the pages and list modules if using the buttons in the docheader (both the view button from within the properties view as well as the view button in the page view), in the languages view for each translation or a list item. If the editor uses the context menu from within the pagetree, they are being send to the correct url and with the `ADMCMD_simTime=` parameter, however they end up at an error page (404 or 403 for example).

As a nasty workaround, the editors can remove the starttime and set the page to be hidden to be able to preview its content while still editing. If they are ready and satisfied with the result, they can set back the starttime and set the page to be visible so the page is enabled at the right time. However this is not a working solution, because if they have to make some more adjustments later on they have to repeat those steps again.

Additional information:
Where the view page module in TYPO3 v9 was working as a workaround too, the view page module in v10 has the same issues as using the docheader buttons and list module where te user is being send to the homepage.