https://ld246.com/article/1700037001804
https://ld246.com/article/1698930271825
#9145

1. 全局只读和单篇锁定功能独立，不会联动。全局只读优先级高，单篇锁定优先级低。如果打开了全局只读，那文档不管单篇锁定与否都不可编辑

如果按全局只读优先级更高考虑的话，那单篇的设置就没有意义了，因为无法覆盖全局，永远也设定不了单篇状态。

2. 文档依旧根据单篇锁定与否来决定是否可以编辑，但是打开全局只读时，所有文档的状态均设置成锁定状态，如果用户对单篇文档解锁，则会自动关闭全局只读

如果单篇可以控制全局，那么全局就没有意义了。另外还有一种情况是全局只读状态，单篇解锁为可编辑，这时候全局改为解锁，编辑完这篇以后又设置为只读，那么此时全局是否要改变？如果改变为只读，那么全局就完全等价于全局了；如果不改变，那么用户一样会困扰，为什么解锁了这篇其它篇也解锁了？

所以综上，单篇覆盖全局应该是最简单的规则了。

如果按全局只读优先级更高考虑的话，那单篇的设置就没有意义了，因为无法覆盖全局，永远也设定不了单篇状态。

不是这么理解，用户使用全局只读时心理的预期就是整个所有文档都不能编辑。也就是说大概率只有在用户需要纯阅读的时候才会打开全局只读的开关，例如手机端，这个时候和单篇锁定没有关系。单篇是用户在例如电脑端使用，存在部分文档需要编辑部分仅阅读时使用，这个时候就保持全局关闭只读

而如果是现在的逻辑的话，用户想要真正的全局只读并不能做到，因为你不知道对于哪一篇文档你是之前有操作过解锁状态的

那没有办法了，这里有逻辑冲突，因为要考虑到前面提到的一种场景：全局只读，但是偶尔想修改一篇，修改以后再锁定。

要解决这个问题就只能取一个优先级最高的覆盖低的，思源里面的设置都是局部覆盖全局。

方案2也有办法解决

如果单篇可以控制全局，那么全局就没有意义了。

也不是没有意义，如果按方案2的话，起码如果全局是只读的话，那底下的所有文档都是锁定状态的，而如果是全局非只读的话，那底下就是锁定或非锁定的

全局只读状态，单篇解锁为可编辑，这时候全局改为解锁，编辑完这篇以后又设置为只读，那么此时全局是否要改变？

全局只读不需要改变，其他文档也还是保持未解锁的状态，就是只有单篇解锁关闭全局只读，而这个关闭不会影响其他文档

其实这两个方案的核心都是一样的，就是打开全局只读后用户的预期其实是所有文档都无法编辑的，要不然也不叫全局只读这个名字了😂

但是只读关闭的话就是可编辑啊，全局只读开关关闭的话就是全局可编辑。

所以逻辑上必然是需要一个优先级的，局部覆盖全局是较为合理的，所以我们才这样设计。

那方案2可能比较适合你局部覆盖全局的考虑

我考虑的全局只读可能是类似内核--readonly参数的效果，优先级更高

Translate to English

Describe the problem

To make it easier to understand, the following read-only/non-read-only is for global, and locked/unlocked is for single document.

Current global read-only vs. single-article read-only logic:

• global read-only, document unlocked: editable
• global read-only, document locked: not editable
• global non-read-only, document unlocked: editable
• global non-read-only, document locked: not editable

To put it simply, whether a document can be edited is determined by whether it is locked or not.

But there is another logic: when the global read-only is turned on, documents that have not been locked and unlocked will become locked, while documents that have been locked and unlocked will not change.

Personally, I find this logic a bit strange, because in this case, the global read-only is not very meaningful, because I have deliberately to operate the global read-only, but there are still some documents can be edited directly, because the document has been operated before the operation of unlocked

Expected result

I think the expected result of a user turning on global read-only should be that all documents are uneditable.

There are two options:

1. global read-only and document locking are independent. They are not linked. Global read-only has a high priority and document locking has a low priority. If global read-only is turned on, the document is not editable (whether the document is locked or not).
2. the document is still based on the document locked or not to determine whether it can be edited, but when you open the global read-only, all documents will be set to locked, if the user will unlock the document, the global read-only will be automatically closed.

Personally prefer option 1, because this can be opened when the need for global read-only alone, and open and close the global read-only will not affect the status of a single document locked or not.

考虑到使用全局只读的两种场景：

• 临时开启，用完关闭（临时锁定所有文档，确保不可编辑）
• 长期开启（多用于在移动端查看 / 只需要特定的某些文档可编辑）

