发表于: 2019-06-03 20:35:36

1 674


今天完成的事情:
任务6的总结和深度思考;
1.后台实现前台的内容修改、编辑、查看等功能的系统,对信息进行创建、存储、处理的地方,也叫管理系统。
企业管理系统,是指能够体现企业管理的大部分职能(包括决策、计划、组织、领导、监控、分析等等),能够提供实时、相关、准确、完整的数据,为管理者提供决策依据的一种软件。以模块划分,企业管理软件可分为财务管理、车间管理进销存管理(ERP)、资产管理成本管理、设备管理、质量管理、分销资源计划管理、人力资源管理(HR)、供应链管理(SCM)、客户关系管理(CRM)等品种。
我给后台分成两种,一种是to c 产品(前端产品)的后台,还有一种是b端产品(后端产品),也就是企业管理系统;
前者的使用者多为C端产品的运营、产品经理等,后者的使用者多为企业员工,比如人力资源管理的使用者就是企业的HR;
所以根据产品前后端的不同,产品经理也分前后端:
前端产品经理的关键词在于:用户、场景、体验、转化、价值挖掘。在根据用户和市场挖掘需求。
后端产品经理的关键词在于:业务、逻辑、跨越、结构、控制、数据。在根据业务和发展规划需求。
2.后台管理主要分为四个部分,模块管理角色管理密码修改账户管理
2.1模块管理:模块是单独的一个功能,平台由多个模块集成,可以使用多个功能。模块管理即对多个模块进行管理。
2.1.1模块管理功能:a.对各个模块增删改 分类排序   b.对各个功能模块启用停用
2.1.2模块列表名词:
a.id:数据库分给后台每个模块的唯一编码
b.名称:后台对每个模块的命名
c.URL:域名,IP,资源类型-存放资源的主机域名-资源文件名
d.父节点:功能或模块的上一级,朋友圈的点赞功能,点赞功能朋友圈功能的子节点,朋友圈是点赞功能的父节点
e.icon:装饰后台管理模块
f.排序:对模块列表进行排序
2.2账户管理:对后台账户体系中的所有账户进行增删改,包括用户名、密码和角色。只有权限高的账户才会有账户管理功能
2.2.1账户管理分类:对内账户(对内部人员设立的账户,给部分权限,可以对前台后台进行权限内操作),对外账户(用户管理,在前台注册的用户,自动形成用户列表,可以对用户列表进行操作)
2.2.2 账户管理和用户管理的区别:账户包括对内的和对外的,用户只是对外的,即前台自行注册的账号,对内的是管理员生成的
2.3角色管理:用户——角色——权限,用户身上多个角色,角色身上有不同的权限,对用户进行角色的赋予修改收回
2.3.1角色:
a.角色是对后台权限的分组
b.每个权限都是单独存在,角色是不同特定权限的组合
c.角色是权限的载体
d.将所有权限分类,不同角色授予不同权限
2.3.2权限设计
a.用户-角色-权限,给角色设置权限,然后用户更替
b.用户-职位-角色-权限,一个用户下可以设置多个职位,一个职位只能对应一个角色。
2.4密码修改:权限高的账户能修改所有账户的密码,包括自己;权限低的只能修改自己的
3.后台的作用以及后台怎么设计才好?
实现前台的内容修改、编辑、查看等功能的系统,对信息进行创建、存储、处理的地方;
这里我们只考虑C端产品的后台,不考虑后端产品,如果想找后端产品的工作,比如ERP,可以深入了解学习;
后台设计的基础原则:可视化原则、数据源原则、控制性原则、内部设置原则
可视化原则:对后台数据统计内容进行查看(允许各种维度的查看,不允许操作),遵循可视化原则常见的功能,包括我们的多维度筛选、排序、到处、数据明细、饼状图、折线图等,都符合可视化设计原则,用最合适的方法,提高我们查看信息的效率
数据源原则:典型特征在于新增,不具备新增功能的后台是不符合数据源原则的,这表示该产品几乎不具备可运营能力,运营也无法通过后台对产品的内容、风险、活跃度进行干预。数据源原则便是要求我们后台要具备”生产新内容“的能力。
控制性原则:后台操作人员能够对用户的部分信息进行修改,属于保护机制,在用户发出不好的内容可以有所作为。在保护内容生态的同时,当用户执行了某些不可逆操作时,我们也需要保护。
内部设置原则:最常见的内部设置是我们的权限系统,与面向用户的产品毫无关系。这部分功能的设计对象仅仅是明确操作者的权限范围。内部设置原则更多的是服务于后台产品本身的功能,他和用户,和我们面向用户的产品没有任何关系。
总结:可视化原则的设计对象是我们看不见的信息,数据源原则的设计对象是新建内容,控制性原则的设计对象是用户及用户生产的内容,内部设置原则的涉及对象更多的是后台本身的功能。
简单来说,就是第一我要可以查看到前端存储的数据,通过筛选等方式提高查看效率,第二运营可以新增内容,第三管理员可以修改用户的部分信息,第四就是可以管理后台的账户和权限;所以后台最基本的就是后台管理模块和内容管理模块两部分。
4.后台设计中的Content(Article)表是为了解决什么问题,在前台什么样的功能可以用Content处理?
Content就是内容管理,主要的作用前台内容格式一样,定制化需求低的时候,如:公告,banner,侧边栏通知,联系我们,常见问题等功能,其实这些功能只不过是前台渲染方式不同,后台编辑时完全可以定义成通用的标题、摘要、内容、缩略图、跳转链接等,可以提高复用性和降低开发成本,也满足产品运营的需求;
例如:banner,后台可以自定义一些通用字段,对每条详情可以进行上下架、编辑、删除等操作,也可以新增;
5.后台里的角色,用户,模块之间的关系是什么,如果加入部门,岗位又该怎么设计?如果支持用户有多个角色,怎么处理? 
角色是权限的集合,所以在后台里,角色决定了用户可以对后台中的哪些模块进行哪些操作;
加入部门,可以在RBAC的模型基础上进行扩展,加入用户组的概念,给账户分配角色,再把账户加入到用户组,也就是部门中,这样用户除了本身拥有的角色权限以外,还拥有所属用户组的所有权限,用户组的概念可以更方便的给群体账户授权,且不影响到账户本身拥有的角色权限;岗位存在于部门下,你在哪个岗位就拥有哪个岗位对应的角色,所以岗位和角色是一对一的关系;
想要用户有多个角色,前提是这些角色是不是互斥的,比如一份文件的审批流程中,你不能既是提交者又是审批者;
6.权限的维度一般是怎么样的,如果是限定在对某一个模块的细粒度操作控制怎么办?比如说限制只能读,不能编辑,应该怎么设计?
权限分为页面权限、操作权限、数据权限;
一般的较为简单的设计会将权限关联到摸个模块或者页面,角色获取相关权限的页面访问权,如有设计需求可以将模块、页面的按钮权限关联给角色;基本上是以单元拆份,以业务逻辑配置;
可以将每个对象的增删改查各作为一个基本的权限单元,从设计上达到低耦合以及模块化;但是在实际业务中可能 有些操作是一体的,不便于拆开分权限,可以让前端进行渲染时打包成一个整体进行提供配置,比如增删改打包成操作权限;
此外,角色与权限之间的关系并不仅限于角色是否有这个权限,还应该包括对该权限的数据访问程度;比如数据范围,用户拥有查看人员列表的权限,但只能查看自己部门的;拥有数据边界线制:一个高级管理员最多能增添5个初级管理员;拥有数据字段限制,普通员工只能看到报表中零件的数量,经理可以看到报表中零件的数量和单价;
7.为什么要设立角色,账户是否可以允许有多个角色?权限为什么不直接分配给账户? 
角色是对后台权限的分组 ;每个权限都是单独存在,角色是不同特定权限的组合  ;角色是权限的载体 ;将所有权限分类,不同角色授予不同权限.
一个账户可以有多个角色,一个角色可以有多个账户。
权限如果直接分配给账户,在账户更替或者权限分配收回的时候就十分麻烦,过程繁琐,工作量巨大。
明天计划的事情
1、任务6应该没啥问题了,开始任务7;
2、后面找时间把之前的任务也梳理总结一下;
遇到的问题:
1、今天上午看了几位师兄任务6的日报,发现自己任务6学的深度和知识点的掌握还是不够。此外发现自己虽然做到任务6,但是对以往做的任务缺少深度的思考和总结,没有复盘,所以今天将任务6中所有的知识点重新梳理了一遍,包括任务6后面的深度思考,形成总结;
收获:
1、对后台管理系统和权限有了更深的理解;



返回列表 返回列表
评论

    分享到