Anonymous users can edit the authoring information

I am attaching patch below.kindly test and review it.

I think that makes sense. Could we get a test for that?

Thank you @George Bills. This looks great.

I only found one nitpick:

+++ b/core/modules/media/tests/src/Functional/MediaAccessTest.php
@@ -154,6 +155,15 @@ public function testMediaAccess() {
+    $role = Role::load(RoleInterface::AUTHENTICATED_ID);

This line is not needed.

Could you also please upload a fail patch (a patch that only contains the new test)? That will prove the fix.

Patches should end on *.patch. *.txt will not be picked up by the testbot.

@George Bills, could you please re-upload your files with the correct file extensions.

I re-uploaded the patches from #16 so the testbot can pick them up

Thank you @Nitebreed.

This looks good to me now.

I'm not sure that this is the best fix. Looking at the node entity I think we should improve the field access to determine access and not only do this on the form level. See \Drupal\node\NodeAccessControlHandler::checkFieldAccess().

    // Only users with the administer nodes permission can edit administrative
    // fields.
    $administrative_fields = ['uid', 'status', 'created', 'promote', 'sticky'];
    if ($operation == 'edit' && in_array($field_definition->getName(), $administrative_fields, TRUE)) {
      return AccessResult::allowedIfHasPermission($account, 'administer nodes');
    }

Here is a new patch that moves the access check to the field level.

+++ b/core/modules/media/src/MediaAccessControlHandler.php
@@ -83,4 +85,18 @@ protected function checkCreateAccess(AccountInterface $account, array $context,
+    $administrative_fields = ['uid', 'status', 'created'];

Do we really need users to have 'administer media' for them to publish/unpublish media? I know node is doing that, but just not sure if we should copy it.

Berdir pointed out that the default status could be 'Unpublished' and there could be some kind of workflow where you don't want users to publish the nodes, but I'm not sure how valid that argument is for media.

Removing the author and created field is probably fine for most sites, but removing the published checkbox for some users on existing sites is probably not.

Tagging and escalating.

Back to NW for the status field. I think we are also missing an interface test where users unpublish media via the interface. I would have at least expected some tests to fail after making a change like this.

Do we really need users to have 'administer media' for them to publish/unpublish media? I know node is doing that, but just not sure if we should copy it.

I'd also question this.

Looking at https://api.drupal.org/api/drupal/core%21modules%21media%21media.permiss... it looks like there's an "Update own media" permission, so maybe attach published/unpublished to that, if we're indeed talking only about personal media here? (You definitely don't want random weirdos unpublishing other peoples' media; though there's also an "Update any media" for that.)

Linking the publishing permissions to edit sounds very reasonable. If you can change the value of the source field and the name, most of the times you would expect to be able to publish / unpublish as well. As long as we don't have more granular permissions in core, this is probably the best we can do.

If you can change the value of the source field and the name, most of the times you would expect to be able to publish / unpublish as well.

This sounds reasonable to me.

@seanB I have added test according to #25, Can you please check and advise these tests are up to the mark.

@vsujeetkumar, Looks good

@seanB This needs code review as well for tests before we move this one to RTBC

The suggestion from #25 to use update media / update any media instead of administer media still needs to be implemented. Setting to needs for for that.

Also

+++ b/core/modules/media/tests/src/Functional/MediaAccessTest.php
@@ -190,6 +199,15 @@ public function testMediaAccess() {
+    // Test the 'administer media' permission on a non-admin account with unpublished media.

This line is longer than 80 chars.

@seanB I have done with the changes mentioned in #35, Please have a look and advise.

@vsjujeetkumar tests are failing, please recheck

+++ b/core/modules/media/src/MediaAccessControlHandler.php
@@ -100,4 +102,18 @@ protected function checkCreateAccess(AccountInterface $account, array $context,
+      return AccessResult::allowedIfHasPermission($account, 'update media');

The update media permission is only for media owners/authors, so we should also check if the user is the owner.

The update any media permission is still missing.

BTW, in #2862422: Add per-media type creation permissions for media we added per media type permissions and the generic permissions will be deprecated in #2925459: Deprecate generic media permissions.

You should probably take a look at MediaAccessControlHandler::checkAccess().

And then specifically this part:

        if ($account->hasPermission('edit any ' . $type . ' media')) {
          return AccessResult::allowed()->cachePerPermissions();
        }
        if ($account->hasPermission('edit own ' . $type . ' media') && $is_owner) {
          return AccessResult::allowed()->cachePerPermissions()->cachePerUser()->addCacheableDependency($entity);
        }
        // @todo Deprecate this permission in
        // https://www.drupal.org/project/drupal/issues/2925459.
        if ($account->hasPermission('update any media')) {
          return AccessResult::allowed()->cachePerPermissions();
        }
        if ($account->hasPermission('update media') && $is_owner) {
          return AccessResult::allowed()->cachePerPermissions()->cachePerUser()->addCacheableDependency($entity);
        }

Another thing is also that the caching is probably not correct for the code we currently have, so you also need to take a look at #2998824: MediaAccessControlHandler update/delete access caching is not correct which adds some changes to fix the caching.

Needs updated patch for retesting
Needs fix

#44 Fixed whitespace errors and re created patch

Instead of re-implementing half the logic from MediaAccessControlHandler::checkAccess(), I think we can simply call this method.

Since this is altering the access (all be it seems correct) think it needs a CR as it is altering behavior.

Felt bad so I went ahead did the CR, super simple one

Since the author field is hidden from the form to users who don't have edit access, I think there should be test assertions that the UID is still set to that creator on save of new media entity.