在 SharePoint 2013 上面实现一个 Timecard 应用的想法来自一个真实的需求，而实现的方案在我脑海里面盘旋已经很久了，终于这几天准备安排点儿时间将它实现出来。
“ We started small, then grow up.”—Dont’know who.
需求
Timecard（打卡）应用的需求描述如下。
角色
- 管理员（Admin），控制可以填写的时间窗口（Time Window）。
- 团队（Team），是被要求打卡的组织内部可管理的群体。比如，部门是一个团队，项目组也是一个团队，如何设置团队，取决于管理需要。
- 团队成员（Team Member），填写 Timecard 的人。只能编辑自己的 Timecard。
- 团队经理（Team Manager），负责审核团队成员的 Timecard。
业务流程
- 团队经理发申请给管理员，让管理员给建立团队的专用 Timecard List。
- 团队经理在自己的 Timecard List 中加入团队成员，给他们适当的权限。（这说是业务流程，其实已经开始做技术方案设计了）
- 管理员定期放出可填的 Time Window，比如，“2014 W26”就是 2014 年第 26 周。并且可以指定这个窗口的起止日期，这是因为，跨月或者跨年的 Timecard 有时要将一个完整的日历周打散分配以便各种财务结算。邮件通知发到每个人。
- 团队成员到自己所属团队的 Timecard List 中填写 Timecard。如果一个人属于多个团队，那么他要在多个地方填写多次。如果他足够聪明，他会把这些不同团队 Timecard List 的链接组织起来、收藏好。
- 团队经理上来，刷已经提交但是还没有审核过的 Timecard，然后审核通过或者拒绝。
- 月底管理员收 Timecard，导出来月度数据供 … 之用 ：）
数据与表单
主要有 Time Window、Timecard、月度导出报告，这样几种。
这个分析的部分是不能掠过的。我知道架构师、程序员不是美工（UI 设计师），但是，无视表单设计的人最后都会遇到麻烦的。哪怕只是一张纸的设计，也要设计。
需求分析
分析下来需要注意几个重点：
- 管理员有查看所有 Timecard 的权限，因为要出报告的。
- 每个团队的权限必须让团队经理自己管理，谁也帮不了他/她。
- Time Window 的可见性由管理员控制，也就意味着 Timecard 的填写有开始和截止日期。
满足以上的要求以后，整个业务的实现也就差不太远了。而且数据一旦到了 Timecard List 里面，再怎么捞出来、怎么分析就相对好办，因为导出 Timecard 和查看分析的功能权限相对集中，只要埋头实现功能即可。
应用设计
这是整个环节中最有趣儿的部分，我们要一步步的慢慢来。
一贯的，这个 Timecard 应用的基本思想仍然是基于 SharePoint 自身的功能，使其成为 SharePoint 应用而不是其它的。如果 SharePoint 这个平台不能使其更好，那么，就不值得在 SharePoint 上面实现它。
一开始尝试过 SharePoint 2013 的 App 来实现，但后来明白过来了，这根本不对路。App 是一个作者面对多个用户独立安装部署的场景，而让公司里面员工都去安装 Timecard App 太搞了；而如果将 App 安装在一个固定位置，让所有人去访问，那又何必折腾用 App 呐？况且，放着 SharePoint 自己的 CRUD 功能不用实在是和自己过去不。于是，调转船头，设计了现在的这个混合方案。
用新 Site，还是新 Web？
我对 Site、Web、Web Site 的理解，就是从了解 SharePoint 开始被颠覆的。恨死那帮人了，起名字太随意了。
Web 本来就是很多节点连接成的“蜘蛛网”，而 Site 则是这个网中的节点。但是，SharePoint “帮”我们给倒过来了。
SharePoint 的 Site 是指的一群网站（Web）的集合，但是，Site 的全称却不叫做“Web Collection”，而叫做“Site Collection”；但它 Collect 的却并不是 Site，而是 Web。用郭德纲的话说：“你想去吧！”
---------- 下面开始说正事 ----------
Timecard 作为一个单独的应用，当然是需要有自己独立的网站的。这时，我们有 2 个选择：1）建立一个新的网站集（Site Collection）或者 2）找一个现有的网站集建立一个新的子站点（Web）。两种选择各有利弊，具体分析起来考虑的因素就很多了。在我们现在这个 Timecard 应用里面，我决定采用子网站（Web）的形式。
内容类型与 List 模板
考虑到管理员要不厌其烦的为每个小组建立他们自己的 Timecard List，还是想点儿办法减轻他/她的工作为好。
专门按照 Timecard 数据结构的需要建立内容类型，然后，附加到每个 List 上面去，无疑会轻松很多。
但是，我们还可以再进一步，在第一个 List 的基础上，再保存它为一个 List 模板，这样，以后再建立其它的 Timecard List 的时候，连绑定内容类型的操作都免了，直接从 List 模板里面选就可以了。
新 Time Window 的通知
可以用 SharePoint 的 Alert 功能。
Time Window 与 Timecard List(s) 的关联
这个相对简单，直接用 Lookup Column 就可以了。
导出的报告
由于每个 Team 的 Timecard List 是独立的，所以，无法直接将所有的 Timecard 导出来或者做成报告。
这里有 2 个选择：1）使用 CQWP，将同属 Timecard 内容类型的数据聚合到一个地方，或者 2）写代码（CSOM、Sandbox Solution 都可以考虑）。
应用实现
首先介绍一下虚拟的团队。
| 管理员 |  Star Scream |
||
| 第一队 |  Long Haul 一队队长 |
 Bonecrusher 一队队员 |
 Hook 一队队员 |
| 第二队 |  Scrapper 二队队长 |
 Scavenger 二队队员 |
 Mixmaster 二队队员 |
Timecard 网站
没什么特别的，就是一个普通的子网站。推荐用 Blank Site 模板。
Time Window 列表
长成下面这个样子：
这个列表的关键在于它的权限设置。
- 这是一个默认所有人都可以访问的列表：
- 过期的时间窗口，则断开权限继承，所有人将不再可以访问，除了管理员：
由于上面这样的权限设置，大家在填写 Timecard 的时候，就只能看见管理员发布的有效的 Time Window 了。这正是我们需要的效果。
Timecard 列表
Timecard 列表和 Time Window 做了关联，从而实现选择由管理员发布的时间窗口的功能。
Timecard 列表需要为每一个团队都建立一个的。
上面这条记录，说明填写的人周六加了 4 个小时的班，并且这条记录还在 Pending 状态。
实际运作的时候，管理员创建好团队的 Timecard 列表，然后将列表的 Full Control 给团队经理，然后团队经理进去安排每个成员的权限。
然后，团队经理需要为每个成员单独建一个文件夹，只允许该成员填写这个文件夹下面的 Timecard。
比如，Bonecrusher 的这个文件夹，就要修改其权限，只让 Bonecrusher 本人可以提交 Timecard、经理 Long Haul 可以审批。
对其他队员也同样设置。
当然，Timecard 列表的 Content Approval 也要开启，这样让团队经理可以审核一下。
好了，现在的 Timecard 已经可以用起来了！
试试看这里：
啊哈，好像可以了耶！这么简单，那让我们炒掉那个 SharePoint 专家算了，这活儿看上去很容易啊！
嘿嘿，真滴吗？：）
（你们用 IE 访问的时候会发现我的博客界面错乱吗？如果有，请发消息或者评论让我知道，谢谢！）
