为什么需要按照应用区分组织结构和角色，用户？

大家为什么需要按照应用区分组织结构和角色，用户？
我一直理解一个公司应该只有一套组织结构，所有的应用应该都是基于一套用户和组织结构；
但是大家一直都希望组织结构等信息安装应有设置，想了解一下大家的使用场景；
所以我想听一下大家具体使用场景，也好给理解大家的想法，更好的安排功能

看了一圈，谁都没说到点儿上

胡布斯是纳闷儿，把组织机构绑在应用上，为什么会有这样的需求呢？

其实特别简单

我给你讲一个故事哈，在很久很久以前……





一个活字格的用户，好不容易开发了一个应用出来，卖给了一家企业，这时，产生了三方：活字格官方，活字格的开发者，应用的使用者。

从活字格的开发者的心态来说，他不希望最终用户知道活字格，因为太简单了，客户如果拿到了工程文件，很可能自己搞了，最终用户越是小企业才越会鸡贼，我这里说鸡贼并没有骂街的意思啊，只是对一种行为方式的形容，什么叫鸡贼呢？就是客户有冲动甩掉开发者自己干，总怕开发者挣了他的钱了，完全不顾开发者付出了多大的努力。如果最终用户是大企业，本着各管一摊，又有合同约束，反而会跟开发者长期合作而不会甩掉开发者，因为甩掉开发者的风险极大，万一审计、巡查来了，有开发者挡着还有个甩锅的，你把开发者甩了，锅你就自己背着吧。

好了，因为最终用户是个小企业，可以说是一点儿技术能力都没有，这个小企业可能是一家出租车公司（说到这儿，胡爷是不是有感觉了？），可能是一个小机械厂，可能是一个小食品作坊，这个”小“，可能只有几个人，也可能有个十几、二十来人，也可能会有一定的组织机构，而且小企业往往还愿意搞出一套机构来，好让他的甲方觉得他很正规，以此树立合作的信心。

因为这个小企业没有技术能力，就会委托开发者来进行部署和运维，而开发者也很愿意在研发的基础上再挣一份服务器运维的钱，还有最重要的——

以下才是最最重要的——

开发者不愿意把工程文件交付给甲方，由甲方的技术人员安装部署。你知道把工程文件交付给甲方意味着什么吗？意味着开发者自尽了，因为这个工程文件必然会流出去，开发者辛辛苦苦的劳动，轻易地被人拿走了。

正是这个原因，所以，开发者会怎么办呢？

开发者会租用一台云服务器，向活字格官方购买相应的用户数，然后帮助（或者说代替）甲方把工程文件发布在云服务器上，并向甲方提供运维服务。当然，用户数、服务器的租金最终都是由甲方来承担的，本着雁过拔毛的原则，开发者肯定会加一点点价的，但是这可绝对不可耻，我相信加的那一点点价，真的是一点点，就如同冬夜天桥上卖头绳的老奶奶加的那点价一样，连糊口的钱都算不上。

而在这整个过程中，甲方都始终不知道活字格官方的存在。

在传统商业上，开发者相当于零售商，活字格相当于厂家，最终用户相当于顾客。零售商当然不希望顾客直接从厂家购买了，对不？

可是，这也并不能说，就需要把组织机构和用户绑定到应用上啊？

不，现在开发者碰到了一个麻烦。

我们可爱的甲方，我们的最终用户，只肯付出5个用户的授权价格，这时，开发者就尴尬了， 因为开发者从活字格官方购买授权数时，是一口气儿买了20个的，现在客户只肯出5个用户的钱，这怎么办？

其实这难不倒开发者，开发者只要能再找到一个客户，再做出一个应用来，而这个客户肯付出 15个用户，那么开发者就能把所有的用户数都卖出去了。

这个客户还真被开发者找到了，第二个应用也顺利开发出来了，而顺利部署上线了。

此时，在这台开发者租用的服务器上，有活字格的20个用户授权，部署了两个应用，一个应用5个用户，另一个应用15个用户，一个应用对应着一个做微商的宝妈，另一个应用对应着一个异型轴承加工厂。

