@alikon @imanickam

Same exists in administrator/components/com_fields/models/forms/field.xml. You may want to extend you PR with this file.

It seems to be those fields which are readonly. However I don't see why they should be readonly to start with. other similar fields (eg for an article) are fully editable. Maybe we can do that consistent at the same time?

Good idea. Evidently Modified date should remain readonly, but we could indeed change the created date to be active.

I found out though that we may have a general bug here. Tested on article:
A Created date can be set in the future, and therefore appear as created AFTER the modified date...

I can solve this bug by preventing save and set an error in that case all over core.
Something like (for contacts):

		if ($data['modified'] < $data['created'])
		{
			$this->setError(JText::_('JERROR_CREATED'));

			return false;
		}

in the save($data) method.
may be a bit different depending on components.

What do you think?

I certainly wouldn't do that in the same PR as it is quite unrelated.

A Created date can be set in the future, and therefore appear as created AFTER the modified date...

I don't consider this an issue. If in 4.0 it wants to be redefined that the create date is the time an item is first saved in a site and made readonly then so be it. Otherwise I quite commonly set my create and publish times to the same thing, which will most often be in the future of the modified date; off hand I don't know where the create time is actually exposed in the frontend but I feel like making it a readonly field in a patch release has bad idea written all over it.

Created Date IS used both in backend and frontend for articles.
Backend:

Frontend:

In the mean while, I corrected the readonly for Created time and added similar modifications in field.xml

@infograf768 can you plz upgrade the PR

@HLeithner
As usual I merged again

thx