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
此版本主要有两项更新
- 在Metadata模块中新增了Custom Label的创建与更新功能。
- 调整了配置信息的存储策略，现在优先本地存储，但仍可以手动进行远程同步。
概述
在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）的配置信息。从新版本开始，配置信息的来源将优先从本地获取，所有的变动也将只修改本地存储的信息。同时，我们增加了两个按钮，用于手动将本地配置信息存储到云端，或者从云端获取配置信息并合并到本地。
同时，由于当前所有配置信息在本地的存储状态并不确定，只有云端版本是我们可以信赖的。所以初始加载逻辑变为先从本地获取，如果从本地无法获取到信息，则从云端获取，并将获取到的信息存储到本地。这样，在版本切换时，我们可以将云端配置信息转变为本地版本。
信息安全是我们的重中之重，这个插件不会收集任何用户输入的信息，无论是在云端还是本地。请放心使用。