If Sitefinity was upgraded and dynamic content items’ permissions are ‘Administrators only’ and the type itself has set different permissions, then there is a chance that the upgrade has failed.

Sitefinity comes with granular permissions for dynamic content items. This requires sites running older versions to go through an upgrade procedure which will modify existing content.

Note that this is done asynchronously after the database model has been already changed and site is running. In order to verify the successful outcome of the upgrade, we can check the UpgradeTrace.log file located in ~/App_Data/Sitefinity/Logs directory. Success would be denoted in this way:

<%@ Application Language="C#" %>
<script runat="server">
    void Application_Start(object sender, EventArgs e)
    {
        Telerik.Sitefinity.Abstractions.Bootstrapper.Initialized += new EventHandler<Telerik.Sitefinity.Data.ExecutedEventArgs>(Bootstrapper_Initialized);
    } 
      
    void Bootstrapper_Initialized(object sender, Telerik.Sitefinity.Data.ExecutedEventArgs e) {
        if (e.CommandName == "Bootstrapped")
        {
            var task = new Telerik.Sitefinity.DynamicModules.Builder.Upgrade.DynamicContentPermissionsUpgradeTask();
            task.ExecuteTime = DateTime.UtcNow.AddMinutes(1);
            task.NumberOfAttempts = 3;
            var schedulingManager = Telerik.Sitefinity.Scheduling.SchedulingManager.GetManager();
            schedulingManager.AddTask(task);
            schedulingManager.SaveChanges();
        }
    } 
</script>

Note that there is no code-behind file for this application resource. Once put in the root directory of the project, request the website.

The task will start executing after a minute. After some time, check again the log file to see if the upgrade has succeeded.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
If re-running the upgrade task doesn`t fix the issue refer to the attached FixPermissionsWebForm.zip that supplies a solution which involves removing all permissions from all modules and their module items and inheriting the permissions for Module Builder defined in Administration->Permissions ->Module Builder. After this inheritance, all permissions will function normally. The manual action to be taken is to assign the desired permissions for each module because they all will be inheriting the permissions from Module Builder.

The steps to use the FixPermissionsWebForm.aspx are:
1. Go to Administration->Permissions and select "Module Builder", those are the permissions that will be assigned to all dynamic module providers and all dynamic module items after the fix is applied. Make sure those permissions are the way you want them!
After the fix you will need to update each module provider individually to assign the proper permissions because the fix will delete them because they are corrupted now.

2. Refer to the attached FixPermissionsWebForm.zip which contains a webform that fixes the issue. Request the webform in the browser to execute it. Note I suggest to fix the modules one by one and this why in the Page_Load method there is only one module executed at a time. After one of the modules is fixed continue from this step 2 to fix the next one.
The entry in Page_Load

string moduleName = "Tests";
string moduleTypeName = "Test";

3. Once the webform is executed go to the module and click permissions on the right sidebar of the module page. For the "Default" provider click "Inherit Permissions from parent", the rest of the providers will already be inheriting the permissions assigned in step 1.

6. The module is fixed after this.