好像没说到底要怎么做呀。

LZ的意思是量身定制，LZ的名字蛮个性的。

>老老实实将它包括在实际的工作流里，利用WF这样基础的工作流平台的快速便捷性，降低项目开发、管理、维护成本

老老实实写代码就无所谓方法论了，这样的写法是提高开发管理和维护的成本。
如果老老实实写，软件可能还在二进制时代呢。

--引用-------------------------------------------------- haio,: >老老实实将它包括在实际的工作流里，利用WF这样基础的工作流平台的快速便捷性，降低项目开发、管理、维护成本 老老实实写代码就无所谓方法论了，这样的写法是提高开发管理和维护的成本。如果老老实实写，软件可能还在二进制时代呢。 --------------------------------------------------------


呵呵，抽象、去耦是要有前提条件的，有些东西本身就很难去耦，又何必去做得不偿失的事情？

Denning的A Lattice Model of Secure Information Flow算不算把权限管理抽象出来了？

说白了，lz就是不想做这个东西。

--引用-------------------------------------------------- yushih: Denning的A Lattice Model of Secure Information Flow算不算把权限管理抽象出来了？ --------------------------------------------------------


恩，能否简单说一下这个模型以及如何应用？能否屏蔽需求变化。

--引用-------------------------------------------------- kiler: 说白了，lz就是不想做这个东西。 --------------------------------------------------------


呵呵，这都被你猜到了。

--引用-------------------------------------------------- kiler: 说白了，lz就是不想做这个东西。 --------------------------------------------------------


其实我很想弄一套权限框架出来，这样以后就省力了，每次都弄一套难道就省力？关键问题是权限实际上是用户资源和表单资源的相互关联，每套系统这些东西都是不一样的，即便你将权限操作从工作流里挖出来，真的就能去耦了吗？需求的改变难道不会影响抽象出来的这个权限模块？如果影响了，那你这种将一个变化点分割成两个变化点的做法是否妥当？是否真的就比死写每个工作流代码量少？还是比死写清晰易于维护？

听听大家意见。

权限是一定可以做成通用的，我就实现一半了。

如果我在做几个工作流方面的项目，那么就可以吧剩下的一半也做出来。

http://www.cnblogs.com/jyk/category/134224.html

我的权限。

@王弈博
与工作流相关联的权限要做好确实不是一个容易的事情，在做好这个权限前必须先做好一个东西能实现一个自定义电子表单模块，以及对于业务数据字段的管理。只有把前面这个东西做好以后才能做出一个比较完美的工作流权限框架。将来要是sharepoint比较成熟了，可以考虑直接调用sharepoint的list的api，这样可以省不少事。

看一看这个.
http://framework.supesoft.com

学习

--引用-------------------------------------------------- kiler: @王弈博与工作流相关联的权限要做好确实不是一个容易的事情，在做好这个权限前必须先做好一个东西能实现一个自定义电子表单模块，以及对于业务数据字段的管理。只有把前面这个东西做好以后才能做出一个比较完美的工作流权限框架。将来要是sharepoint比较成熟了，可以考虑直接调用sharepoint的list的api，这样可以省不少事。 --------------------------------------------------------


恩，是这样的，必须能有效地抽象和管理业务数据字段，有关这方面的问题我会继续深入，希望能提出新的想法供大家讨论。

@金色海洋（jyk）


你那个权限管理模块很清楚，通用性上也不错。

只是你这个权限系统属于“方法级”的权限，也就是说可以有效的定义和管理那种用户可以执行什么样的操作。但有的时候权限需求是很细的，比如有的客户会有这样的要求：金额小于1000时，科级干部可以直接审批，大于1000时，必须申报上级部门，支付日期小于3天的需要总经理审批，大于3天的需要副经理批准。

这样的权限需求是很细的，细到表单的字段。其实我文章一开始的意思就是说：如果面对这样细致的权限需求，可能传统的权限框架就应付不过来了。你可以分离出这样的模块来，但始终你必须面对和实际业务体系的强相关性，如何有效的管理和抽象而不至于导致将一个变化点分割为两个变化点是个很棘手的问题。

我的思路就是，还原权限管理本来的位置，将用户资料看成和表单一样的资源来处理，死写在每个版本的工作流里。

上面kiler的建议是不错的，我会继续思考这一问题。

前两天看这篇文章，没看明白，今天看了你上个回复，才搞清楚，你把一些概念搞混了。

你开篇提到ERP的权限，这个权限是数据访问的权限，控制用户能访问到那些数据，能修改那些数据。

你在上个回复中的提到的不同的级别审批不同的金额，是审批的权限，控制流程的流转。