我提出第 3 种方案：

• 在关闭全局只读时记忆单篇文档的锁定状态；在开启全局只读时改变的状态不记忆
• 开启全局只读时默认将所有文档锁定，但保留在开启全局只读前的状态记忆，在关闭全局只读后按照记忆恢复原先的状态

https://ld246.com/article/1700037001804/comment/1700037641465#comments

一个最简单的解决办法：

• 如果全局只读打开，关闭文档时就重置文档的readonly字段为True，此时相当于全局只读优先级最高
• 如果全局只读关闭，关闭文档时啥都不做，此时相当于文档readonly优先级最高

您的方案1个人感觉不好。

因为用户如果误打开全局只读，操作时候会发现不管上不上锁都没法编辑，出现类似bug的表现。会引起用户愤怒。（不是所有用户都能意识到有这个全局只读功能，而且即使知道这个功能，发现疑似bug的表现时候不一定都能想到是这个原因。）

您的方案2个人感觉也不好。

全局只读作为一个开关不应该大批量操作各文档属性，因为误操作后回退成本巨大（之前用过一个思源插件，本身在前端渲染就能实现的功能，启用后把我的所有文档都改了一遍，回退成本相当大，非常讨厌这种特性）。

个人觉得最好的方案：

启用全局只读时：

• 所有内容锁上，想要编辑就按锁头按钮解锁，解锁后可以编辑该篇内容，但是这个可编辑与否属性不用记录到文档的属性中。所以关闭文档（或者关闭app）再打开，还是上锁的，想要编辑重新按锁头解锁。
• 新建文档属性默认解锁，但是前端编辑限制为符合上一条描述。

关闭全局只读：

• 上锁与否根据各文档自身的属性决定。
• 新建文档属性默认解锁。

@88250 : 不改了不改了，单篇覆盖全局 👿

这个恐怕相当不好。 一切看起来像 bug 的 feature 都不应该存在。

这个恐怕相当不好。 一切看起来像 bug 的 feature 都不应该存在。

之前讨论已经说过了，这个设计逻辑上就有冲突，只能选择一个覆盖规则，从设计的一致性角度着手，单篇覆盖全局是合理的。

单篇覆盖全局是合理的。

sorry,看走眼了，我还以为采纳楼主的方案（全局覆盖单篇）了。个人认为楼主的方案欠妥。 因为feat看起来像bug.

不过我还是觉得我的方案目前是最合理的，类似于目前官方的方案，但是个人觉得更合理一点。

因为目前楼主的和官方的方案稍微有点奇怪，官方的稍好一些，但是依然两个开关带来了四种状态，不是很线性。因为不知道锁上到底是全局只读上的所还是单篇只读上的锁（我可以摸清楚，但是考虑到有用户可能会感到迷惑）。

我的方案：全局只读可以作为编辑器的锁，而且这个锁可以通过锁头按钮临时解除一次（不要把改动写到文档的属性），关闭文档后重新上全局锁，应该是最好的。

设计图

您的方案1个人感觉不好。
因为用户如果误打开全局只读，操作时候会发现不管上不上锁都没法编辑，出现类似bug的表现。会引起用户愤怒。

这个方案主要是从实现复杂程度考虑，所以简单分为两个优先级，逻辑也比较清晰，至于你说的开了全局只读之后用户引起误会其实可以通过提示解决😁，当然你提到优化版本可以更优雅的解决这个问题

您的方案2个人感觉也不好。

确实，全局只读作为一个临时使用的功能会修改单篇锁定状态，不太合理

官方的稍好一些，但是依然两个开关带来了四种状态，不是很线性。因为不知道锁上到底是全局只读上的所还是单篇只读上的锁（我可以摸清楚，但是考虑到有用户可能会感到迷惑）

你可能还没懂现在官方方案问题所在，目前官方方案没有那么复杂，就是按照单篇状态来确定，和全局只读与否没有关系。关键在于打开了全局只读之后，有些文档（编辑过单篇状态的文档）依旧可以直接编辑，这才是最大的问题

最后，你提的方案确实是目前最合理的方案，满足打开全局只读之后，未打开的所有文档默认都是不能直接编辑，需要手动解锁。同时，文档是否可以编辑只取决于单篇状态，也满足了D大提到的单篇覆盖全局的一致性考虑

启用全局只读时：新建文档属性默认解锁，但是前端编辑限制为符合上一条描述

只有这一点，启动全局只读时，为了保证逻辑统一，新建文档是不是应该默认锁定，用户手动解锁编辑更好一些