突然有一天，那个做微商的宝妈家的布偶猫跳上了键盘，宝妈的电脑没有如愿进入她的客户界面，而是出现了一个轴承……

这就是原因。

你再往下想啊，开发者是继续再开发另外一个新的应用更好呢，还是把这两个已经开发完了，各有了一个用户的，已经部署上线的应用——再卖出一份去更好呢？

哪个策略对开发者来说是更优解？

万幸，开发者又卖出去了一份，又有一个类似业务的轴承企业购买了开发者的应用，开发者又向活字格官方购买了20个用户授权，并且分配给第二家轴承厂了15个用户数，这时，在这台服务器上，已经有3个应用了，一个宝妈的CRM，两个轴承厂的工艺数据应用，还有开发者手上没有消耗掉的5个用户授权。

这时，开发者发现，他可能碰到麻烦了，因为，两个轴承厂各有各的组织机构，而活字格的服务器只有一套组织机构和用户系统。

开发者向活字格官方反映了这个问题，可是反馈的信息给开发者感觉却是官方在敷衍他，而且官方也并没有真的想解决这个问题。

好在这个问题通过一些骚操作还是能解决的，只是手工赋权麻烦一些罢了，而且有一个轴承厂总换人，向开发者提了好几次了能不能向他们开放，让他们自己就能管理用户。开发者心说，不行啊，你一登录管理控制台，有哪些用户不全者看见了吗？只能各种敷衍用户。

而另一边，胡爷一边喝着咖啡一边纳着闷儿，一边自言自语：“我就奇了怪了啊，你说，吃不上饭，他为什么不吃肉糜呢？“

按照应用使用不同的组织架构 角色 以及用户.这是要做成平台的形式?

针对使用群体不同部署多个项目的时候，特别在项目开发人员不同时，角色、人员容易混淆，区分的时候不好区分，容易造成项目之间的相互干扰，角色混乱

一个公司就是一个组织架构，一套用户。只有想做saas应用才需要隔离。

对活字格这种，在企业内部有多个小应用，有些时候甚至是部门级的应用，如果没有比较好的隔离体系，会有不少管理上的尴尬。
这个东西真的是可以不用，但不可以没有。

KAN3 发表于 2022-7-1 11:52
对活字格这种，在企业内部有多个小应用，有些时候甚至是部门级的应用，如果没有比较好的隔离体系，会有不少 ...

一套的话，隔离那都不是事，只要组织架构-角色-用户，合理的权限设计好了，一个库能N多个不同部门的应用隔离，那都是一句话的事，页面可以绑定部门，部门又是组织架构的一环，这种权限分配后，该页面只有该部门的人可以看到和使用。

我复制粘贴一下啊
首先1、保留活字格原用户中心，改为设计者中心，只有设计者可以登录，用来提供web服务，应用公有服务，以及应用库管理功能，2、设计新用户管理中心，按应用库单独分配用户，3、将新用户中心像活字格新工作流一样集成内置到设计器上，4、形成以组织架构->角色->用户的权限思路，5、权限分配全面页面化，前端化，将基础权限设计为类型流程条类型的固定结构，设计者只需要选中后排版，自己给权限条上的控件配置权限命令即可，再配个图

确实有的行业或者某些企业运行需要这种多架构，比如对外来说是两个主体公司，对内实际上就一个实际行动公司加一个走账的公司，实际运行公司的人员在这俩公司都有任职，在实际运行公司他是人力主管，可能在哪个走账的皮包公司那就是办公室主任。

个人认为没有必要。
组织机构又没有规定只能设几层。上面设个总公司，下面你爱设置多少公司都可以。角色、用户你带上公司名也行啊。

授权是按用户或并发来的，设多少用户得买多少。

小公司不需要这个，但是能不能考虑同一套用户下面的这些应用能共用数据库吖，每次都说到这个就说可以外联数据库来实现，但活字格广告词不是开发成本低，非专业开发者也能定制企业级应用，结果现在还得学数据库