I have tested this item ✅ successfully on ff1fd06

?

Add to as it is not enabled by default?

Add to as it is not enabled by default?

Thanks - thought I had done that but obv didnt

Tested this in a fresh installation (no update).

It works for fields, but not for field groups. Is this correct?

And a linguistic question. For a German this looks strange: User xx performed a check in to table #__nn

Clicking on the field link goes to the last Field section visited. In the screenshot, it is an Article field yet it displays it as a User field.

It works for fields, but not for field groups. Is this correct?

Yes - field groups is becond the scope of this pr. I would welcome someone adding support for that. (in other words I failed to achieve it)

And a linguistic question. For a German this looks strange: User xx performed a check in to table #__nn

I hope this helps you to understand https://developer.joomla.org/en-gb-user-interface-text-guidelines/action-or-description.html

Clicking on the field link goes to the last Field section visited. In the screenshot, it is an Article field yet it displays it as a User field.

grrhh - no idea how to address that

Thanks. I would say "I performed a check on a table " not in to a table, but can live with this ;)

The headline - yes. It probably comes from the context.

Thanks. I would say "I performed a check on a table " not in to a table, but can live with this ;)

No - it is specifically a check in

@Quy i have an article field. The context correct and the link is /administrator/index.php?option=com_fields&view=field&layout=edit&id=1&context=com_content.article goes to an article field.

@chmst Now create a User field. Then click on the Article field in the User Action Log. The heading will display it as a User field.

@Quy indeed. Seems to depend on the context in the user state.

This pull request has been automatically rebased to 5.0-dev.

@brianteeman Due to the rebase to 5.0-dev it needs to rename the update SQL scripts. I suggest to rename them to "5.0.0-2023-08-28.sql" because there are other PR's proposed which will already use "5.0.0-2023-08-22.sql" to "5.0.0-2023-08-27.sql". The base name needs to be greater than the one of the greatest update SQL script in the branch, using version_compare, otherwise it will not run on update when updating from a previous 5.0.0-alpha.

Feel free to do it. I don't use my pc on Sabbath

I have tested this item ✅ successfully on b917bc5

5.0.0-beta1-dev+pr.29376

Feel free to do it. I don't use my pc on Sabbath

@brianteeman Done.

@MacJoom It seems you have tested with a new installation. Could you also test with updating from a previous 5.0.0-alpha or from 4.4? Thanks in advance.

Works as a Update from 4.4.0 to 5.0 too. You have to add 'Fields' in the com_actionlogs options (Events to log), as stated in the instructions

@MacJoom Ok, I've restored your test result. Counter was reset after I've renamed the update SQL scripts. Do you think @viocassel 's test result still counts, too? He had tested before the PR was rebased, but after that there haven't been made any changes besides my scripts rename. Not sure if I shall count it and set the PR RTC or if a 2nd actual test would be better. What do you think?

@MacJoom Ok, I've restored your test result. Counter was reset after I've renamed the update SQL scripts. Do you think @viocassel 's test result still counts, too? He had tested before the PR was rebased, but after that there haven't been made any changes besides my scripts rename. Not sure if I shall count it and set the PR RTC or if a 2nd actual test would be better. What do you think?

I would prefer another test on 5.0 - his test is over a year old

I have tested this item ✅ successfully on 8877476

PBF23 ‎5.0.0-beta1-dev PHP 8.1

RTC

Seems I missed this thanks