Skip to content

fix: Fix the problem of abnormal theme color switching #8012

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
f2c-ci-robot merged 1 commit into from
Feb 26, 2025
Merged

fix: Fix the problem of abnormal theme color switching #8012

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions agent/app/repo/monitor.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ func (u *MonitorRepo) GetIO(opts ...DBOption) ([]model.MonitorIO, error) {
for _, opt := range opts {
db = opt(db)
}
err := db.First(&data).Error
err := db.Find(&data).Error
return data, err
}
func (u *MonitorRepo) GetNetwork(opts ...DBOption) ([]model.MonitorNetwork, error) {
Expand All @@ -50,7 +50,7 @@ func (u *MonitorRepo) GetNetwork(opts ...DBOption) ([]model.MonitorNetwork, erro
for _, opt := range opts {
db = opt(db)
}
err := db.First(&data).Error
err := db.Find(&data).Error
return data, err
}

Expand Down
3 changes: 2 additions & 1 deletion frontend/src/layout/index.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ import { GlobalStore, MenuStore, TabsStore } from '@/store';
import { DeviceType } from '@/enums/app';
import { getSystemAvailable } from '@/api/modules/setting';
import { useRoute, useRouter } from 'vue-router';
import { loadMasterProductProFromDB, loadProductProFromDB } from '@/utils/xpack';
import { loadMasterProductProFromDB, loadProductProFromDB, getXpackSettingForTheme } from '@/utils/xpack';
import { useTheme } from '@/global/use-theme';
import TaskList from '@/components/task-list/index.vue';
const { switchTheme } = useTheme();
Expand Down Expand Up @@ -108,6 +108,7 @@ onMounted(() => {
loadStatus();
loadProductProFromDB();
loadMasterProductProFromDB();
getXpackSettingForTheme();
globalStore.isFullScreen = false;

const mqList = window.matchMedia('(prefers-color-scheme: dark)');
Expand Down
17 changes: 0 additions & 17 deletions frontend/src/utils/xpack.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,23 +87,6 @@ export async function loadMasterProductProFromDB() {
}

export async function getXpackSettingForTheme() {
const res = await getMasterLicenseStatus();
if (!res.data) {
globalStore.isMasterProductPro = false;
resetXSetting();
switchTheme();
initFavicon();
return;
}
globalStore.isMasterProductPro = res.data.status === 'Bound';
if (!globalStore.isMasterProductPro) {
globalStore.isMasterProductPro = false;
resetXSetting();
switchTheme();
initFavicon();
return;
}

let searchXSetting;
const xpackModules = import.meta.glob('../xpack/api/modules/setting.ts', { eager: true });
if (xpackModules['../xpack/api/modules/setting.ts']) {
Copy link
Member

@wanghe-fit2cloud wanghe-fit2cloud Feb 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There doesn't seem to be any specific code differences that I can identify in the provided snippet of JavaScript. The changes appear minor and could be part of normal maintenance practices or bug fixes without any glaring issues.

However, it might be worth noting one small difference:

+const res = await getMasterLicenseStatus();

Could potentially have unintended side effects like calling getMasterLicenseStatus() every time this file is loaded. To avoid those extra calls, maybe you should fetch the data once upon startup?

As a general optimization strategy, consider creating more modular components or services and pass their initialization and retrieval parameters through these modules, making sure dependencies are satisfied only when required.

Regarding licensing statuses, there's no clear reference to licenses here. It would be important either to handle such situations at an API level before passing license details from Master Product Pro directly. Or to store relevant license info in some form within your current project structure, which makes sense considering the overall context of having multiple products licensed under different versions.

Keep in mind though, as this issue pertains solely to syntax/semantics modifications on existing pieces of code, it's not likely that it warrants further development efforts compared with other areas requiring enhancement or debugging efforts.

Since the focus seems to be on maintaining existing functionality instead of introducing new features, there isn't much scope for substantial improvements beyond suggested best practices or minor style adjustments. For detailed optimizations aimed at boosting performance or user experience, perhaps consult the documentation and/or seek external advice from experienced developers?

Expand Down
5 changes: 3 additions & 2 deletions frontend/src/views/login/components/login-form.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -184,6 +184,7 @@ import { MsgSuccess } from '@/utils/message';
import { useI18n } from 'vue-i18n';
import { getSettingInfo } from '@/api/modules/setting';
import { encryptPassword } from '@/utils/util';
import { getXpackSettingForTheme } from '@/utils/xpack';

const i18n = useI18n();
const themeConfig = computed(() => globalStore.themeConfig);
Expand Down Expand Up @@ -334,7 +335,6 @@ const login = (formEl: FormInstance | undefined) => {
menuStore.setMenuList([]);
tabsStore.removeAllTabs();
MsgSuccess(i18n.t('commons.msg.loginSuccess'));
loadDataFromDB();
router.push({ name: 'home' });
} catch (res) {
if (res.code === 401) {
Expand Down Expand Up @@ -369,7 +369,6 @@ const mfaLogin = async (auto: boolean) => {
menuStore.setMenuList([]);
tabsStore.removeAllTabs();
MsgSuccess(i18n.t('commons.msg.loginSuccess'));
loadDataFromDB();
router.push({ name: 'home' });
} catch (res) {
if (res.code === 401) {
Expand Down Expand Up @@ -415,6 +414,8 @@ const getSetting = async () => {
onMounted(() => {
globalStore.isOnRestart = false;
getSetting();
loadDataFromDB();
getXpackSettingForTheme();
if (!globalStore.ignoreCaptcha) {
loginVerify();
}
Copy link
Member

@wanghe-fit2cloud wanghe-fit2cloud Feb 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The primary issue is that loading data from the database should be inside the loadData method rather than in the handleLogin event handler. This will ensure that user data isn't lost if it occurs before the Login component has displayed to the user.

Here's a concise way of fixing this:

const loadUserInfo = async () => {
  // Logic to fetch user info
}

onBeforeRouteEnter((to, from, next) => {
  setTimeout(async () => {
    await Promise.all([loadUserInfo() , loadDataFromDB()]);
    next();
}, 1000);

Also, we could consider moving XPack setting retrieval into an isolated function within common-utils, ensuring no direct interaction with local storage while fetching settings.
Remember, changes are made here based on assuming you were working during November 2021, when there was still support for localStorage which can easily lead to unexpected consequences due to its strict security measures compared to modern browsers like Web Storage API.

Expand Down
8 changes: 4 additions & 4 deletions frontend/src/views/setting/panel/password/index.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,14 +5,14 @@
<el-input type="password" show-password clearable v-model.trim="passForm.oldPassword" />
</el-form-item>
<el-form-item
v-if="complexityVerification === 'disable'"
v-if="complexityVerification === 'Disable'"
:label="$t('setting.newPassword')"
prop="newPassword"
>
<el-input type="password" show-password clearable v-model.trim="passForm.newPassword" />
</el-form-item>
<el-form-item
v-if="complexityVerification === 'enable'"
v-if="complexityVerification === 'Enable'"
:label="$t('setting.newPassword')"
prop="newPasswordComplexity"
>
Expand Down Expand Up @@ -80,7 +80,7 @@ const acceptParams = (params: DialogProps): void => {
};

function checkPassword(rule: any, value: any, callback: any) {
let password = complexityVerification.value === 'disable' ? passForm.newPassword : passForm.newPasswordComplexity;
let password = complexityVerification.value === 'Disable' ? passForm.newPassword : passForm.newPasswordComplexity;
if (password !== passForm.retryPassword) {
return callback(new Error(i18n.global.t('commons.rule.rePassword')));
}
Expand All @@ -92,7 +92,7 @@ const submitChangePassword = async (formEl: FormInstance | undefined) => {
formEl.validate(async (valid) => {
if (!valid) return;
let password =
complexityVerification.value === 'disable' ? passForm.newPassword : passForm.newPasswordComplexity;
complexityVerification.value === 'Disable' ? passForm.newPassword : passForm.newPasswordComplexity;
if (password === passForm.oldPassword) {
MsgError(i18n.global.t('setting.duplicatePassword'));
return;
Copy link
Member

@wanghe-fit2cloud wanghe-fit2cloud Feb 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The provided code snippet appears to be related to creating an authentication form with password fields using El-Table component. I have not found specific differences between the two versions as they seem identical until version 80 (@@ and +) indicating a difference was made around this line:

if (password !== passForm.retryPassword)

This seems problematic because it uses conditional expressions which can cause unexpected behavior due to its strict evaluation strategy. This is especially concerning considering the use case of a complex form validation system which would benefit from checking all conditions before applying the logic.

A safer approach might involve removing or commenting out this line, ensuring both passwords match in each field. This will allow better error handling, maintainability, and security features during development and production scenarios by making the process more predictable. After reviewing other parts of the codebase, you should address any additional discrepancies if necessary within my capabilities to ensure compliance with coding standards and practices.

I would appreciate further guidance on how to tackle this issue effectively without compromising on robust validation processes for user input data.

Expand Down
Loading