Initially, I don't really see the value in adding these columns. Especially the created by for the user as that generally has other implications throughout the system as well (i.e. ACL).

Hm I don't know about other implications, but my use case is that, in a multi-admin environment, can track who did the last change (and when) to a module.

Modified is probably "safer" (I still don't personally see the use for it in core, you could do this activity logging more thoroughly and probably better overall just as easily with a plugin catching onXXXAfterSave), but adding the created fields generally has other implications/uses that don't necessarily apply to modules (i.e. with categories edit.own permission uses the created_by field for the user ID).

Ok, understood your point. But isn't having full ACL on modules a desirable thing? Or are there performance reasons why we shouldn't do this?

if you have created_by you need to add core.edit.own ACL processing in all modules processing (where core.edit ACL check exists for com_modules.module.xx basicly).

But isn't having full ACL on modules a desirable thing?

I guess it depends. I never personally saw the use in having per-module ACL but apparently I've never run into those cases where I'd benefit from it either. The sites and teams I've worked with have never necessitated a need to only be able to edit certain modules.

Or are there performance reasons why we shouldn't do this?

Some will tell you there's no need for per-item ACL in general, I know at least one company whose first action on any performance related issue is to just delete all com_content.article.X assets as it's a major performance issue. How I don't know personally, never debugged that to understand it, but I guess there is some less than optimal performance in the ACL system overall from the sounds of it.

Maybe ACL checks can be a performance issue in huge sites.

JAccess preloads all assets for a particular component in a single query (see https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/access/access.php#L312) so it doesn't have to make a query for each asset that is checked on page generation (and they can be a lot when you are not logged as super user).

This is a good performance improvement in sites with small to medium ACL tables - one query returns all assets for that component (imagine a page with 10+ modules when logged with registered user), but probably when you have 10.000 article assets it will have some memory/performance issues, since it's a query that can return up to 10.000 rows.

Not really tested, but in theory...

i am closing this at this time as there doesnt seem to be any interest in creating the necessary code for this change to even see if it is feasible. It can always be reopened if there is a code proposal