这两个权限是概念就是完全不同的，实现的方法也是完全不同的，但都是可以实现的。

--引用-------------------------------------------------- walter1: 前两天看这篇文章，没看明白，今天看了你上个回复，才搞清楚，你把一些概念搞混了。 你开篇提到ERP的权限，这个权限是数据访问的权限，控制用户能访问到那些数据，能修改那些数据。 你在上个回复中的提到的不同的级别审批不同的金额，是审批的权限，控制流程的流转。 这两个权限是概念就是完全不同的，实现的方法也是完全不同的，但都是可以实现的。 --------------------------------------------------------


恩，我知道你的意思，但这两者本质是相同的，只是一个是针对方法、大的资源集合级别的，比方说只能由财务经理使用查询所有职员的工资的功能，但现在客户需求变了，变成“财务经理查看所有非总经理亲戚员工工资的信息”和“总经理查看所有自家亲戚员工的工资”，而你原来的数据库表的设计肯定没想到用户会有这样变态的需求，你仍旧是一张员工工资表。你说这是属于流程的还是属于权限的？那如果做成两张表，一张是“普通员工的”，一张是“领导亲戚”，那这样是权限的还是流程的?

权限实质上定义的是资源之间的相互作用关系，本质上就是流程的，只是一般的应用场景粒度大，每个流程都需要权限认证这一过程，所以你容易分割，将它独立出来统一管理，可当粒度一旦精细，你如何处理？我的观点就是，如果涉及非常精细的权限需求，不如将权限认证还原到本来的地方。

如何处理涉及到资源的粒度问题，但无论资源是一个数据库，还是一张表，还是一张表中某个字段相同的一类数据，权限都是属于流程的，并不是你说的针对几张表的权限就叫权限，针对一张表中某个字段相同的一类数据就不叫权限而叫流程了。照你的理解，我可以轻易的将资源的粒度变换一下，这时候你原来所理解的流程控制是不是又变成你所理解的权限控制了？

最重要的认识就是：权限认证本质上就是用户资源和其他资源之间的相互作用关系，是流程的！能不能分割出来是要看具体环境的。

不知道我有没有说清楚。

还有就是你说的那个“审批的权限”，审批是用户发起的，在做架构设计时应该是：“审批流程中各种用户的操作权限控制”，仍然是处理用户资源和表单资源之间关系的问题。

我一直研究这些东西，有5-6年的经验了，很通用的东西，我手上就有，
若有兴趣，可以联系我

不知道大家的权限控制到那个级别的,目前我做到的系统,权限只控制到列...不知道那位大家把权限能动态的控到的行...还请指教呀

实现一个系统首先要确定目标和采用的方法。

目标就是实现当前的共性的需求，太个性化的需求只能按项目定制，不应该做到平台里；

方法是把复杂的问题分解成几个相对简单的问题，分散解决。
1、审批权限
就是一张部门经理、流程的审批权限表，某个部门经理审批后，从这张表里取出他对该流程的权限，在流程中和某个预设值比较，不同的结果走不同的分支。
2、页面的打开权限
这个大家差不多，有权限的可以看见页面，没有的看不见。
3、页面内的操作权限
这部分是页面内实现的，根据权限显示相应的功能按钮，甚至于可以控制到字段级。

我们实现的平台里包括了以上的三类权限控制，已经用在了四、五个项目，除了第3点需要少量的代码，其他都不需要。

所以你想把三个做到一起，在我看来这种方法是不适合的，另外你提到的那些特殊的需求，也不适合实现为通用的，而应该订制。

--引用-------------------------------------------------- walter1: 实现一个系统首先要确定目标和采用的方法。 目标就是实现当前的共性的需求，太个性化的需求只能按项目定制，不应该做到平台里； 方法是把复杂的问题分解成几个相对简单的问题，分散解决。 1、审批权限就是一张部门经理、流程的审批权限表，某个部门经理审批后，从这张表里取出他对该流程的权限，在流程中和某个预设值比较，不同的结果走不同的分支。 2、页面的打开权限这个大家差不多，有权限的可以看见页面，没有的看不见。 3、页面内的操作权限这部分是页面内实现的，根据权限显示相应的功能按钮，甚至于可以控制到字段级。 我们实现的平台里包括了以上的三类权限控制，已经用在了四、五个项目，除了第3点需要少量的代码，其他都不需要。 所以你想把三个做到一起，在我看来这种方法是不适合的，另外你提到的那些特殊的需求，也不适合实现为通用的，而应该订制。 --------------------------------------------------------


恩，是这样的，受教了，呵呵。

上文有个小错误，
第1点中的预设值，应该是业务中传入的某个字段值。