Since last update, all resellers layouts set to "Refreshed" instead of "Icons grid"

[nlaruelle]

Hello,

I have already reported in this thread (https://forum.directadmin.com/threads/how-to-update-existing-reseller-and-user-skins.67475/) the big difficulties in forcing all users and resellers on a specific "Default Layout", but I haven't received any response from the DirectAdmin team, so I'm taking my chance by opening my own thread.

My need is quite simple:

I want all my users and resellers to be forced on the same interface to avoid for example having 25% of users choosing a "List Layout"… 25% a "Refreshed Layout"… and the rest split between "Standard", "Sidebar", "Hybrid", and "Refreshed".

It's a pretty basic need to want the same interface for all users, right?
This avoids confusion when we publish screenshots in the knowledge base.
Additionally, the technical support staff is less confused if they always work with the same interface.

Personally, I admit I prefer the "Icons Grid" layout because it reminds me of my habits with cPanel. I would also like to enforce the option "Forbid users changing the skin layout on user level" for all my resellers.
The "Dashboard Mode" of Refreshed should be "Menu" by default instead of "Widgets," etc.
By the way… ALL options in "/customize-skin/options" should be easily enforceable "globally"

To accomplish this (more or less), I had removed access to "Customize Evolution Skin" for my users (in /usr/local/directadmin/data/users/$USER/skin_customizations/evolution/files/menu-v3.json, by bash+cron) and created a second bash script that changed the value of "da: options/skin/layout" to "grid" for all my users and resellers:

#!/bin/bash

for USER in $(ls /usr/local/directadmin/data/users/); do

    USER_OPTIONS_JSON="/usr/local/directadmin/data/users/$USER/skin_customizations/evolution/user_options.json"
    OPTIONS_V4_JSON="/usr/local/directadmin/data/users/$USER/skin_customizations/evolution/files/options-v4.json"

    if [ -f "$USER_OPTIONS_JSON" ]; then
        SKIN_LAYOUT_VALUE=$(grep -oP '(?<="da:options/skin/layout":")\\?"[^"]*' "$USER_OPTIONS_JSON")
        if [ -z "$SKIN_LAYOUT_VALUE" ] || [ "$SKIN_LAYOUT_VALUE" != "\\\"grid\\\"" ]; then
            sed -i 's/\("da:options\/skin\/layout":"\)[^"]*\("\)/\1\\"grid\\"\2/' "$USER_OPTIONS_JSON"
        fi
    fi

    if [ -f "$OPTIONS_V4_JSON" ]; then
        SKIN_LAYOUT_V4_VALUE=$(grep -oP '(?<="skin/layout": ")[^"]*' "$OPTIONS_V4_JSON")
        if [ -z "$SKIN_LAYOUT_V4_VALUE" ] || [ "$SKIN_LAYOUT_V4_VALUE" != "grid" ]; then
            sed -i 's/\("skin\/layout": "\)[^"]*\("\)/\1grid\2/' "$OPTIONS_V4_JSON"
        fi
    fi

    if [ -f "$OPTIONS_V4_JSON" ]; then
        SIMPLE_LAYOUT_VALUE=$(grep -oP '(?<="simple-layout/navigation/display-type": ")[^"]*' "$OPTIONS_V4_JSON")
        if [ -z "$SIMPLE_LAYOUT_VALUE" ] || [ "$SIMPLE_LAYOUT_VALUE" != "grid" ]; then
            sed -i 's/\("simple-layout\/navigation\/display-type": "\)[^"]*\("\)/\1grid\2/' "$OPTIONS_V4_JSON"
        fi
    fi

done

Unfortunately, as often happens with DirectAdmin (which I regret), the changes were not persistent (due to a lack of backward compatibility) and did not survive DirectAdmin updates for long.

Since the latest DirectAdmin update, all my resellers' skin settings were overwritten (lost), and all my resellers found themselves with a very different interface overnight from the one they were familiar to.
Even my logo and favicon disappeared, as they were configured only for "Icons Grid" and not for "Refreshed."
To be honest, I was informed of this sudden interface change through few customer complaint tickets. They think about a bug since they were familiar with the previous minimalist "Icons Grid" interface.

The issue is that the structure of the user config file has changed significantly for /usr/local/directadmin/data/users/$USER/skin_customizations/evolution/user_options.json.

Now, we have a numerical value for /reseller/customize-skin that is different for each reseller.

For example :

{"da:options/search/settings":"[\"domains\",\"email\",\"ftp\",\"db\",\"plugin\",\"route\",\"admins\",\"resellers\",\"users\"]","da:options/skin/date-formats/date":"\"dd'/'MM'/'yyyy\"","da:options/skin/date-formats/datetime":"\"dd'/'MM'/'yyyy HH':'mm\"","da:options/skin/date-formats/weekStart":"\"monday\"","da:options/skin/fixed-color-mode":"\"none\"","da:options/skin/language":"\"en\"","da:options/standard-2021-layout/frequent-routes":"[[\"/user/domains\",242],[\"/reseller/customize-skin\",XXXXXXXXXXXXXXXXXXX]]","da:options/standard-2021-layout/user-dashboard-type":"\"widgets\"","da:options/user/level":"\"reseller\""}

It is therefore impossible for me to adapt my bash to force the default layout to "Icons Grid," as I don’t know how to guess the value to assign to each /reseller/customize-skin.

Overall, I would prefer to stop randomly tinkering with bash scripts and cron jobs that modify .conf and .json files.

Also, I can't manually navigate through hundreds of user sub-accounts to change the setting by hand every time I want to globally modify an option under "Customize Evolution Skin."

So, what is the proper way to set a unique "Default Layout" globally for all my users/resllers (as well as the other options available in "Customize Evolution Skin" (Layout Options, etc.)), for both old and new users?
A command line?
A feature to enhance in the DirectAdmin interface?

Thank you in advance for your help with this issue, which is very important for my DirectAdmin projects, as it greatly affects my users' experience.

 

[fln]

Thanks for a very detailed explanation of the problem you are facing. This gives us a good insight on different DA usage scenarios.

I think the customization system is quite complex, and a deeper insight into how it works can make it easier to achieve the desired results.

---

The skin customization system has a built-in inheritance logic. It works in the following way: when the user account (for example, user1) loads customizations it will load them from his creator account (for example, reseller1). If his creator is not an admin and has no customizations then the creator of reseller1 will be checked (for example, admin1).

This longer customization inheritance chain allows a single admin account to control all of the customizations as long as:

• All resellers belong to a single admin account (if multiple admin accounts are creators of users, then customizations need to be copied).
• All resellers do not have their own customizations.

Instead of trying to unify the customizations for all accounts, a better approach would be to ensure resellers do not have the customizations, and customizations made by admin accounts are the only source of truth for everyone.

---

When the structure of skin customizations changes, Evolution automatically creates a new version of the customizations file. For example, in DA 1.669 and older menu customizations used to be stored in the menu-v3.json file. In version 1.670, a structure was slightly changed, and now the customizations are being stored in the menu-v4.json file. Evolution takes care to read the v3 file, convert it to v4, and save if such action is allowed (and resellers are allowed to make the customizations).

I think this automated conversion is what actually caused you problems after the upgrade. If the customizations were created in the admin account, when resellers logged in for the first time, they migrated the customizations into v4 and stored them as their own customizations. This made the resellers and users of the resellers no longer follow the customizations in the admin account but instead use the reseller-owned customizations.

This is a customization migration bug that we need to take into consideration and make sure reseller accounts do not try to migrate them by creating their own version of customizations. Thanks for bringing this to our attention!

An easy workaround for the problem would be:

• Login as an admin account into Evolution to allow it to perform customization migration.
• Remove the /usr/local/directadmin/data/users/{resellername}/skin_customizations/evolution/files directory from all reseller accounts.

If the admin-provided customization files are up-to-date when reseller logs in, Evolution will not try to perform the migration.

---

To prevent resellers from making any customizations, it would be better to actually deny them this action on the backend instead of hiding this feature from the menu. Blocking customizations on the backend would have also prevented resellers from copying the customizations for migration.

To make sure resellers are not allowed to make any customizations you can add the skin-customization line into the file /usr/local/directadmin/data/users/{resellernaname}/commands.deny. Single shell command:

echo 'skin-customization' >> /usr/local/directadmin/data/users/{resellername}/commands.deny

If this method is used to block skin customization actions, Evolution is smart enough to not show the menu entry for the skin customization. So there would be no need to customize the reseller menu.

 

[nlaruelle]

Thanks a lot fln!
I was able to restore the Grid Layout, and my logo + favicon following your advice to remove */skin_customizations/evolution/files/ by this way:

for USER in reseller1 reseller2 reseller3; do mv /usr/local/directadmin/data/users/$USER/skin_customizations/evolution/files/ /usr/local/directadmin/data/users/$USER/skin_customizations/evolution/files-bkp/; done

Also, I very appreciate the whole explanation about parameter inheritance logic from the Admin / Creator to the sub accounts

Thanks again!

 

[nlaruelle]

I was thinking this issue would be resolved in future update.

However, it's a bit disappointing that since the last update (around December 19), the problem has reappeared.

Unfortunately, I discovered the issue a bit late since it was during the holiday season.
A recent user reported that their new (and incorrect) interface was confusing and even asked to cancel their service, stating, "the new interface is more confusing than cPanel"

To address the issue, I've set up the following cron job each 24h:

0 6 * * * DATE_TODAY=$(date +\%Y-\%m-\%d); for USER in $(cat /usr/local/directadmin/data/admin/reseller.list); do mv /usr/local/directadmin/data/users/$USER/skin_customizations/evolution/files/ /usr/local/directadmin/data/users/$USER/skin_customizations/evolution/files-bkp-${DATE_TODAY}/; done

It's just a workaround, not an entirely clean solution.

Is there any way to resolve this problem without affecting the skins for future updates?

 

[fln]

Thanks for the report @nlaruelle. We will double-check to see if DA 1.672 could have caused such problems.

If resellers are allowed to customize Evolution (they are always allowed unless skin-customization command is explicitly forbidden with commands.deny file or other means), they will be able to reset admin customizations by changing anything in the customize Evolution page.

What we have fixed in the DA 1.670 is the automatic reseller customization migrations. A situation when an admin account has an outdated customization file and the reseller tries to upgrade it by creating its own customization.

If there is a situation where a reseller can trigger automatic customizations (without manually making them on the customization page), this is a bug and needs to be fixed. Your report hints that there could be a situation when automatic customization is still possible, but it is not yet clear how. It would be great if you could open a support ticket and give us an example of the .../evolution/files-bkp-{date} directory contents and admin-owned customizations. This could hint at how or why resellers created customizations after the DA update.

 

[fln]

We have identified the root cause of this problem. Due to a bug the DA 1.672 always creates the images-v1.json customization file, even when images are not customized. This issue is fixed in DA 1.673, this version also has the code to automatically clean-up the surplus customization file. The fix for this problem will be backported to DA 1.672 before it hits the stable release branch.

Thanks for reporting the issue.