User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Change the value of column field_mappings
of the record for com_users in table #__content_types
from '"core_created_time":"registerdate"' to '"core_created_time":"registerDate"' so the camel case of the register date columns fits to the name of that columns in table #_users
, like is is already correct for column lastvisitDate
.
Can be merged on review.
@wilsonge I've made 2 commits, one for joomla.sql for new installations and one for the update sql script, so in case if you think the update statement is too risky and we should leave updated installations alone, just cherry pick the first commit for the new installations. But I don't really see a risk in the update sql.
Status | New | ⇒ | Pending |
Category | ⇒ | SQL Administration com_admin Postgresql Installation |
Labels |
Added:
?
|
@wilsonge @alikon The update with replace statement in the update sql script is safe because the search string "core_created_time":"registerdate"
covers the complete parameter name value pair including all double quotes at beginning and end, so partial strings will not match, which was the problem in past issues with such statements.
I have tested this item
@punambaravkar Could you report back how you have tested this PR? It does not make sense to test it with patchtester because it contains sql changes only. You have to run the SQL statements in file administrator/components/com_admin/sql/updates/mysql/4.0.0-2019-10-13.sql
in PhpMyAdmin or file administrator/components/com_admin/sql/updates/postgresql/4.0.0-2019-10-13.sql
in PhpPgAdmin, depending on which kind of database you use.
@punambaravkar Please read my previous comment and either change back your test result to "I have not tested this item" in the issue tracker, or test it in the right way. And in general leaving a negative test result without giving any information what has failed is not ok.
I'm happy with this. But @alikon i'd like you to do a secondary review on the update statement as
punishmentsomeone who's done this before and knows the risk
@alikon please do review as George required in his comment above. Execute the SQL statement in the update sql script created by this PR on a J4 installation and then check in PhpWhateverYourDbTypeIsAdmin in table #__content_types
that all is like before except of the thing changed with the statement.
review done and update query tested, all good for what i can see
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-10-25 22:53:43 |
Closed_By | ⇒ | wilsonge | |
Labels |
Added:
?
|
Thanks!
I'm happy with this. But @alikon i'd like you to do a secondary review on the update statement as
punishmentsomeone who's done this before and knows the risk