-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
需求讨论 #18
Comments
CAPUHOME 需求汇总 |
用户设计,想法是加一个 |
未名bbs的模式有啥问题么?就是注册都可以注册,但是使用上有限制,必须在认证之后才能解锁一些功能。感觉这个更贴合我们的实际(这个问题怎么到现在还在想法阶段…… |
支持这个~但是其实我还是想把整个论坛都收进来……毕竟我实在没有想到应该把哪些版面开放给未认证用户。 |
五湖四海啊~如果不认证就不能看工作区,不能在那些版发帖神马的,这样应该也差不多就算是收起来了吧。而且我觉得我们没有必要非常排斥外面的人,其实本来也就没几个人关注…… 另外这种比较大的决策性的东西,是还需要理事会来最终决定还是说听你的就行了?不然总感觉我俩扯这些细节意义不大……技术上肯定都不是问题,就看想做成啥样…… |
咱们可以先做,最后就是一个权限的问题。我现在也不是理事我说的和你说的分量都差不多。可以跟小刀说说看。 @huxuan |
感觉我们现在最主要的问题就是跟理事会的联系略远……要不找个机会把风尘拉进来吧,就算不写代码,参与需求讨论应该没啥问题吧~ |
其实风辰在这里面吧…… |
但是他从来不说话……必须严肃的跟他说,让他重视一下,不然这边有很多东西进行不下去……(非要逼我下学期申请增补理事么…… |
主体框架提议,有任何增删改的建议尽管回复说明 CAPUHOME 需求汇总1.常规部分1.1 用户相关需求
1.2 消息(通知/私信/群发/群聊)相关需求
1.3 数据(注册用户数/活跃用户数/帖子数等)相关需求
1.4 后台管理相关需求
2.首页部分2.1 公告相关需求
2.2 照片/视频/日程展示相关需求(数据与活动对应)
2.3 关于(协会/暑期/部门/车队/联系我们)相关需求
3.论坛部分3.1 版面相关需求
3.2 主题相关需求
3.3 帖子相关需求
3.4 评论相关需求
4.活动资料部分4.1 活动(包括拉练、暑期、招新等)相关需求
4.2 事件相关需求(一个活动由多个事件组成)
4.3 团购/水果组(条目确定/条目不确定)相关需求
4.4 借车系统相关需求
5.用户资料部分5.1 个人首页相关需求
5.2 考勤相关需求(所有考勤记录都通过活动获取,五四训练也要新建活动)
5.3 车辆信息相关需求(包括零部件?二手市场?
5.4 师徒制相关需求
5.5 活动履历相关需求(数据与活动对应)
5.6 群组(主席团、理事会、执委会、部门、车队)相关需求
5.7 徽章(包括押后/队医/特检/免检资格、荣誉理事、体侧纪录、工作履历?)相关需求(分类别?
|
履历在活动记录里面?以及再加一个特检免检? @huxuan |
是的,就是一个人的活动记录嘛(但是可能有些活动是不显示在履历里的?
我的理解是这应该归到成就/徽章里?队医押后资格应该也可以归到这里,还是精简一点比较好 P.S. 我更新了前面那个提议的楼层内容 |
其他一些零碎的,没太想清楚的
|
|
我觉得需要增加学期会历这一项,放在和暑期路线一起的置顶里面,作为常用链接。 |
@huxuan 活动需要增加取消这一项,同时要向报名的所有人推送邮件和私信。 |
以及我觉得一楼的帖子应该和主题绑定在一起,删除一楼的时候连带整个帖子一起删除。 |
感觉你们说的不是一个东西了……最主要的一点是,我想在设计上把活动和论坛区分开,所以活动就没有“回复”的功能了,就算有在设计上也会单独存,而不是跟论坛的版面/主题/帖子放在一起,因此没有什么re和不可re的问题…… |
这个本来就应该是这样子的…… - -|||
我设想的是在学期开始,理事会就把活动都新建好,这样日程就出来了,有些不希望显示出来的加个字段visible=false就可以了
活动相关通知在计划中,可能没列出来,我稍后加上。 |
刚好今天看到了社团抵卡申请!我觉得可以接入~ @huxuan 整理进去吧~ |
拉练、前站、车队训练折算成五四训练的程序应该怎么设计?我想了一下没有想到特别好的方法,每年的规矩都不一样。 |
@huxuan 组织部借教室的事情也可以加进去~ |
嗯,不过最好能把这些东西整合一下,我们还是希望能做一个universal的系统的,比如这个整合成各种application?只是有不同的category,只是“收件人”可能也不一样? |
折算训练我觉得半年改一次代码还是可以接受的~ |
嗯删帖子我觉得可以不从数据库里搞掉,直接加个 deleted 列吧~ |
2.押后日志/队医日志我觉得可以改成填表:新建事故,事故人,事故部位,处理方案,补充。然后加个感想。。。 |
Messages那里,是不是应该可以屏蔽某个来源的消息? |
Comments 层主应该也可以删除(但不能编辑)自己楼下的评论吧 |
Comments 要不要加关闭评论的选项? |
群组的优先级~比如已审核用户和被封禁用户的权限是冲突的,然后解决冲突的办法是取优先级最高的 |
以及分开系统通知和站内信(存在两个表里)。现在的 CAPUBBS 里系统通知和站内信存在一个表里,但是它们根本就是两个东西,它们的关系是一条新站内信会产生一个新系统通知,但反过来不一定(不是每个系统通知都是站内信产生的)。所以现在的 CAPUBBS 这部分数据库和代码都有点小混乱。。。 |
收藏可以分不同文件夹 |
Message那里,加一个直接设置为已读和全部已读的功能吧~还是挺需要的~ |
今晚统一回复所有前面未回复的内容,mark在这里,要是忘记了再ping我(包括那个pr) |
这个不是不可以有,只是觉得是不是不太符合协会的精神?感觉可以一开始不考虑这个需求,如果一定需要到时候额外搞个message_black_list之类的表就好了……
这个是最后具体实现时的权限设置,不影响功能的设计和基本实现的
这个应该属于update范畴,只要model里有这个column就行,目前不需要到那么具体,最后所有的update应该都是差不多类似于这样的代码 https://github.com/huxuan/fangmi-api/blob/master/app/models.py#L208
这个跟API木有关系的,是前台有个按钮然后去请求就好了 |
嗯,是该开始做点什么了,关于需求就在这个帖子里面讨论吧
大致的计划是先整理出类别,然后逐步完善细节
一楼用来整理汇总,其他有什么问题包括需求相关的讨论都放在后面的楼层里好了
但是需要提醒一点的是请不要乱水,也尽量不要离题太远,如果有需要会清理太不相关的帖子
The text was updated successfully, but these errors were encountered: