?
avatar ReLater
ReLater
18 Mar 2020

Reported by user alexanderbrix on https://forum.joomla.de/thread/11394-beiträge-veröffentlichung-starten-erhöht-sich-automatisch-bei-kategoriewechsel/ (Joomla 3.9.16)

and i can confirm the issue. User anka in forum, too.

Steps to reproduce the issue

  • Current nightly 3.9.17-dev

  • Global Joomla Configuration: Set "Website Time Zone": "Berlin"

  • Important addition (thanks to anka for further investigations): Create a custom field for articles. Only then the edit form of articles will be reloaded after category change.

  • Open an article. Note the date fields and fill not filled ones:

18-03-_2020_12-42-03

  • Chenge the category of the article in "Category" field
  • Check time fields again. At least 1 hour higher, "Finish Publishing" by 2 hours (whyever).

18-03-_2020_12-43-22

  • With any category change: time +1h.
  • Field "Finish Publishing" was empty before test. I filled it. That's the one that has a +2h value after category change.
  • No reset to correct time values when article saved finally.
avatar ReLater ReLater - open - 18 Mar 2020
avatar joomla-cms-bot joomla-cms-bot - change - 18 Mar 2020
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 18 Mar 2020
avatar ReLater ReLater - change - 18 Mar 2020
The description was changed
avatar ReLater ReLater - edited - 18 Mar 2020
avatar ReLater ReLater - change - 18 Mar 2020
Title
[3] Date fields in article change on each category Change
[3] Date fields in article change on each category change
avatar ReLater ReLater - edited - 18 Mar 2020
avatar ReLater ReLater - change - 18 Mar 2020
The description was changed
avatar ReLater ReLater - edited - 18 Mar 2020
avatar ReLater ReLater - change - 18 Mar 2020
The description was changed
avatar ReLater ReLater - edited - 18 Mar 2020
avatar ReLater
ReLater - comment - 18 Mar 2020
Setting Value
 
PHP Built On Linux dd46134 4.15.0-76-generic #86~16.04.1-Ubuntu SMP Mon Jan 20 11:02:50 UTC 2020 x86_64
Database Type mysql
Database Version 5.7.28-nmm1-log
Database Collation utf8_general_ci
Database Connection Collation utf8mb4_general_ci
PHP Version 7.2.24-nmm1 and 7.4.2
Web Server Apache
WebServer to PHP Interface fpm-fcgi
Joomla! Version Joomla! 3.9.17-dev Development [ Amani ] 10-March-2020 15:28 GMT
Joomla! Platform Version Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
avatar SharkyKZ
SharkyKZ - comment - 18 Mar 2020

Side effect of #28103. Although same issue exists when saving fails.

avatar ReLater
ReLater - comment - 18 Mar 2020

Release blocker for 3.9.17? Just asking...

avatar HLeithner
HLeithner - comment - 18 Mar 2020

Should be fixed before 3.9.17 @SharkyKZ are you able to fix this?

avatar jwaisner jwaisner - change - 18 Mar 2020
Status New Confirmed
avatar jwaisner jwaisner - change - 18 Mar 2020
Labels Added: ?
avatar jwaisner jwaisner - labeled - 18 Mar 2020
avatar jwaisner jwaisner - change - 18 Mar 2020
Priority Medium Urgent
avatar jwaisner
jwaisner - comment - 18 Mar 2020

Increasing priority as this will block the upcoming release of 3.9.17


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/28386.

avatar ReLater
ReLater - comment - 18 Mar 2020
avatar ReLater ReLater - change - 18 Mar 2020
The description was changed
avatar ReLater ReLater - edited - 18 Mar 2020
avatar ReLater ReLater - change - 18 Mar 2020
The description was changed
avatar ReLater ReLater - edited - 18 Mar 2020
avatar SharkyKZ
SharkyKZ - comment - 18 Mar 2020

Not sure what to do here. The same issue occurs when form validation fails. We store unfiltered data to user state in such case so I don't think #28103 is necessarily wrong. Then again we store validated data when saving in model fails, so issues like #27919 (for which #28103 was made) pop up again.

avatar richard67
richard67 - comment - 18 Mar 2020

Maybe you should store half filtered and half unfiltered data ;-) (joking)

avatar HLeithner
HLeithner - comment - 18 Mar 2020

Is filtering the problem or the missing fields removed by the filter?
When the fields are missing we could add them again after the filter? (I know sounds awful...)

avatar ReLater
ReLater - comment - 19 Mar 2020

Just BTW: I wonder why the "Finish Publishing" is increasing by 2 hours while the other date fields just by 1 hour.

avatar ReLater ReLater - change - 19 Mar 2020
The description was changed
avatar ReLater ReLater - edited - 19 Mar 2020
avatar SharkyKZ
SharkyKZ - comment - 19 Mar 2020

Calendar field also changes value client-side sometimes.

avatar ReLater
ReLater - comment - 19 Mar 2020

Is it possible somehow to suppress the onChange event or whatever is fired by JS after reload?

avatar SharkyKZ
SharkyKZ - comment - 20 Mar 2020

Is it possible somehow to suppress the onChange event or whatever is fired by JS after reload?

I don't think JS does that on reload, only when date is first entered. But I could be wrong. Maybe someone more familiar with Calendar field knows.

Maybe it would be possible for the field to manipulate displayed value in JS but submit unaltered date.

When the fields are missing we could add them again after the filter? (I know sounds awful...)

This does sound awful. But it could work.

avatar ReLater
ReLater - comment - 20 Mar 2020

I changed a calendar field to a text field in XML and tested. The date inside the text field stays untouched after reload. Don't know if that helps anyhow... just poking...

avatar HLeithner
HLeithner - comment - 21 Mar 2020

Do we find a solution here? If not i would revert the PR til we find a solution.

avatar SharkyKZ
SharkyKZ - comment - 21 Mar 2020

No solution yet.

avatar joomdonation
joomdonation - comment - 22 Mar 2020

Just for information, the issue happens here because Calendar field type works in a different way compare to other form field types.

  • We store data in database for calendar form fields in UTC timezone.
  • When the item is edited, Joomla converts that Date Time value from UTC timezone to user timezone.
  • When the form is re-loaded, that changed value is in user timezone already, but the Calendar form field still assumes that that value is in UTC timezone, and it converts to user timezone again, thus the value changes.

So this affects every calendar fields in the form.

avatar joomdonation
joomdonation - comment - 22 Mar 2020

So the solution here is get filtered data for calendar fields only and get these filtered values back to $data array. It works, but I'm unsure if it's acceptable. Below is the propose code for reload method:

public function reload($key = null, $urlVar = null)
{
	// Check for request forgeries.
	$this->checkToken();

	$app = \JFactory::getApplication();

	$model = $this->getModel();
	$data  = $this->input->post->get('jform', [], 'array');

	// Determine the name of the primary key for the data.
	if (empty($key))
	{
		$key = $model->getTable()->getKeyName();
	}

	// To avoid data collisions the urlVar may be different from the primary key.
	if (empty($urlVar))
	{
		$urlVar = $key;
	}

	$recordId = $this->input->getInt($urlVar);

	// Populate the row id from the session.
	$data[$key] = $recordId;

	// Check if it is allowed to edit or create the data
	if (($recordId && !$this->allowEdit($data, $key)) || (!$recordId && !$this->allowAdd($data)))
	{
		$this->setRedirect(
			\JRoute::_(
				'index.php?option=' . $this->option . '&view=' . $this->view_list
				. $this->getRedirectToListAppend(), false
			)
		);
		$this->redirect();
	}

	// The redirect url
	$redirectUrl = \JRoute::_(
		'index.php?option=' . $this->option . '&view=' . $this->view_item .
		$this->getRedirectToItemAppend($recordId, $urlVar),
		false
	);

	/* @var \JForm $form */
	$form = $model->getForm($data, false);

	/* Get filtered data for calendar fields and set it back to posted data */
	$filteredData = $form->filter($data);

	foreach ($form->getFieldset() as $field)
	{
		if ($field->type === 'Calendar')
		{
			$fieldName = $field->fieldname;

			if (isset($filteredData[$fieldName]))
			{
				$data[$fieldName] = $filteredData[$fieldName];
			}
		}
	}

	// Save the data in the session.
	$app->setUserState($this->option . '.edit.' . $this->context . '.data', $data);

	$this->setRedirect($redirectUrl);
	$this->redirect();
}
avatar HLeithner
HLeithner - comment - 27 Mar 2020

It's not a complete workaround, I think searching for the filter server_utc and user_utc would be better.

the other way would be to fill only fields with "unset" filter, this would be a more generic approach.

Any opinions at this @SharkyKZ @joomdonation @ReLater and anyone else ;-)

avatar joomdonation
joomdonation - comment - 28 Mar 2020

@HLeithner I think we do not need to searching for the filter server_utc and user_utc. From what I see, Calendar is the only field type changed the passed value to it before displaying (a special behavior), so that's the only field type need to have the filter applied he.

avatar HLeithner
HLeithner - comment - 28 Mar 2020

@joomdonation that's maybe true for core but maybe not for 3rd party component, so I think searching for the unset filter would be better

avatar SharkyKZ
SharkyKZ - comment - 28 Mar 2020

Not a fan of the above solution or anything that checks specific field/filter types. The controller shouldn't even be touching the form directly, it should be using model's methods.

I deal solution would be to stop calendar field from altering the value like that, but not sure this can be done in a B/C safe way.

avatar HLeithner
HLeithner - comment - 28 Mar 2020

Our calendar has some hacks but validation before saving would make sense anyway and if our only problem is that "unset" filtered fields are missing we should exclude them from getting dropped.

If we can solve this problem with javascript by setting the time correctly I would be happy too.

avatar HLeithner
HLeithner - comment - 7 Apr 2020

Closing we have a PR #28596

avatar HLeithner HLeithner - change - 7 Apr 2020
Status Confirmed Closed
Closed_Date 0000-00-00 00:00:00 2020-04-07 13:28:30
Closed_By HLeithner
avatar HLeithner HLeithner - close - 7 Apr 2020
avatar wilsonge wilsonge - change - 18 Dec 2020
Labels Removed: ?
avatar wilsonge wilsonge - unlabeled - 18 Dec 2020

Add a Comment

Login with GitHub to post a comment