User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Fix empty parameter for mail template.
'{"tags": ["task_id", "task_title", ""]}'
.'{"tags": ["task_id", "task_title"]}'
.None.
Status | New | ⇒ | Pending |
Category | ⇒ | SQL Administration com_admin |
Labels |
Added:
?
|
Category | SQL Administration com_admin | ⇒ | SQL Administration com_admin Postgresql |
What shall this PR fix? For sure it’s not an SQL error during update. The changes here don’t fix any error in SQL syntax.
The params column should be a json string. I just saw that one row was inconsistent, that’s all.
Ah, i thought it was an attempt to fix the update issue.
I don’t think we need a new update SQL because it will be fixed anyway if someone saves these options, but maybe @bembelimen has a different opinion.
@richard67 on the last file (the jooally plg) you are also including the columns checkout and checkout_time but this file doesn’t. Would that be a prob?
No that shouldn’t be a problem since they have default value of NULL, as far as I remember. Can’t check now because off desk.
Category | SQL Administration com_admin Postgresql | ⇒ | SQL Administration com_admin Postgresql Installation |
As agreed in our meeting, I have removed the change for the empty string instead of empty json params in the extensions table so this PR fixes only the wrong mail template params.
I have also added a new update SQL to fix that for previous beta versions, and I have changed that in supports.sql for new installations, too.
The change for the extensions table should be done in a separate PR because it needs to do the same fix for other plugins, too.
You can see that here: https://github.com/joomla/joomla-cms/blob/4.1-dev/installation/sql/mysql/base.sql#L245-L379
We are completely inconsistent with that params. It should be fixed all together.
@brianteeman Check my previous comment. I think it answers your question. PR will come sooner or later to fix that, too.
@richard67 thanks - our posts crossed.
@brianteeman Another question is why we change the old update SQL at all if we have a new one which fixes that during the update. I know you don't like us touching the old SQL if not necessary, and I know some people thought they have to run it again when it has changed, which caused a mess. The reason why I prefer to change them is that often they are used as templates for making new update SQL in future, so if we fix them we make sure people don't copy wrong stuff. I had discussed that with @bembelimen and he agreed with me, that's why I did not revert that change in the old update script.
I thought I should explain it to you so you know why I do it like I do here.
I have tested this item
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 | ⇒ | 2022-01-09 10:51:59 |
Closed_By | ⇒ | bembelimen | |
Labels |
Added:
?
|
Thx
Do we still allow updates from beta to stable? If so do we need an update query as well?