實現一個基於 SharePoint 2013 的 Timecard 應用（上）

在 SharePoint 2013 上面實現一個 Timecard 應用的想法來自一個真實的需求，而實現的方案在我腦海裏面盤旋已經好久了，終於這幾天準備安排點兒時間將它實現出來。

 

 

「 We started small, then grow up.」—Dont’know who.

 

 

需求

Timecard（打卡）應用的需求描述以下。

角色

1. 管理員（Admin），控制能夠填寫的時間窗口（Time Window）。
2. 團隊（Team），是被要求打卡的組織內部可管理的羣體。好比，部門是一個團隊，項目組也是一個團隊，如何設置團隊，取決於管理須要。
3. 團隊成員（Team Member），填寫 Timecard 的人。只能編輯本身的 Timecard。
4. 團隊經理（Team Manager），負責審覈團隊成員的 Timecard。

 

 

業務流程

1. 團隊經理髮申請給管理員，讓管理員給創建團隊的專用 Timecard List。
2. 團隊經理在本身的 Timecard List 中加入團隊成員，給他們適當的權限。（這說是業務流程，其實已經開始作技術方案設計了）
3. 管理員按期放出可填的 Time Window，好比，「2014 W26」就是 2014 年第 26 周。而且能夠指定這個窗口的起止日期，這是由於，跨月或者跨年的 Timecard 有時要將一個完整的日曆周打散分配以便各類財務結算。郵件通知發到每一個人。
4. 團隊成員到本身所屬團隊的 Timecard List 中填寫 Timecard。若是一我的屬於多個團隊，那麼他要在多個地方填寫屢次。若是他足夠聰明，他會把這些不一樣團隊 Timecard List 的連接組織起來、收藏好。
5. 團隊經理上來，刷已經提交可是尚未審覈過的 Timecard，而後審覈經過或者拒絕。
6. 月底管理員收 Timecard，導出來月度數據供 … 之用 ：）

 

數據與表單

主要有 Time Window、Timecard、月度導出報告，這樣幾種。

這個分析的部分是不能掠過的。我知道架構師、程序員不是美工（UI 設計師），可是，無視表單設計的人最後都會遇到麻煩的。哪怕只是一張紙的設計，也要設計。

 

需求分析

分析下來須要注意幾個重點：

1. 管理員有查看全部 Timecard 的權限，由於要出報告的。
2. 每一個團隊的權限必須讓團隊經理本身管理，誰也幫不了他/她。
3. 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 列表

長成下面這個樣子：

這個列表的關鍵在於它的權限設置。

1. 這是一個默認全部人均可以訪問的列表：
    
2. 過時的時間窗口，則斷開權限繼承，全部人將再也不能夠訪問，除了管理員：
   

 

因爲上面這樣的權限設置，你們在填寫 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 訪問的時候會發現個人博客界面錯亂嗎？若是有，請發消息或者評論讓我知道，謝謝！）