CN108959628A - 论坛管理方法 - Google Patents
论坛管理方法 Download PDFInfo
- Publication number
- CN108959628A CN108959628A CN201810814723.3A CN201810814723A CN108959628A CN 108959628 A CN108959628 A CN 108959628A CN 201810814723 A CN201810814723 A CN 201810814723A CN 108959628 A CN108959628 A CN 108959628A
- Authority
- CN
- China
- Prior art keywords
- role
- forum
- user
- board
- management
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000007726 management method Methods 0.000 title claims abstract description 135
- 238000012550 audit Methods 0.000 claims description 38
- 238000007789 sealing Methods 0.000 claims description 9
- 230000008859 change Effects 0.000 claims description 7
- 230000009471 action Effects 0.000 claims description 6
- 230000007306 turnover Effects 0.000 abstract description 7
- 238000013475 authorization Methods 0.000 description 21
- 238000000034 method Methods 0.000 description 20
- 238000004519 manufacturing process Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 230000007246 mechanism Effects 0.000 description 6
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000012552 review Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000007257 malfunction Effects 0.000 description 2
- 238000012827 research and development Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000005034 decoration Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 235000013399 edible fruits Nutrition 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 230000000366 juvenile effect Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000002715 modification method Methods 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/103—Workflow collaboration or project management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/105—Human resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/01—Social networking
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Marketing (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Operations Research (AREA)
- Computing Systems (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Storage Device Security (AREA)
Abstract
本发明公开了一种论坛管理方法,包括以下步骤:创建系统角色,所述角色是独立的个体,而非组/类;设置论坛版块,论坛中包含一个或多个论坛版块;设置各论坛版块的参与角色/管理角色,并设置参与角色/管理角色在论坛版块中的权限;将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限使用论坛,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色。本发明将论坛版块中的权限赋予给角色,员工通过对应的用户关联的角色获得其在论坛中的相应权限,员工离职或调岗时,能够实现无缝对接,不会出现论坛权限设置的滞后或遗漏,不会影响员工对论坛的正常访问,也规避了机密信息泄露的风险。
Description
技术领域
本发明涉及一种论坛管理方法。
背景技术
基于角色的访问控制(RBAC)是近年来研究最多、思想最成熟的一种数据库权限管理机制,它被认为是替代传统的强制访问控制(MAC)和自主访问控制(DAC)的理想候选。传统的自主访问控制的灵活性高但是安全性低,强制访问控制安全性高但是限制太强;基于角色的访问控制两者兼具,不仅易于管理而且降低了复杂性、成本和发生错误的概率,因而近年来得到了极大的发展。基于角色的访问控制(RBAC)的基本思想是根据企业组织视图中不同的职能岗位划分不同的角色,将数据库资源的访问权限封装在角色中,用户通过被赋予不同的角色来间接访问数据库资源。
在大型应用系统中往往都建有大量的表和视图,这使得对数据库资源的管理和授权变得十分复杂。由用户直接管理数据库资源的存取和权限的收授是十分困难的,它需要用户对数据库结构的了解非常透彻,并且熟悉SQL语言的使用,而且一旦应用系统结构或安全需求有所变动,都要进行大量复杂而繁琐的授权变动,非常容易出现一些意想不到的授权失误而引起的安全漏洞。因此,为大型应用系统设计一种简单、高效的权限管理方法已成为系统和系统用户的普遍需求。
基于角色的权限控制机制能够对系统的访问权限进行简单、高效的管理,极大地降低了系统权限管理的负担和代价,而且使得系统权限管理更加符合应用系统的业务管理规范。
然而,传统基于角色的用户权限管理均采用“角色对用户一对多”的关联机制,其“角色”为组/类性质,即一个角色可以同时对应/关联多个用户,角色类似于岗位/职位/工种等概念,这种关联机制下对用户权限的授权基本分为以下三种形式:1、如图1所示,直接对用户授权,缺点是工作量大、操作频繁且麻烦;当发生员工变动(如调岗、离职等),该员工涉及到的所有表单操作权限必须要作相应调整,特别是对于公司管理人员,其涉及到的表单权限多,权限调整的工作量大、繁杂,容易出错或遗漏,影响企业的正常运营,甚至造成不可预估的损失。
2、如图2所示,对角色(类/组/岗位/工种性质)进行授权(一个角色可以关联多个用户),用户通过角色获得权限,审批操作主体是组/类性质角色;3、如图3所示,以上两种方式结合。
以上的表述中,2、3均需要对类/组性质的角色进行授权,而通过类/组/岗位/工种性质的角色进行授权的方式有以下缺点:1、用户权限变化时的操作难:在实际的系统使用过程中,经常因为在运营过程中需要对用户的权限进行调整,比如:在处理员工权限变化时,角色关联的某个员工权限发生变化,我们不能因该个别员工权限的变化而改变整个角色的权限,因为该角色还关联了其他权限未变的员工。因此为了应对该种情况,要么创建新角色来满足该权限发生变化的员工,要么对该员工根据权限需求直接授权(脱离角色)。以上两种处理方式,在角色权限较多的情况下对角色授权不仅所需时间长,而且容易犯错,使用方操作起来繁琐又麻烦,也容易出错导致对系统使用方的损失。
员工/用户的表单操作权限发生变化时,要么员工/用户脱离角色,要么新增角色来满足工作要求。第一种方式的缺陷同上述“直接对用户授权”方式的缺陷。第二种方式,新增角色便涉及到角色的新建、关联、授权工作,特别在角色多、角色关联的用户也多的情况下,角色具体关联了哪些用户是很难记住的。
2、要长期记住角色包含的具体权限难:若角色的权限功能点比较多,时间一长,很难记住角色的具体权限,更难记住权限相近的角色之间的权限差别,相近角色的权限也很容易混淆;若要关联新的用户,无法准确判断应当如何选择关联。
3、因为用户权限变化,则会造成角色创建越来越多(若不创建新角色,则会大幅增加直接对用户的授权),更难分清各角色权限的具体差别。
4、调岗时,若要将被调岗用户的很多个权限分配给另外几个用户承担,则处理时必须将被调岗用户的这些权限区分开来,分别再创建角色来关联另外几个用户,这样的操作不仅复杂耗时,而且还很容易发生错误。
结合系统中企业内部论坛的管理而言,论坛要分版块,每个版块要限制参与人,如果不限制参与人,则公司敏感信息很可能被泄露。如论坛中有销售版块、生产版块、售后版块、财务版块、研发版块、公司战略版块、危机话题版块等,若公司战略版块的帖子大家都能看到,则公司的商业机密在论坛的讨论中很可能被泄密,还有如财务机密、核心技术机密等等。
传统系统对论坛用户的管理主要有三种模式:(1)直接设置论坛参与人和管理员(人、用户)的权限:对于职员数量较多的公司,调岗、入职发生频率高,每次发生调岗、入职都需要对员工在论坛中的权限进行设置,操作频繁,工作量大,且极易犯错。尤其致命的是:如果对员工的论坛权限设置滞后或遗漏,一方面会影响员工在论坛中的正常使用,另一方面可能导致公司机密信息的泄露,给企业带来不可预估的损失。如,现在张三做研发,授权了论坛中研发版块帖子的查看和删除权限,但过段时间其调去做销售,若不及时修改他的论坛权限,一方面会影响张三正常访问销售版块;另一方面,张三仍然能够查看和删除研发版块的帖子,有可能造成泄密,或者被恶意操作。员工新入职时,如果不及时为其设置论坛权限,会影响新员工对公司及工作岗位的了解或学习,可能会影响工作的开展。
(2)以工种授权:无法实现权限的精细化控制,容易导致信息泄露,例如:对销售工种授权,若一个系统中有飞机事业部销售论坛、家具事业部销售论坛等,若设置销售工种能够看到以上两个论坛版块,则为销售工种的家具事业部的销售员也能看到飞机事业部的销售论坛,显然这无法满足企业对论坛权限管理的需求,仍存在机密信息泄露的风险。
(3)以部门授权:无法适用于某些特定情形,容易导致信息泄露,例如:各部门可能存在多个工种,如销售部有销售工程师、协助销售工程师、准备资料的文员等,生产部有组装工人、测试工人等,若以部门进行授权,则会导致不同工种的人员在论坛版块中的权限一致,很容易导致信息泄露;另外部门内包括部门普通员工和部门主管,若只想让各部门的部门主管参与某个版块,采用该方式根本就无法实现。
设置管理人员若直接设置为人:现在张三从事的是销售管理工种,并负责了销售版块的管理(张三任销售版块的版主),现在张三调去做生产去了,应该让另外一人来接替张三对该销售版块的管理;若未及时设置,则张三仍能够看到论坛版块中公司后续的销售或市场信息资料,存在机密信息泄露的风险。另外一方面,若需要版主审核销售版块内新发的帖子,因为张三已经调离该岗位,自己不再负责,则可能认为没有必要再审核销售版块中待审核的帖子,会导致待审核的帖子不能及时审核,即使新任版主接手了该版块的管理工作,也无法审核此前提交的待审核帖子,因为该审核任务在张三那里。若审核者采用独立个体性质角色,则此前提交的待审核帖子的审核任务自动由该管理角色关联的用户对应的员工(新任版主)接收,由新任版主来审核。
发明内容
本发明的目的在于克服现有技术的不足,提供一种论坛管理方法,将论坛版块中的权限赋予给角色,员工通过对应的用户关联的角色获得其在论坛中的相应权限,员工离职时,直接由系统管理员(或相应管理员)取消该员工对应的用户与角色的关联,则该离职员工自动失去了访问论坛任何版块的权限,避免了企业机密信息泄露的风险;员工调岗时,直接由系统管理员(或相应管理员)取消该员工与原角色的关联,再关联新的角色即可自动获得该新角色在论坛中的权限,能够实现无缝对接,保证用户对论坛版块的权限得到及时更新,不会出现论坛权限设置的滞后或遗漏,不会影响员工对论坛的正常访问,也规避了机密信息泄露的风险;对于论坛管理人员而言,只需在前期设置好角色的论坛权限,在发生员工离职或调岗时都不再需要其进行任何操作,大大减少了论坛管理人员(或系统管理员/相应管理员)的工作量。
本发明的目的是通过以下技术方案来实现的:论坛管理方法,包括以下步骤:创建系统角色,所述角色是独立的个体,而非组/类;设置论坛版块,论坛中包含一个或多个论坛版块;设置各论坛版块的参与角色,并设置参与角色在论坛版块中的权限;将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限使用论坛,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色。“创建系统角色”步骤和“设置论坛版块”步骤不分先后顺序,另外:“将系统中的用户与角色相互关联”步骤在“创建系统角色”步骤之后即可。
所述参与角色在论坛版块中的权限包括对论坛版块内他人已发帖子/回帖的查看权限、在论坛版块内发帖的权限、在论坛版块内回帖的权限中的任意一种或多种的组合。
所述的角色归属于部门,该角色的名称在该部门下唯一,该角色的编号在系统中唯一,根据角色的工作内容对角色进行授权。
论坛管理方法,还包括一个用户跨部门调岗管理步骤,具体包括:(1)取消用户与原部门内的角色的关联;(2)将用户与新部门内的角色进行关联,用户自动获得该角色在论坛中的相应权限。
一个用户对应一个员工,一个员工对应一个用户,员工通过其对应的用户关联的角色确定(获得)权限;所述员工离职后冻结该员工对应的用户,当该员工再次入职后,解冻该员工此前的用户作为该员工当前的用户。用户在被冻结期间不能作为员工的对应用户。
论坛管理方法,包括以下步骤:创建系统角色,所述角色是独立的个体,而非组/类;设置论坛版块,论坛中包含一个或多个论坛版块;设置各论坛版块的管理角色,设置管理角色在论坛版块中的管理权限;将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限管理论坛,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色。“创建系统角色”步骤和“设置论坛版块”步骤不分先后顺序,另外:“将系统中的用户与角色相互关联”步骤在“创建系统角色”步骤之后即可。
所述的管理角色包括一级管理角色,一级管理角色在论坛版块中的管理权限包括对论坛版块内已发帖子/回帖的查看、修改、审核、删除权限中的任意一种或多种的组合;
或还包括二级管理角色,二级管理角色用于监督一级管理角色的管理操作。
所述二级管理角色在论坛版块中的管理权限包括对论坛版块内已发帖子的封存和解封,帖子被封存时,该帖子的所有回帖也被封存,只有二级管理角色能够查看被封存的帖子,解封后恢复到封存前的状态。
每个论坛版块有一个或多个一级管理角色,每个论坛版块有一个或多个二级管理角色。
论坛管理方法,还包括一个设置发帖审核通过率的步骤,在管理角色审核论坛版块内的发帖是否通过时,在指定时间内,发帖审核通过率=已给出审核结果且审核结果为通过的人数/已给出审核结果的总人数。以上表述中的审核方式也可以为审批方式。
本发明的有益效果是:(1)本发明将论坛版块中的权限赋予给角色,员工通过对应的用户关联的角色获得其在论坛中的相应权限,员工离职时,直接由系统管理员(或相应管理员)取消该员工对应的用户与角色的关联,则该离职员工自动失去了访问论坛任何版块的权限,避免了企业机密信息泄露的风险;员工调岗时,直接由系统管理员(或相应管理员)取消该员工对应的用户与原角色的关联,再关联新的角色即可自动获得该新角色在论坛中的权限,能够实现无缝对接,保证用户对论坛版块的权限得到及时更新,不会出现论坛权限设置的滞后或遗漏,不会影响员工对论坛的正常访问,也规避了机密信息泄露的风险;对于论坛管理人员或系统管理员(或相应管理员)而言,只需在前期设置好角色的论坛权限,在发生员工离职或调岗时都不再需要其进行任何操作(通过角色的关联就顺带实现了员工论坛中权限的切换),大大减少了论坛管理人员或系统管理员(或相应管理员)的工作量。
离职举例:论坛管理人员为“生产工人1”这一角色设置的论坛权限为:能够查看生产版块内的帖子和回帖内容,且能够在生产版块内发帖、回帖,员工张三对应的用户关联“生产工人1”时,张三则获得了该角色的论坛权限,张三离职时,系统管理员(或相应管理员)直接取消张三对应的用户与“生产工人1”这一角色的关联,则张三自动失去了访问论坛任何版块的权限(此前张三对应的用户只关联了“生产工人1”);新入职员工李四接替张三的工作内容时,直接让李四对应的用户关联“生产工人1”,则李四自动获得了“生产工人1”这一角色的论坛权限,无需再为李四重新设置论坛权限,操作简单快捷,大大减少了工作量。
调岗举例:员工张三要从生产部调岗到售后部,系统管理员(或相应管理员)取消张三对应的用户与原角色“生产工人1”的关联,再关联到售后部的新角色“售后服务人员3”,张三则自动获得了“售后服务人员3”这一角色的论坛权限。
(2)系统设有两级管理角色(一级、二级只是一种管理层级的表述,也可以以其他方式表述管理层级),一级管理角色(版主)对该版块的发帖、回帖等进行查看、修改、审核和删除,二级管理角色(超级版主)一般设置为管理层的高层或最高管理层或老板,便于了解论坛整体情况,作用在于:1、便于管理者了解、汇集信息;2、可以对论坛发帖、回帖的态度及内容起到正向的引导作用;3、公平,可以及时的督导,促使论坛版块版主在审核时公正、负责、认真。为什么有了版主还要设置超级版主,超级版主一般是高层或最高层,其更多的是监督的需要,而不会去具体操作,如删帖等都是由版主操作(进一步的,也可以设置超级版主除了特定权限外,还可以具有版主的部分或全部权限)。
发帖一般需要版主审核确认后才能发帖成功,有助于提高论坛内帖子质量,若质量不高的帖子太多,不仅浪费参与人查看时间,而且会影响参与人的参与意愿度。
二级管理角色具有封存和解封的操作权限,对于记载了重要敏感信息的帖子,一方面需要保留、不能删除,另一方面也不能让普通论坛用户看到,二级管理角色可以对这样的帖子进行封存,封存后只有二级管理角色能看到这个帖子的内容,满足企业经营过程中对此类特殊帖子的管理硬需求。
(3)发帖审核基本是所有论坛都具备的功能,然而现有技术中如果版主迟迟不给出帖子的审核意见,该帖子就无法获得审批结果也无法完成发帖,拖长了发帖审核的周期。
本申请将审核周期限制在指定时间内,计算出这段时间内的审核通过率,通过率达到设定标准则审核通过,通过率未达到设定标准则审核不通过,大大缩短了发帖审核的周期,提高了论坛管理效率。
(4)本申请角色对用户是一对一的关系,同一时段一个角色只能关联唯一的用户,一个用户关联一个或多个角色,这样做的好处是,只要将用户关联到角色即可获得权限(即用户获得其关联的角色的权限),而且角色的权限变更比传统机制中的用户权限变更要少得多。独立体性质(岗位号/工位号性质)的角色数量变化小,虽然员工流动大,但岗位号/工位号的变化小(甚至在一定时段内是没有变化的,即角色没有变化),这样将极大简化用户的权限管理,减少系统的开销。
(5)动态管理、入职调岗等的操作简单方便,效率高,可靠性高:入职/离职/调岗在权限管理中的应用简单,当员工/用户发生变化时不用重新设置权限,用户只需取消或关联角色即可:不再任职该角色的用户就取消该角色关联,接手任职该角色的用户关联该岗位号的角色,关联该角色的用户自动就获得了该角色的相关任务和操作权限,无需对角色进行重新授权,极大地提高了系统设置的效率、安全性和可靠性。
举例:因张三用户离职或调岗等原因,张三不再做“采购员3”这个角色的工作,则将张三取消与“采购员3”的关联;另外李四接手做“采购员3”这个角色的工作,只需将李四关联该角色,则李四自动获得了“采购员3”这个角色的权限和任务。
(6)传统的权限管理机制将角色定义为组、工种、类等性质,角色对用户是一对多的关系,在实际的系统使用过程中,因为在运营过程中经常需要对用户的权限进行调整,比如:在处理员工权限变化的时候,角色关联的某个员工的权限发生变化,我们不能因该个别员工权限的变化而改变整个角色的权限,因为该角色还关联了其他权限未变的员工。因此为了应对该种情况,要么创建新角色来满足该权限发生变化的员工,要么对该员工根据权限需求直接授权(脱离角色)。以上两种处理方式,在角色权限较多的情况下对角色授权不仅所需时间长,而且容易犯错,使用方操作起来繁琐又麻烦,也容易出错导致对系统使用方的损失。
但在本申请的方法下,因为角色是一个独立的个体,则可以选择改变角色权限即可达到目的。本申请的方法,虽然看起来在系统初始化时会增加工作量,但可以通过复制等方法,使其创建角色或授权的效率高于传统组/类性质的角色,因为不用考虑组/类性质角色在满足关联用户时的共通性,本申请方案会让权限设置清晰,明了;尤其是在系统使用一段时间后(用户/角色权限动态变化),该申请方案能为系统使用方大幅度提高系统使用中的权限管理效率,使动态授权更简单,更方便,更清晰、明了,提高权限设置的效率和可靠性。
(7)传统组/类性质的角色授权方法容易出错,本申请方法大幅降低了授权出错的几率,因为本申请方法只需考虑作为独立个体的角色,而不用考虑传统方法下关联该组性质角色的多个用户有哪些共通性。即使授权出错也只影响关联到该角色的那一个用户,而传统以组性质的角色则会影响关联到该角色的所有用户。即使出现权限授权错误,本申请的修正方法简单、时间短,而传统以组性质的角色在修正错误时需要考虑关联到该角色的所有用户的权限共通性,在功能点多的情况下不仅修改麻烦、复杂,非常容易出错,且很多情况下只能新创建角色才能解决。
(8)在传统以组为性质的角色授权方法下,若角色的权限功能点比较多,时间一长,很难记住角色的具体权限,更难记住权限相近的角色之间的权限差别,若要关联新的用户,无法准确判断应当如何选择关联。本申请方法的角色本身就具有岗位号/工位号的性质,选择一目了然。
(9)调岗时,若要将被调岗用户的很多个权限分配给另外几个用户承担,则处理时必须将被调岗用户的这些权限区分开来,分别再创建角色来关联另外几个用户,这样的操作不仅复杂耗时,而且还很容易发生错误。
本申请方法则为:被调岗用户关联了几个角色,在调岗时,首先取消用户与原部门内的角色的关联(被取消的这几个角色可以被重新关联给其他用户),然后将用户与新部门内的角色进行关联即可。操作简单,不会出错。
附图说明
图1为背景技术中系统直接对用户进行授权的方式示意图;
图2为背景技术中系统对组/类性质角色进行授权的方式示意图;
图3为背景技术中系统对用户直接授权和对组/类性质角色授权相结合的方式示意图;
图4为本发明系统通过独立个体性质角色对用户进行授权的方式示意图;
图5为本发明设置论坛版块参与角色的流程图;
图6为本发明设置论坛版块管理角色的流程图。
具体实施方式
下面结合附图进一步详细描述本发明的技术方案,但本发明的保护范围不局限于以下所述。
【实施例1】如图5所示,论坛管理方法,包括以下步骤:创建系统角色,所述角色是独立的个体,而非组/类;设置论坛版块/类别,论坛中包含一个或多个论坛版块/类别;为各论坛版块/类别设置参与角色(可设置一个或多个参与角色),并设置参与角色在论坛版块/类别中的权限(可一起或分别设置参与角色在论坛版块中的权限);所述参与角色在论坛版块/类别中的权限包括对论坛版块/类别内他人已发帖子/回帖的查看权限、在论坛版块/类别内发帖的权限、在论坛版块/类别内回帖的权限。
将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限使用论坛,如图4所示,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色,一个用户对应一个员工,一个员工对应一个用户,员工通过其对应的用户关联的角色确定(获得)权限。
参与角色参与讨论的帖子将记录以下信息:发帖内容、发帖时间、发帖角色、角色关联的用户对应的员工等。
参与角色能够查看其被授权的论坛版块的相关内容。
本实施例将论坛版块中的权限赋予给角色,员工通过对应的用户关联的角色获得其在论坛中的相应权限,员工离职时,直接由系统管理员(或相应管理员)取消该员工对应的用户与角色的关联,则该离职员工自动失去了访问论坛任何版块的权限,避免了企业机密信息泄露的风险;员工调岗时,直接由系统管理员(或相应管理员)取消该员工对应的用户与原角色的关联,再关联新的角色即可自动获得该新角色在论坛中的权限,能够实现无缝对接,保证用户对论坛版块的权限得到及时更新,不会出现论坛权限设置的滞后或遗漏,不会影响员工对论坛的正常访问,也规避了机密信息泄露的风险;对于论坛管理人员或系统管理员(或相应管理员)而言,只需在前期设置好角色的论坛权限,在发生员工离职或调岗时都不再需要其进行任何操作,大大减少了论坛管理人员或系统管理员(或相应管理员)的工作量。
离职举例:论坛管理人员为“生产工人1”这一角色设置的论坛权限为:能够查看生产版块内的帖子和回帖内容,且能够在生产版块内发帖、回帖,员工张三对应的用户关联“生产工人1”时,张三则获得了该角色的论坛权限,张三离职时,系统管理员(或相应管理员)直接取消张三对应的用户与“生产工人1”这一角色的关联,则张三自动失去了访问论坛任何版块的权限;新入职员工李四接替张三的工作内容时,直接让李四对应的用户关联“生产工人1”,则李四自动获得了“生产工人1”这一角色的论坛权限,无需再为李四重新设置论坛权限,操作简单快捷,大大减少了工作量。
调岗举例:员工张三要从生产部调岗到售后部,系统管理员(或相应管理员)取消张三对应的用户与原角色“生产工人1”的关联,再关联到售后部的新角色“售后服务人员3”,张三则自动获得了“售后服务人员3”这一角色的论坛权限。
【实施例2】如图5所示,论坛管理方法,包括以下步骤:创建系统角色,所述角色是独立的个体,而非组/类;设置论坛版块/类别,论坛中包含一个或多个论坛版块/类别;设置角色能够参与的论坛版块/类别,并设置参与角色在论坛版块中的权限;所述参与角色在论坛版块中的权限包括对论坛版块内他人已发帖子/回帖的查看权限、在论坛版块内发帖的权限、在论坛版块内回帖的权限。
将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限使用论坛,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色,一个用户对应一个员工,一个员工对应一个用户,员工通过其对应的用户关联的角色确定(获得)权限。
本实施例中,所述的角色归属于部门,该角色的名称在该部门下唯一,该角色的编号在系统中唯一,根据角色的工作内容对角色进行授权。
如果用户需要跨部门调岗,还包括一个用户跨部门调岗管理步骤,具体包括:(1)取消用户与原部门内的角色的关联;(2)将用户与新部门内的角色进行关联,用户自动获得该角色在论坛中的相应权限。
【实施例3】如图6所示,论坛管理方法,包括以下步骤:创建系统角色,所述角色是独立的个体,而非组/类;设置论坛版块,论坛中包含一个或多个论坛版块;为各论坛版块设置管理角色,设置管理角色在论坛版块中的管理权限;将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限管理论坛,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色。
本实施例中,所述的管理角色包括一级管理角色(版主)和二级管理角色(超级版主),版主在论坛版块中的管理权限包括对论坛版块内已发帖子/回帖的查看、修改、审核、删除权限;超级版主用于监督一级管理角色的管理操作。二级管理角色可以是一级管理角色中选出的一个或多个,也可以将其他角色直接设置为二级管理角色(超级版主)。
系统设有两级管理角色,一级管理角色(版主)对该版块的发帖、回帖等进行修改、审核和删除,二级管理角色(超级版主)一般设置为管理层的高层或最高管理层或老板,便于了解论坛整体情况,作用在于:1、便于管理者了解、汇集信息;2、可以对论坛发帖、回帖的态度及内容起到正向的引导作用;3、公平,可以及时的督导,促使论坛版块版主在审核时公正、负责、认真。为什么有了版主还要设置超级版主,超级版主一般是高层或最高层,其更多的是监督的需要,而不会(不用)去具体操作,如删帖等都是由版主操作。
【实施例4】如图6所示,论坛管理方法,包括以下步骤:创建系统角色,所述角色是独立的个体,而非组/类;设置论坛版块,论坛中包含一个或多个论坛版块;设置哪些角色能够成为论坛版块的管理角色,设置管理角色在论坛版块中的管理权限;将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限管理论坛,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色。
本实施例中,所述的管理角色包括一级管理角色(版主)和二级管理角色(超级版主),版主在论坛版块中的管理权限包括对论坛版块内已发帖子/回帖的查看、修改、审核、删除权限;超级版主用于监督一级管理角色的管理操作。
所述二级管理角色在论坛版块中的管理权限包括对论坛版块内已发帖子的封存和解封,帖子被封存时,该帖子的所有回帖也被封存,只有二级管理角色能够查看被封存的帖子,解封后恢复到封存前的状态。二级管理角色具有封存和解封的操作权限,对于记载了重要敏感信息的帖子,一方面需要保留、不能删除,另一方面也不能让普通论坛用户看到,二级管理角色可以对这样的帖子进行封存,封存后只有二级管理角色能看到这个帖子的内容,满足企业经营过程中对此类特殊帖子的管理硬需求。
【实施例5】如图6所示,论坛管理方法,包括以下步骤:创建系统角色,所述角色是独立的个体,而非组/类;设置论坛版块,论坛中包含一个或多个论坛版块;设置哪些角色能够成为论坛版块的管理角色,设置管理角色在论坛版块中的管理权限;将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限管理论坛,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色。
发帖一般需要版主审核确认后才能发帖成功,有助于提高论坛内帖子质量,若质量不高的帖子太多,不仅浪费参与人查看时间,而且会影响参与人的参与意愿度。
在审核帖子过程中,还包括一个设置发帖审核通过率的步骤,在管理角色审核论坛版块内的发帖是否通过时,在指定时间内(指定时间段的设置可以自己定义),发帖审核通过率=已给出审核结果且审核结果为通过的人数/已给出审核结果的总人数。
发帖审核基本是所有论坛都具备的功能,然而现有技术中如果版主迟迟不给出帖子的审核意见,该帖子就无法获得审批结果也无法完成发帖,拖长了发帖审核的周期。
本申请将审核周期限制在指定时间内,计算出这段时间内的审核通过率,通过率达到设定标准则审核通过,通过率未达到设定标准则审核不通过,大大缩短了发帖审核的周期,提高了论坛管理效率。
上述实施例中,如图4所示,本申请论坛参与者和管理者都为独立个体性质角色,以下对通过独立个体性质角色对用户进行授权所具备的优势进行分析:用户通过其与角色的关联确定(获得)权限,如果要修改用户的权限,通过调整角色所拥有的权限以达到改变关联了该角色的用户的权限的目的。一旦用户关联角色后,该用户就拥有了该角色的所有操作权限。
角色对用户的关系为一对一(该角色与一个用户关联时,其他用户则不能再关联该角色;若该角色未被用户关联,则可以被其他用户选择关联;即同一时段,一个角色能且只能被一个用户关联)。用户对角色的关系为一对多(一个用户可以同时关联多个角色)。
角色的定义:角色不具有组/类/类别/岗位/职位/工种等性质,而是一个非集合的性质,角色具有唯一性,角色是独立存在的独立个体;在企事业单位应用中相当于岗位号(此处的岗位号非岗位,一个岗位同时可能有多个员工,而同一时段一个岗位号只能对应一个员工)。
举例:某个公司系统中可创建如下角色:总经理、副总经理1、副总经理2、北京销售一部经理、北京销售二部经理、北京销售三部经理、上海销售工程师1、上海销售工程师2、上海销售工程师3、上海销售工程师4、上海销售工程师5……用户与角色的关联关系:若该公司员工张三任职该公司副总经理2,同时任职北京销售一部经理,则张三需要关联的角色为副总经理2和北京销售一部经理,张三拥有了这两个角色的权限。
传统角色的概念是组/类/岗位/职位/工种性质,一个角色能够对应多个用户。而本申请“角色”的概念相当于岗位号/工位号,也类同于影视剧中的角色:一个角色在同一时段(童年、少年、中年……)只能由一个演员来饰演,而一个演员可能会分饰多角。
在创建角色之后,可以在创建用户的过程中关联角色,也可以在用户创建完成后随时进行关联。用户关联角色后可以随时解除与角色的关联关系,也可以随时建立与其他角色的关联关系。
所述角色的构成为:岗位名+岗内编号。例如:车间生产工人1、车间生产工人2、车间生产工人3……角色是独立个体,相当于岗位号、工位号的概念,不同于传统权限管理体系中的角色,传统体系中角色的概念是岗位/职位/工种等的组/类性质。
以下举例员工张三进入某公司后,员工、用户与角色之间的关系为:1、新入职:员工新入职,直接为该用户(员工)选择相应的岗位号/工位号的角色进行关联即可,例:张三入职公司(公司为张三分配了一个张三用户),工作内容是在销售一部,负责北京区域冰箱产品的销售(对应的角色是销售一部下的“销售工程师5”这个角色),则张三用户直接选择“销售工程师5”这个角色关联即可。
2、增加职位:张三工作一段时间后,公司还安排张三负责北京区域电视产品的销售(对应的角色是销售一部下的“销售工程师8”这个角色)并兼任售后部主管(对应售后部主管1这个角色),则张三用户再增加关联销售一部下的“销售工程师8”和售后部下的“售后部主管1”这两个角色,此时,张三员工关联了三个角色,分别为销售一部下的“销售工程师5”、“销售工程师8”和售后部下的“售后部主管1”,张三用户则拥有了这三个角色的权限。
3、减少职位:又过了一段时间,公司决定让张三任职售后部经理(对应售后部下“售后部经理”这个角色),且不再兼任其他工作。则张三用户关联售后部下“售后部经理”这个角色,同时取消此前关联的三个角色(销售一部下的“销售工程师5”、“销售工程师8”和售后部下的“售后部主管1”),此时,张三用户只拥有售后部下“售后部经理”这个角色的权限。
4、角色权限的调整(针对角色本身所拥有的权限的调整):如公司决定增加售后部经理的权限,则只需增加对售后部经理这个角色的授权即可,则张三用户因为售后部经理这个角色的权限增加了,张三用户的权限也增加了。
5、离职:一年后,张三离职了,则取消张三用户与售后部下“售后部经理”这个角色的关联即可。
举例:公司在动态的经营中,职员的入职、离职是经常持续发生的,但岗位号/工位号的变化非常少(甚至在一定时期内是没有变化的)。
传统授权方法:在系统功能点多的情况下,以传统的组/类性质的角色进行授权,不仅授权工作量大,繁杂,而且很容易出错,甚至出错了在短时间内都不容易发现,容易对系统使用方造成损失。
本申请授权方法:本申请是对岗位号/工位号性质的角色进行授权,用户关联角色而确定(获得)权限,则对用户权限的控制,通过简单的用户-角色的关联关系来实现,让权限控制变得简单、易操作,清晰明了,大幅度提高了授权效率和授权可靠性。
若需要,还可以在参与者(版块的参与者)中设置一个游客(一个类型为游客)参与,则除了设置的角色关联的系统用户对应的员工能够参与外,其他系统游客也能够访问论坛,可将该论坛用于外部的讨论,如客户论坛模块或游客论坛模块:让客户或任意游客都能够参与(公司设置的系统用户对应的员工当然也能够参与,员工若通过系统用户参与,则需要判断员工对应的用户关联的角色是否有权限参与,若不通过系统用户而是直接以游客参与,则不需要判断员工对应的用户关联的角色是否有权限参与),再由版主进行管理,能够收集客户或游客的信息。
以上所述仅是本发明的优选实施方式,应当理解本发明并非局限于本文所披露的形式,不应看作是对其他实施例的排除,而可用于各种其他组合、修改和环境,并能够在本文所述构想范围内,通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围,则都应在本发明所附权利要求的保护范围内。
Claims (10)
1.论坛管理方法,其特征在于,包括以下步骤:
创建系统角色,所述角色是独立的个体,而非组/类;
设置论坛版块,论坛中包含一个或多个论坛版块;
设置各论坛版块的参与角色,并设置参与角色在论坛版块中的权限;
将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限使用论坛,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色。
2.根据权利要求1所述的论坛管理方法,其特征在于:所述参与角色在论坛版块中的权限包括对论坛版块内他人已发帖子/回帖的查看权限、在论坛版块内发帖的权限、在论坛版块内回帖的权限中的任意一种或多种的组合。
3.根据权利要求1所述的论坛管理方法,其特征在于:所述的角色归属于部门,该角色的名称在该部门下唯一,该角色的编号在系统中唯一,根据角色的工作内容对角色进行授权。
4.根据权利要求3所述的论坛管理方法,其特征在于:还包括一个用户跨部门调岗管理步骤,具体包括:
(1)取消用户与原部门内的角色的关联;
(2)将用户与新部门内的角色进行关联,用户自动获得该角色在论坛中的相应权限。
5.根据权利要求1所述的论坛管理方法,其特征在于:一个用户对应一个员工,一个员工对应一个用户,员工通过其对应的用户关联的角色确定权限。
6.论坛管理方法,其特征在于,包括以下步骤:
创建系统角色,所述角色是独立的个体,而非组/类;
设置论坛版块,论坛中包含一个或多个论坛版块;
设置各论坛版块的管理角色,设置管理角色在论坛版块中的管理权限;
将系统中的用户与角色相互关联,用户根据其关联的角色在论坛中的权限管理论坛,同一时段一个角色只能关联唯一的用户,而一个用户关联一个或多个角色。
7.根据权利要求6所述的论坛管理方法,其特征在于:所述的管理角色包括一级管理角色,一级管理角色在论坛版块中的管理权限包括对论坛版块内已发帖子/回帖的查看、修改、审核、删除权限中的任意一种或多种的组合;
或还包括二级管理角色,二级管理角色用于监督一级管理角色的管理操作。
8.根据权利要求7所述的论坛管理方法,其特征在于:所述二级管理角色在论坛版块中的管理权限包括对论坛版块内已发帖子的封存和解封,帖子被封存时,该帖子的所有回帖也被封存,只有二级管理角色能够查看被封存的帖子,解封后恢复到封存前的状态。
9.根据权利要求7所述的论坛管理方法,其特征在于:每个论坛版块有一个或多个一级管理角色,每个论坛版块有一个或多个二级管理角色。
10.根据权利要求9所述的论坛管理方法,其特征在于:还包括一个设置发帖审核通过率的步骤,在管理角色审核论坛版块内的发帖是否通过时,在指定时间内,发帖审核通过率=已给出审核结果且审核结果为通过的人数/已给出审核结果的总人数。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710603812.9A CN107451792A (zh) | 2017-07-24 | 2017-07-24 | 论坛管理方法 |
CN2017106038129 | 2017-07-24 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN108959628A true CN108959628A (zh) | 2018-12-07 |
Family
ID=60487383
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710603812.9A Pending CN107451792A (zh) | 2017-07-24 | 2017-07-24 | 论坛管理方法 |
CN201810814723.3A Pending CN108959628A (zh) | 2017-07-24 | 2018-07-23 | 论坛管理方法 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710603812.9A Pending CN107451792A (zh) | 2017-07-24 | 2017-07-24 | 论坛管理方法 |
Country Status (2)
Country | Link |
---|---|
CN (2) | CN107451792A (zh) |
WO (1) | WO2019019980A1 (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107451792A (zh) * | 2017-07-24 | 2017-12-08 | 成都牵牛草信息技术有限公司 | 论坛管理方法 |
CN107465672A (zh) | 2017-07-28 | 2017-12-12 | 成都牵牛草信息技术有限公司 | 系统中用户/员工获取邮箱账号的方法 |
CN111027032B (zh) * | 2019-11-13 | 2022-07-26 | 北京字节跳动网络技术有限公司 | 一种权限管理的方法、装置、介质和电子设备 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN201111137Y (zh) * | 2007-08-24 | 2008-09-03 | 上海全成通信技术有限公司 | 一种岗位授权装置 |
CN101373527A (zh) * | 2007-08-24 | 2009-02-25 | 上海全成通信技术有限公司 | 系统参与人的权限控制方法 |
CN103903093A (zh) * | 2014-03-25 | 2014-07-02 | 沈阳化工大学 | 一种人事信息管理系统 |
CN105912924A (zh) * | 2016-04-01 | 2016-08-31 | 北京元心科技有限公司 | 对企业信息管理系统中的用户账户下发权限的方法 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8402514B1 (en) * | 2006-11-17 | 2013-03-19 | Network Appliance, Inc. | Hierarchy-aware role-based access control |
CN102468971A (zh) * | 2010-11-04 | 2012-05-23 | 北京北方微电子基地设备工艺研究中心有限责任公司 | 权限管理方法和装置、权限控制方法和装置 |
CN106803138A (zh) * | 2015-11-26 | 2017-06-06 | 北京奥鹏远程教育中心有限公司 | 一种运维服务子系统 |
CN107451792A (zh) * | 2017-07-24 | 2017-12-08 | 成都牵牛草信息技术有限公司 | 论坛管理方法 |
-
2017
- 2017-07-24 CN CN201710603812.9A patent/CN107451792A/zh active Pending
-
2018
- 2018-07-23 CN CN201810814723.3A patent/CN108959628A/zh active Pending
- 2018-07-23 WO PCT/CN2018/096712 patent/WO2019019980A1/zh active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN201111137Y (zh) * | 2007-08-24 | 2008-09-03 | 上海全成通信技术有限公司 | 一种岗位授权装置 |
CN101373527A (zh) * | 2007-08-24 | 2009-02-25 | 上海全成通信技术有限公司 | 系统参与人的权限控制方法 |
CN103903093A (zh) * | 2014-03-25 | 2014-07-02 | 沈阳化工大学 | 一种人事信息管理系统 |
CN105912924A (zh) * | 2016-04-01 | 2016-08-31 | 北京元心科技有限公司 | 对企业信息管理系统中的用户账户下发权限的方法 |
Non-Patent Citations (1)
Title |
---|
聂宜军: ""咨询指南:eHR系统人岗分配关系建模,一岗多人 Vs 一岗一人,孰优孰劣?"", 《HTTPS://MP.WEIXIN.QQ.COM/S/Q9ZEYBOUHYDCUT-RQENZ8A》 * |
Also Published As
Publication number | Publication date |
---|---|
CN107451792A (zh) | 2017-12-08 |
WO2019019980A1 (zh) | 2019-01-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109086627A (zh) | 表单数据操作的审核方法 | |
CN108805532A (zh) | 工作流审批节点高效审批方法 | |
CN108694557A (zh) | 工作流及其审批节点的表单字段操作权限的设定方法 | |
CN108876313A (zh) | 系统中用户在信息交流单元的权限的设置方法 | |
CN108764691A (zh) | 基于会签的审批节点在审批流程中的设置方法 | |
CN108984715A (zh) | 基于依据字段设置审批流程的方法 | |
CN108734400A (zh) | 工作流审批节点按角色设置审批角色的方法 | |
CN108764833A (zh) | 工作流审批节点按部门设置审批角色的方法 | |
CN109214150A (zh) | 基于角色的表单操作权限授权方法 | |
CN109167755A (zh) | 管理系统中即时通讯账号的管理方法 | |
CN107180334A (zh) | 基于角色对用户一对一的工作流控制方法和系统 | |
CN108920915A (zh) | 表单字段值操作权限授权方法 | |
CN109032458A (zh) | 基于角色获取的表单数据的授权方法 | |
CN108932610A (zh) | 一种系统派工方法 | |
CN108921520A (zh) | 统计列表操作权限授权方法 | |
CN109165524A (zh) | 基于改进型rbac权限控制机制的审批任务转交方法 | |
CN108804948A (zh) | 一种表单的关联信息授权方法 | |
CN109102253A (zh) | 审批者针对审批任务征询参考意见的方法 | |
CN108898693A (zh) | 一种系统的考勤设置方法 | |
CN109104425A (zh) | 基于时间段的操作记录查看权限的设置方法 | |
CN108959628A (zh) | 论坛管理方法 | |
CN108711037A (zh) | 审批工作流的委托及其再委托方法 | |
CN108958870A (zh) | 快捷功能设置方法 | |
CN108985659A (zh) | 对使用者进行审批流程及其审批节点授权的方法 | |
CN109087001A (zh) | 监察审批操作、授权操作及表单操作的方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |