SalesforceToolkit开发日志v0.341

Release Note

v0.341 Release Note
- Bugfix
    - None
- New features
    - Metadata Module - Add support for custom label
    - Login Module - Optimize config saving strategy to local first
- Function improvement
    - None

此版本主要有两项更新

  1. 在Metadata模块中新增了Custom Label的创建与更新功能。
  2. 调整了配置信息的存储策略,现在优先本地存储,但仍可以手动进行远程同步。

概述

在Metadata模块中新增了Custom Label的创建与更新功能

在之前的更新中,我们添加了CustomLabel的翻译创建与更新功能,目的是帮助大家提高维护CustomLabel翻译的效率。在此基础上,有些朋友提出手动创建CustomLabel本身也是一件效率较低的事情,所以我们进行了改进。

由于对CustomLabel没有公开的数据操作方式,所以原理上我们仍然是通过SOAP API方式调用Metadata API,依然是手动拼接XML。

与CustomLabel Translation的操作逻辑不同,Translation可以创建/更新的前提是CustomLabel必然已经存在。所以,我们可以通过同一个XML同时进行没有翻译创建翻译,有翻译更新翻译的操作。但是Custom Label的创建和更新接口是两个完全不同的XML类型。因此,我们在弹出窗口中增加了一个选项,让你选择是创建还是更新。填写内容的方式仍然是传统的XXXX,YYYY模式,XXXX为API Name,YYYY为Value。

在处理返回值时,CustomLabel接口出现了特殊性——返回结果会多出一行success节点值为false,fullName为空但带有属性xsi:nil=”true”的result。这导致原有的错误处理代码做出了错误的结果判断。我们试过切换API版本等措施,但都无法定位和解决此问题,所以只能在判断结果时额外循环一次移除这种多余的result节点。

将来,我们可能会增加CustomLabel删除的选项,但由于被引用的问题,大部分CustomLabel很难直接删除,所以这个功能不会优先考虑。

至于查询系统当前的CustomLabel,由于目前Tooling API可以直接查询CustomLabel表,SOQL模块已经支持Tooling API查询,所以我们短期内不会考虑这个功能。

调整配置信息的存储策略,现在优先本地存储,但仍可以手动进行远程同步

Chrome插件为了方便用户跨设备同步配置信息,提供了Chrome.storage.sync接口。这个接口的行为与浏览器的标准local.storage类似,但并不会存储在浏览器的Storage空间中,而是存储在Google账号的云空间中。需要注意的是,这些信息属于用户个人的Google账号,插件的开发者并不能看到。如果用户没有登录Google账号,Chrome.Storage.Sync接口的行为会降级到Chrome.Storage.Local接口。这个接口与浏览器标准的local.Storage不同,它是存储在独立的浏览器沙盒空间中。

之前的配置信息同步逻辑是,插件初次加载时从云端获取配置信息,如果配置信息发生变动,如新增、修改、删除,则实时存储回云端。其他配套功能如配置导出等,都是直接从云端配置读取,而不是使用已加载的页面信息,这样可以避免信息状态同步的问题。

虽然这个机制运行良好,但有些用户反映出现了配置被反复覆盖回某个时间点的版本的问题。我们调查发现,出现这种现象的用户都是因为Chrome账号服务被人为阻塞导致的——只阻塞了同步到云端,但没有阻塞从云端获取。这就导致无论本地信息如何变动,只要重新加载插件,配置就会恢复到云端版本。

为了根本解决云端配置同步的潜在问题,我们决定优先使用本地版本(Chrome.Storage.Local)的配置信息。从新版本开始,配置信息的来源将优先从本地获取,所有的变动也将只修改本地存储的信息。同时,我们增加了两个按钮,用于手动将本地配置信息存储到云端,或者从云端获取配置信息并合并到本地。

同时,由于当前所有配置信息在本地的存储状态并不确定,只有云端版本是我们可以信赖的。所以初始加载逻辑变为先从本地获取,如果从本地无法获取到信息,则从云端获取,并将获取到的信息存储到本地。这样,在版本切换时,我们可以将云端配置信息转变为本地版本。

信息安全是我们的重中之重,这个插件不会收集任何用户输入的信息,无论是在云端还是本地。请放心使用。