如何安全“锁定”你的Excel在线表格
1102
2022-07-03
近年来,在线协作表格因不受使用设备、地理位置限制以及团队之间能实时共享数据的优势被广泛使用。在线协作表格最大的缺点就是:编辑好的数据很容易被他人随意改动,多人同时编辑同一表格,部分敏感信息也很容易被泄露。所以,在线表格中的权限管理显得尤为重要。
在日常生活中,经常需要使用到在线表格来收集信息,如学校中的新生报名登记、学籍登记等,而收集这些信息,都需要学生或家长填写身份证、住址、联系方式等,这些信息都涉及到个人隐私,且经过多人填写后,难以控制个人信息是否被泄露。
在日常的工作中,即便是同一个公司管理的表格,各部门之间能查看、编辑表格的权限都是不同的。如在门店管理中,针对进销存管理类型的表格,只需要让店长看到成本价,而店员却不能,那么,有没有一款软件既可以实现团队之间的在线协作,又能针对不同的部门、不同的人员进行权限设置呢?
电子表格的权限管理在表格软件中非常重要,尤其是有些公司已经利用表格软件实现了业务表格化。表格中是权限的优化和细分,公司里则是更加明确的职权分配,善用表格系统工作将会更简单。
多人协作在线文档的概念,最早由 Google Docs 带入中国。但实际上,在日常工作中,与团队的其他人进行协作是一种在常见不过的工作方式。
由于工作分工、工作进展的不同,团队内部的信息往往需要及时同步,然而伴随着团队经营规模的不断扩大,在线协同、多人协作,以及软件项目管理等问题将会接踵而至,成为制约企业高效发展的瓶颈。
这些问题,通常表现为:
跨部门、地区协作不便
过度依赖文件夹共享的形式,不能确保文档的安全性
没法纪录和体现职工对文本文档的意见和评价
文档记录发生变更时,无法及时通知到相关部门和员工
文档无法在线协同编辑,缺失必要的流程管控
多人共同编辑一个文档,无法留存修改记录和历史版本
针对上述问题,目前最佳的解决方案是:使用一款可多人在线协同办公的软件或工具。市面上,这类软件有很多,比如国外的 Google Docs、Office365,以及国内的腾讯文档、石墨文档、有道云协作等。
本文将不再过多赘述这类成品软件,而是深入协同办公系统的实现原理,从企业 IT 管理者的角度出发,深入研究多人协作的形式、基础和难点,分析一款开发工具应具备怎样的特点,才是实现多人协作“在线 excel”系统的关键。
以下内容,节选自葡萄城公开课《如何实现可多人协作的“在线 excel”系统?》,欢迎大家提前预约,届时观看:https://live.vhall.com/483759540
多人协作的历史十分悠久,起源于静态的多人协作模式,即每个人先完成自己的工作,然后再进行汇总。
递增式协作
邮件:你来我往
论坛:跟帖回复
独占式协作
文档传递
微软 VSS
合并式协作
SVN
Git
diff,patch,merge 指令
静态协作的比喻
拼接画
积木
静态协作的特点
多版本
块操作
有协作动作
静态协作的缺点
版本碎片化
缺乏时效性
协作动作成本高
静态多人协作的成本,会随着加入人数和项目的复杂度呈几何级数的增长。因此,对于企业来说,急需一种无协作动作、唯一版本、版本可控的无协作成本模式,即动态多人协作模式。
动态协作的比喻
一起画黑板
动态协作的特点
唯一版本
原子操作
无协作动作
动态协作的优点
版本可控
实时
无协作成本
典型产品
Office Online
石墨
OnlyOffice
任何信息,无论其是什么展现形式,如果要做到多人实时编辑与展现,只需要实现以下三步而已:
操作化
可传输
可还原
操作化,指任何信息都可以转换为一组操作的集合。很容易理解,但它仍有不少值得思考的点:
1. 分割与组合
如何保证:信息的所有变化都可以分解为操作的集合?反之,操作如何覆盖出信息的所有变化?
分割的颗粒度如何决定?
粗一点?
细一点?
如何兼顾解释性与扩展性?
2. 绝对操作与相对操作
绝对操作
针孔打印机的完美世界
打印机时代的编辑噩梦
相对操作
4K 电视不是梦
为什么数字电视稳定性不如模拟电视
绝对操作与相对操作比喻:时间与空间的互换
3. 使用一款开发工具:SpreadJS,实现操作化的优势:
好用的指令集,保证覆盖信息的全部变化与操作的集合
经过实践验证的颗粒度,完美兼顾解释性与扩展性平衡
可传输,就是指操作有办法通过网络传输给其他终端。实现动态多人协作,需要考虑以下几点:
1. 传输内容
原始文本
清晰
冗余
压缩技术
逻辑压缩
协议压缩
手动压缩
2. 网络协议
Socket
TCP
UDP
HTTP
WebSocket
3. QoS(Quality of Service,服务质量)
快速失败
自动回滚
自动重连
自动恢复
可还原,就是指接收到来自网络的操作消息后,可以在本地完全一致地再次执行该操作。可还原包括了:
1. 绝对操作的还原
控制体积
合理的提示
2. 相对操作的还原
严格的顺序性
从源头保障顺序性
顺序性的补救
3. 本地操作的还原
过滤收到的操作集合
从源头细化操作颗粒
本地保存本地执行
4. 无入侵的还原
定义入侵
排除入侵
千人千面
乱序的表现形式如下图,小明在客户端执行了一系列操作,传递到服务器时发生乱序,导致小花看到了截然不同的信息:
为了解决乱序问题,可以尝试以下方法:
用性能换取顺序正确——基于协议
用性能换取顺序正确——基于回执
1. 基于协议
优点
可靠,历经考验
简单,无需开发
缺点
资源开销高
必须整套使用
2. 基于回执
优点
自主可控,按需开发
资源开销可控
缺点
需要自己投入开发
应用层逻辑控制使得网络复杂度向外蔓延
复杂度带来维护成本
网络不是绝对可靠的,为了实现相对可靠,需要付出一定的代价,企业需要考虑的是:如何衡量所付出的代价与产出成正比。
比乱序更高级的一种表现形式,存在多向、多维度等问题。
原则:任何一次不一致,都会导致后续的操作基于错误的信息进行,从而不断扩大错误,造成无法收拾的结果。因此,不一致是不能被容忍的。 解决办法:
严格一致性:独占
最终一致性:检查与修复
非技术手段:设计与提示
独占就是同一时间同一范围只能由一人操作。
1. 范围(以 SpreadJS 为例)
整个表格,类似 VSS
工作表
单元格范围
2. 排他性
独占冲突时,必有一方被弹开
直到占有者解开,不然无法占用
占用前无法操作
原理和锁基本一致
3. 优点
可以确保严格一致性,不会产生多版本的错误累积
比起修复恢复这类弥补手段,一开始就不出错的成本最低
逻辑清楚简单,开发维护成本低
4. 缺点
静态协作的味道
独占动作严重影响体验
大幅降低协作效率
5. SpreadJS 提供的支持
锁定工作表
锁定单元格
基于唯一正确顺序,察觉客户端的错误,撤销错误操作后重新执行正确的操作。
1. 唯一正确
服务器到达顺序
协作边界分流
P2P+选举算法
2. 察觉错误
服务器回执 id
服务器回执操作,MS
3. 撤销错误
撤销到错误发生前的一步操作的结果
利用 SpreadJS 的撤销功能
利用操作版本快照
4. 重新执行
操作队列需保存
区分好无感知执行与显式执行
技术手段追求错误 0 发生,而非技术手段则可以降低错误发生的可能性。
1. 选中框
非常重要但不显眼
人性化的独占
操作的预期
协作感
SpreadJS 提供高度可自定义的边框
2. 协作设计
设计协作区域与合并手段
设置权限
SpreadJS 提供几乎 Excel 的所有公式
SpreadJS 提供了工作表和单元格锁定功能
3. 单向协作
区分单向与双向协作的场景
对单向协作尽量放开
对双向协作严谨设计
首先,可以明确一点:SpreadJS 完全可以用作多人协作系统开发的组件。原因在于:
SpreadJS 的产品质量是毋庸置疑的
SpreadJS 在设计之初,便考虑到了多人协作的可能,而除此之外,绝大多数的前端产品都不是为了多人协作而设计的
多人协作需要中心系统的支持,SpreadJS 基于纯前端的体系架构可以很容易的嵌入系统开发,而无需过多考虑与原生系统的兼容性,这是常规组件是无法做到的
要实现多人协作,需要投入一定的开发成本,SpreadJS 作为一款开发工具,可以有效帮助开发人员减轻代码量
多人协作表格的本质:
Server – Clients 中心系统,类似数值敏感的小型网游
任何这类系统都是在体验和正确性中寻求平衡
多人协作表格的特点:
表格的数值敏感性高于网游,数据操作和存储的挑战更大
表格的计算复杂度更高,尤其涉及复杂公式嵌套与全量统计筛选
Web 存在天花板,所以复杂的页游并不多见,端游较多
SpreadJS 已经可以很好地支持多人协作的最终一致性。如果能支持多人多撤销队列,或者撤销重做自定义,那么就可以给用户提供更加易用且多样化的体验效果,从此丝般顺滑不是梦。
SpreadJS 的绝大部分功能是支持命令的,这使得操作化变得更简单。如果 SpreadJS 能开放命令自定义,便可以让自主控制颗粒度成为可能,用户可以针对具体的业务逻辑做出更加精细化的操作转换,大幅提高协作效率。
SpreadJS 不仅在数据录入、数据填报等方面表现出强大的功能,其各类统计分析与图形化手段也是一个不少,一旦明年的透视表功能上线,使用 SpreadJS 开发在线协同系统的数据商业价值将更易体现,用户将体验到“表格”无限的魅力与威力。
表格在多人协作中的数据量增长速度比单人使用时快得多,希望 SpreadJS 可以支持更大的数据量,尤其是在大数据量情况下仍旧保持操作的性能与体验。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。