项目实训记录（六）——标准删除相关操作

目录

一、最近做了什么？

二、标准删除相关操作导致的逻辑修改

1.标准和申请在数据库的展示形式

2.业务流程

３.删除发布的管理员端逻辑

4.删除发布的用户端逻辑

一、最近做了什么？

五月底，还是在进行系统功能的完善。

首先是用户端的ｂｕｇ问题，也就是ａｘｉｏｓ异步通信的问题，之前的博客介绍过了。有兴趣可以看看。

然后是管理员端的删除、修改已发布标准部分。因为修改比较容易实现，所以主要是删除发布的一些逻辑。然后删除发布也会导致用户端前端逻辑的一些变化。

所以这篇文章主要来复现一下管理员端和用户端的逻辑问题。

二、标准删除相关操作导致的逻辑修改

1.标准和申请在数据库的展示形式

标准：

申请：

 

 上图可以看到用户申请含有ｐｉｄ（也就是发布id字段）。所以当发布删除时，用户逻辑也要有修改

2.业务流程

ｓｔｅｐ１：管理员选择相应数据库相应数据表的相应字段发布标准。

ｓｔｅｐ２：用户查找到相应发布。并点击申请。

ｓｔｅｐ３：管理员审核用户申请。

ｓｔｅｐ４：如果用户申请被管理员通过。用户可以查看该申请详情。当用户点击查看该申请的密钥时，该申请开始计时。未达到失效时间时，用户可以点击操作；达到失效时间时，系统提示已失效，无法进行操作。

ｓｔｅｐ５：管理员删除该发布。

ｓｔｅｐ６：用户点击查看申请详情时，系统提示发布已删除。

３.删除发布的管理员端逻辑

ｓｔｅｐ１：将用户申请表中等于该被删除发布ｉｄ的数据的ｐｉｄ修改为-1。

ｓｔｅｐ2：删除Pinfo表（发布信息表）中相关行

ｓｔｅｐ3：删除数据库名-发布ｉｄ表（这个表记录了标准所设计的数据库表的元信息）

4.删除发布的用户端逻辑

主要是　前端展示部分。

ｓｔｅｐ１：点击查看详情按钮。判断该申请的ｐｉｄ是否为-１。如果为负，提示发布已删除，不为负，进行下一步。

ｓｔｅｐ2：首先查看失效时间。查看失效位，如果失效位为1（已失效），系统提示已失效，查看密钥和点击操作都会提示失效；失效位为2（用户还没有点击查看密钥，申请还没有开始计时），提示点击查看密钥；失效位为0（已查看未失效），比较当前时间和失效时间，已失效，就更改失效位为１。