[#26745] - [4.0] Set modified by user to created by user for new items
- Fixed in Code Base
- 2 Nov 2019
- Medium
- Build: 4.0-dev
- # 26745
- Diff
- richard67:4.0-dev-set-modified-by-if-created-null-date
- Pending Hound Hound is busy sniffing around... Details
User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Summary of Changes
With the changes for datime database columns recently merged, the handling of modified times was made consistent everywhere so that if something has never been modified, the modified time is equal to the created time (with 1 exception: template overrides, where null for modified time is used to indicate that a component for which an override has been made has meanwhile been uninstalled).
This PR here does the same for the modified by user id, so that at the end if something has never been modified, the modified user id is equal to the created user id.
Together with the first change, the handling is then equal to what filesystems do with files and folder.
Finally, the installer is corrected so it changes the user ID's from hard-coded default to random one also for the workflows.
Testing Instructions
If you have both MySQL and PostgreSQL, please test on both if possible.
Test 1: New installation
- Have a new installation of the 4.0-dev branch or a 4.0-Alpha-12.
- Login to backend and switch error reporting to "Maximum" or "Development" in Global Config - Server settings.
- Create each one new item of following types and don't modify it after having saved it for the first time:
- banner
- category
- article
- contact
- field group
- field
- finder filter
- newsfeed
- tag
- user note
- workflow
- Check modification times and modified by users in the edit views of the particular items or in database using appropriate tools, and check creator user id and modified by user id for the default workflow.
Result: See section "Actual result" for 4.0 below.
- Apply the patch of this PR. Attention: It happened to me that the patchtester timed out, so not all changes were applied. To be safe, download the zip of this branch and copy the changed files manually to your J4. If you want to save this work: Download a modified nightly build from the following link which includes this PR https://test5.richard-fath.de/Joomla_4.0.0-beta1-dev-Development-Full_Package_2019-10-21_pr-26745.zip, clear your Joomla folder so it is empty, delete all database tables, unzip the download into the Joomla folder and then perform a new installation. Then skip the next step 6 and continue with 7.
- Delete file
configuration.phpin your Joomla root folder, and delete all Joomla database tables in PhpMyAdmin or PhpPgAdmin (depending on your database type). - Repeat steps 1 to 4 above.
Result: See section "Expected result" below.
Test 2: Update of a 3.9.12 or staging.
- Have a new installation of the staging branch or 3.9.12.
- Login to backend and switch error reporting to "Maximum" or "Development" in Global Config - Server settings.
- Create each one new item of following types and don't modify it after having saved it for the first time:
- banner
- category
- article
- contact
- field group
- field
- finder filter
- newsfeed
- tag
- user note
- Check modification times and modified by users in the edit views of the particular items or in database using appropriate tools.
Result: See section "Actual result" for 3.x below.
- Update to a patched nightly build which is equal to current 4.0-dev plus the changes in this PR using the "Upload & Update" tab of the Joomla Update component and the update container previously downloaded from following URL: https://test5.richard-fath.de/Joomla_4.0.0-beta1-dev-Development-Update_Package_2019-10-21_pr-26745.zip
- Check again modification times and modified by users in the edit views of the particular items or in database using appropriate tools.
Result: See section "Expected result" below.
Expected result
On 4.0 after patch (new installed and updated): For items which never have been modified, the time of last modification is equal to the time of creation, and the user who has modified it as last is equal to the user who created it.
After new installation, the default workflow has the right creator user id and modified by user id of the super user.
Actual result
On 4.0 before patch: For items which never have been modified, the time of last modification is equal to the time of creation, but the id of the user who has modified it as last is zero, i.e. the modified by user field is empty in the edit view.
On 3.x or staging before patch: For items which never have been modified, the time of last modification is equal to the (pseudo-)nulldatetime of the database type, and the id of the user who has modified it as last is zero, i.e. the modified by user field is empty in the edit view.
Documentation Changes Required
None.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | SQL Administration com_admin Postgresql com_banners com_contact com_fields com_finder com_newsfeeds com_tags com_users com_workflow Installation |
| Labels |
Added:
?
|
||
| Title |
|
||||||
Please wait with testing, I found some small mistake. For category, modified_user_id is still zero. Same for article and contact, modified_by is zero for a new item. All other item types listed above seem to be ok.
PR is ready for test.
Important hint for testers: It happened to me that the (old) patchtester timed out, so not all changes have been applied. So maybe it is better to download the zip of the complete branch here and copy the files manually into your testing environment for the 1st test with new installation of J4.
Sorry I am confused here. If an item has never been modified why are we setting a value. It seems wrong to me.
@brianteeman Was agreed with George to do it this way. For the modified times and user ids it has already been done at several places in PHP in the table classes in check and/or store functions. For the modified times we then have done this in sql scripts with the recently merged PRs for the nulldates, but to do the same with the modified user IDs has been forgotten. This PR here just adds that. At the end behavior is consistent everywhere and is same as filesystems handle modification times and users for files and folders.
I know this will not convince you, it shall only be an explanation for the reasons behind it.
@brianteeman P.S.: And you are not alone with your opinion, Sharky or Harald would agree with you, I think, and surely more people. I did not want to decide on that and would have done it the one or the other way and was ok with both and so left the decision to George at the end.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/26745.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/26745.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/26745.
@SharayuYadav @ttplpoojak Sure you've tested as described in the testing instructions, i.e. after having applied the patch with patchtester, removed configuration.php and deleted database tables and then made a new installation? If so, please report back at which step what went wrong. Otherwise, if you have tested in the wrong way, please change back your testing result in the issue tracker to "I have not tested this item", and if time test again in the right way.
| Category | SQL Administration com_admin Postgresql com_banners com_contact com_fields com_finder com_newsfeeds com_tags com_users com_workflow Installation | ⇒ | SQL Administration com_admin Postgresql com_banners com_contact com_fields com_finder com_newsfeeds com_tags com_users com_workflow Installation Libraries |
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-11-02 22:33:18 |
| Closed_By | ⇒ | wilsonge |
Thanks!
Thanks too.
@wilsonge Please review. Thanks in advance.