@Temacc0531 谢谢您的认同和详细的解答！

只有这一点，启动全局只读时，为了保证逻辑统一，新建文档是不是应该默认锁定，用户手动解锁编辑更好一些

这个我主要是考虑到只读功能是保护已有内容避免误删或者修改。但是既然新建了页面，既然不存在内容所以也没必要保护，加上既然新建了页面就是想填入内容，所以就不用锁了。
当然您说的也很合理，或许相比便利性，还是符合操作逻辑更重要一点。这个细节就由开发者决定（如果还打算改的话）就好。

我没有读过思源的源码，不是很清楚实现我的方案是不是原理上可行的。但是我确定逻辑上是可行的。个人感觉或许编辑器的有一部分要重写，工作量可能比较大，所以如果开发者决定不动它的话我们也很理解。
（好像从逻辑判断上也能实现，等我熟悉思源代码后尝试实现一下）

@88250 D大，有空看看 @zxkmm 这个老哥的方案如何，论坛调研了一下，大部分用户还是支持优化的

@Vanessa219 来评估一下。

先看一下需求是不是这样：

• 全局锁定时
  • 文档无论解锁与否都进行锁定
  • 点击解锁/锁定都不进行保存
• 全局解锁时
  • 文档如果被锁定则不可编辑
  • 点击解锁/锁定都进行保存

@Vanessa219 老大您好。如果说的是我的方案的话，是的，大体如此。

全局锁定时, 文档无论解锁与否都进行锁定

是的，但是可以临时解锁。最好有文字提示，类似于这样：

点击解锁/锁定都不进行保存

是的，不把锁定状态保存到文档的属性（我这样设计是因为客观上如果遵循官方方案的话，用户回锁时候会有一种 “我只是回锁到之前的全局锁定” 的错觉，逻辑上不线性（一个单项开关感觉上有三种状态），无法回退）

全局解锁时, 文档如果被锁定则不可编辑

是的。 维持现状

全局解锁时, 点击解锁/锁定都进行保存

是的。 维持现状

目前 @Temacc0531 和社区一位用户同意我的方案是最好的。社区其他人怎么看待我不清楚。

全局锁定时，要能临时解锁，其他的正常

@Vanessa219 理解应该没啥问题，我再总结一下

• 全局状态和单篇状态互相独立
• 文档是否可编辑只取决于单篇状态
• 打开全局只读
  • 文档单篇默认锁定
  • 用户可以手动操作单篇状态，关闭文档后恢复默认锁定
• 关闭全局只读
  • 文档单篇默认解锁
  • 用户可以手动操作单篇状态，关闭文档后状态不变

回复 @Temacc0531 :

全局状态和单篇状态互相独立

这个似乎不是我的方案。我的方案不需要两个各文档属性值。我的方案只有一个单篇是否锁定的各文档属性值，没有全局是否锁定各文档属性值，因为全局锁定本来就是要全部锁定的，没有必要加一个各文档属性值。

关闭全局只读, 文档单篇默认解锁

这个似乎也不是我的方案。我的方案是，关闭全局只读后维持该文档的上锁现状， 不是关闭全局只读后把所有文档全都解锁一遍。这个一定要说明清楚。因为 “关闭全局只读后把文档全都解锁一遍“ 这个行为没有道理。任何单刀开关都不应该创造不能回退的行为。

用户可以手动操作单篇状态，关闭文档后状态不变

这个描述和您的其他描述是对的。

@zxkmm 根据建议我再补充一下

• 全局锁定时
  • 文档无论解锁与否都进行锁定
  • 点击解锁/锁定都不进行保存
  • 解除锁定文案修改为临时解除锁定
  • 锁定编辑文案修改为临时锁定编辑
• 全局解锁时
  • 文档如果被锁定则不可编辑
  • 点击解锁/锁定都进行保存
  • 文案不变

全局状态和单篇状态互相独立
这个似乎不是我的方案。我的方案不需要两个属性。我的方案只有一个单篇是否锁定属性，没有全局是否锁定属性，因为全局锁定本来就是要全部锁定的，没有必要加一个属性。

全局只读是需要另外一个字段去存这个属性的，它和单篇状态没有关系，所以我说的独立。和你说的不冲突

关闭全局只读, 文档单篇默认解锁
这个也不是我的方案。我的方案是关闭全局只读时维持属性现状， 不是关闭全局只读后把文档全都解锁一遍。这个一定要说明清楚。因为 “关闭全局只读后把文档全都解锁一遍“ 这个行为没有道理。任何单刀开关都不应该创造不能回退的行为。

