Django-CRM 总结2
Django-Crm总结第二篇
1. 什么是CRM系统，具有哪些功能
-
客户关系管理系统(customer relationship managerment)，记录跟客户的相关记录信息
-
功能
# 登录 注册 注销 --认证 1.客户的管理 客户信息展示(公私户的转换) 新增 编辑 删除客户信息 公私户的转换 2.客户的跟进记录管理 查询当前销售的所有的跟进记录 查询某个客户的所有的跟进记录 对跟进记录进行增删改 3.报名记录管理 查询当前销售的所有客户的报名表 查询某个客户的报名表 报名表的增删改 4.缴费记录管理 查看当前销售的所有客户的所有缴费记录 查看某个客户的所有缴费记录 缴费记录的增删改 5.班级记录 查看所有的班级记录 对班级记录进行增删改 6.课程记录 查看某个班级的课程记录 对课程记录进行增删改 7.学习记录,记录学生的学习情况,是否正常出勤,是否正常完成作业 查看某个课程的所有学生的学习记录 对学习记录进行增删改
什么是公户?什么是私户?
公户:尚未分配销售的客户,属于公户
私户:已分配到销售,属于某个销售的客户
区分公户和私户,可以明确该客户是否有销售跟进,若是公户,则需要尽快分配到相关销售去做跟进工作,
# 目的： 若是私户,则其他销售无权访问,以免造成撞单现象.
通过ORM操作对数据库的数据做展示时,不同字段类型有不同的展示方法
# 模板遍历 ORM对象
{%for obj in all_obj%}
# 假设name为字段
1.普通字段
{{obj.name}}
2.带有choices参数
{{obj.get_name_display}}
3.自定义
在models对应的类下,自定义一个方法,供调用,主要是对于多对多的情况下
def show_name(self):
return '{}_OK'.format(self.name)
列举出CRM项目中的技术点
1.分页功能
2.Form组件(modelform) 对表进行增删改查
3.模糊查询(Q对象)
4.分页保留源搜索条件(QueryDict)
5.url命令和反向解析
6.修改或新增后跳转到原界面
7.加锁,事务 公私户的转换
8.批量插入学习记录
7.限制choice的选择
8.登录的密码二次校验
9.给密码加密haslib
10.中间件,登录校验,登录成功后返回原网址
11.母版的继承
12.自定义temple_tag
几张表来完成权限控制？每张表中有哪些字段？
# 6张表
# menu 菜单表
(id,name,icon,weight)
# permission 权限表
(id,url title name icon menu parent)
# role 角色表
(id,name permissions)
# user 用户表
(id,username password roles)
# user与role的多对多关系表， 使用户和角色存在多对多关系！
(id user_id role_id)
# role与permission的多对多的关系表 ， 使角色和权限存在多对多关系！
(id role_id permission_id)
简述实现权限控制的流程
# 给不同的用户分配不同的功能,这里主要阐述的是基于角色的权限控制rbac(role based access control)
# 在web开发中,一个url就可以看做是一个权限
控制流程:
1.要实现权限控制需要有表[一个简单的权限控制,需要6张表]
2.登录成功后查询当前用户的权限信息,保存在session中，也可以存到redis中
3.利用中间件进行权限校验 process_request中间件，请求到来之前进行权限校验。
3.1 根据当前访问的url和session中存放的权限进行正则匹配,匹配成功,则按照正常流程走,匹配不成功则,告知未有访问的权限。
3.2 页面中可见的按钮代表也有权限,在模板设置中,根据filter进行判断,若返回true则代表有权限,若返回False则代表无权限
4.动态生成一级菜单
5.动态生成二级菜单,对一级菜单进行排序
6.二级菜单默认选中并展示
7.非菜单权限的归属(二级菜单和子权限,都有选中的效果)
8.路径导航
9.权限控制到按钮级别
初始化权限时,定义了两个字典,分别是什么数据结构?为什么要把他们存在session中
# 全局权限表
permission_dict={
# permissions__name 权限名称
permissions__name:{
url:"路由地址",
title:"菜单标题",
parent_id:"权限id",
permissions__parent_name:"父权限名称（标题）",
permissions__parent_id:"父权限id"
}
}
# 全局权限菜单表
menu_dict={
一级菜单的id:{
title:"菜单标题",
icon:"菜单图标",
children:{} # 二级（子级）菜单{title:"菜单标题",icon:"菜单图标", children:{} # 三级（子级）菜单}
}
}
保存在sessions是为了在进行权限校验和菜单展示时通过request调用session保存在服务器上安全
开发过程中遇到,一般都是怎么解决的?
业务需求的变化是在开发过程中遇到的比较棘手的问题,之前做过一个CRM项目,做语言培训的,一开始我们理解的
需求是一个语言合同是由一个老师一对一对学生进行授课,项目已经开发的差不多的时候,需求方突然想起来说
他们的学生有时候不是一个老师授课的,可能会有其他老师帮着一起,我们的表结构是以合同对授课老师多对一的关系
这样的需求就需要先从数据库表改起,后来改成一个授课记录跟授课老师是多对一的关系,这样就可以通过提取每个老师的授课
记录来计算课时,而不是通过合同来计算课时了,像这种很细小的需求经常会遇到,前期对接的时候说的都是正常情况下
后期开发的时候说的都是特殊情况下也可以这样,规则不明朗,很不好弄!
简述下管理权限信息的流程(管理 分配权限是如何操作的）
1. 可以通过admin 即：django-admin模块。进行角色的新增,菜单的新增,权限的分配
2. 也可以通过设计权限分配的批量操作来实现
简述如何将rbac应用到一个项目中
1. 先把rbac的文件拷贝到项目中,并注册该APP
2.迁移数据库
修改rbac中User,把permissions=models.ManyToMany(Role,...)Role的引号去掉
在class Meta中添加:abstract = True 迁移时不生成表,继承使用
在crm中引入rbac的User from rbac.models importUser
让UserProfile继承User
执行数据库迁移的命令
python manage.py makemigrations
pyton manage.py migrate
3.配置rbac的路由
url(r'^rbac/',include('rbac.urls',namespace='rbac))
4.把rbac中的admin中User表去掉
5.把自定义的中间件(登录认证先取消),然后添加角色,菜单,批量操作权限,中间涉及到使用User表都需要改成UserProfile
6.分配权限,给用户分配角色,给角色分配权限
7.应用上角色
把权限校验的中间件添加上,也把登录认证的添加上
在settings中添加几个常量
白名单
免认证名单
权限session key
菜单session key
登录权限的初始化,在登录成功后添加
from rbac.service.init_permission import init_permission
init_permission(request,obj)
8.动态生成二级菜单
在母版中添加{%load rbac%} {% menu request%}
加上css js样式
9.路径导航 {%breadcrumb%}
10.权限控制到按钮级别
在模板中:{%load rbac%}
在需要控制的按钮下写上:
{%if request|has_permission:'add_customer'%}
显示
{%endif%}
rbac组件中有哪些技术点,用于做什么
1.中间件
权限校验
权限控制到按钮级别
2.登录
获取权限
构建权限列表和菜单列表
保存在session中
非菜单权限的归属
3.模板
动态生成二级菜单 dymaic menu
路径导航 # 面包屑导航
权限控制到按钮级别 # button permission
表字段粒度级别 # table field permission
母版和继承 templates extend