这个是说文档的默认状态是解锁，例如新建，不是说关闭全局只读后会刷新的意思，下面一点说了用户操作单篇状态后就维持不变了

总体和你方案一致的

回复 @Vanessa219 ：

* 全局锁定时
  
    * 文档无论解锁与否都进行锁定[aka 不可编辑]  (文档无论**自身属性**解锁与否都进行锁定)
    * 点击解锁/锁定都不进行保存 （ok）
    * 解除锁定文案修改为临时解除锁定 (ok)
    * 锁定编辑文案修改为临时锁定编辑  (p.s.)
  	(文案建议按我的截图设计)

* 全局解锁时
  
    * 文档如果被锁定则不可编辑  (ok)
    * 点击解锁/锁定都进行保存 （ok）
    * 文案不变 （维持现在官方head的锁头那个图标就行）

是的。我的方案是这个意思。

^p.s.

锁定编辑文案修改为临时锁定编辑

这个文案可能写成 “取消临时解锁” 或者 “不再临时解锁” 会更清楚一点

side note:
其实我个人觉得全局锁定这个功能获取根本不需要，但是可能有用户确实需要吧。。。

@Temacc0531 谢谢您的澄清。我之前只是为了避免误会，所以我比较挑剔用词。抱歉。：） ^ ___^

• 全局锁定时
  • 解除锁定文案修改为临时解除锁定
  • 锁定编辑文案修改为临时锁定编辑

这个是不是按钮改叫临时锁定/临时解锁就可以了，文字太多也不好显示吧...

回复 @Temacc0531 :

这个是不是按钮改叫临时锁定/临时解锁就可以了，文字太多按钮也不好显示吧...

"临时锁定"这个称呼给人一种之后会重新解锁 的错觉（因为“临时” “锁定” 了）。但实际上这个操作是回退到全局锁定的锁定状态。
所以个人认为，要么直接不要这个按钮，反正效果和用户关闭文档（app）是一样的。要么留着这个功能但是用我那个逻辑清楚的文案（“取消临时解锁”）。
只是个人观点，具体的由开发者决定。

edit：
反正只要逻辑是正确的，关于界面和文案的细节由开发者决定就好

@Temacc0531 您可以看一下这个界面您觉得合不合适。

@zxkmm 我刚刚想岔了，以为现在的单篇状态是用【锁定/解锁】按钮来显示的，但其实就是个小锁头的图标。那我觉得打开全局只读后锁定和解锁都保持小锁头的图标和原来的一致就好（因为对于用户来说逻辑都是一致的，就是单篇小锁头打开可编辑，关闭不可编辑），提示的可以放在小锁头的悬浮文案里面，现在的文案是【锁定编辑/解除锁定】，可以在打开全局只读锁定后文案提示【锁定编辑/临时解锁】，因为实际只有解锁是临时的，锁定是持久的

上面的图我没太看懂😶

开了个投票。如果社区观点还是比较零散的话我个人感觉可以维持现状不用再改了。https://ld246.com/article/1700817185016

开了个投票。如果社区观点还是比较零散的话我个人感觉可以维持现状不用再改了。
关于全局锁定（只读）目前的暂定方案，请社区投票

个人感觉这个方案确实已经相当完善了

已修改，各位稍后可前往 dev 版本体验。

谢谢开发者！
已测试最新的dev build, 逻辑是对的。

关于锁头图标会代表四个状态（单篇解锁，单篇锁定，全局已锁, 临时解锁）的逻辑，虽然我个人觉得部分用户如果不读wiki用起来可能会比较困惑。但是考虑到简洁性和统一性，我尊重开发者的设计方案。后续基于这个逻辑我再想想有没有更合理的界面设计，如果有的话我会PR。

但是我有点摸不清楚三点菜单下的只读模式的默认选项是什么意思？ 启用和禁用看起来好像是控制单篇解锁与否的。那么为什么还要有一个默认？难道不应该只有锁与不锁两种状态吗？

默认是移除单个文档的只读设置，跟随全局设置。

默认是移除单个文档的只读设置，跟随全局设置。

这个【默认】和【禁用】是不是有点重复，单个文档禁用只读之后也是跟随全局设置来的

@Temacc0531 我也觉得好像是重复了，但我之前担心可能是我没搞懂所以我没敢回复😄🙏

收到，那就先不显示了。

@Vanessa219 v2.11.0 还有个小问题，关闭全局只读单个文档禁用只读状态（锁头解锁），只读模式里面显示的是【启用】，应该是【禁用】才对

收到，下个版本继续修改。