出勤管理表
いつもお世話になっております。drupal7で図(attachments参照)の様な出勤管理システムの様なものを
作れないかと思いまして投稿させて頂きました。CCKとviewsとreference、rulesである
程度は作れないかと考えているのですが、なかなか苦戦しております。
具体的にどの様なコンテンツタイプを作り、それぞれのコンテンツタイプに
どの様なフィールドを持たせれば良いのか。そして、それぞれのコンテンツタイプ
同士をどの様に関係を持たせるのか(referenceモジュール利用?)を考えているのですが
なかなか思う通りにできません。
現時点では以下の様なアプローチを考えています。
コンテンツタイプ
①出勤者:出勤者の名前や説明、写真等の個人情報を持たせる
②出勤日:dateフィールドで日付を入力
③出勤時間:dateフィールドで時間を入力
これらのコンテンツタイプをreferenceモジュールで関連付けをする。
あまりに、漠然とした質問になってしまいますので問題点をデータ構造に
絞らせて頂きたいと思います。
問題①そもそも、cckとviewsとrefereceを利用して、この図の様なデータ構造を
持つものを作ることは可能なのか?
問題②今回は、上記の3つのコンテンツタイプを用意しましたがこの3つの
コンテンツタイプだけでOKなのか?もしくは、3つも必要ない?
問題③具体的にどの様なコンテンツタイプを作れば良いのか?
データモデリング(?)をするのは、全くの初めてでしてアプローチの方法さえ
掴めない状況です。大変分かりにくい、説明だと思いますが宜しくお願いします。
下記でディスカッションされている内容が近いのかとも思ったのですが…。
http://drupal.org/node/163153
| Attachment | Size |
|---|---|
| kinmu.jpg | 171.09 KB |
| conent.png | 88.57 KB |
Comments
データモデリングというよりは、Drupal
データモデリングというよりは、Drupal アーキテクチャーという感じかもしれませんね。
このようなシステムを Drupal で構築する場合、Drupal が提供する枠組みをある程度知っている必要が生じるので、PHP と MySQL でゼロから組むよりも、ある意味難しいかもしれません。知ってさえいれば、ずいぶん楽に出来るのですが。
この記録をノードで行う場合、ユーザー + ひとつのコンテンツタイプだけで可能だと思います。
日時の記録に使うコンテンツタイプに必要なフィールドは:
で良いと思います。
このコンテンツタイプを元にするノードを作成する際に、作成者を出勤者とすることで、ノードとユーザーを関連付けることができます。
集計に関連して気をつけるべきことは、このコンテンツタイプのリビジョン機能をオフにするか、かならず node テーブルの vid と、node_revisions テーブルの vid を join することです。リビジョンが存在する場合、合計に誤りが生じるためです。
ですが、上記のような感じで、ノードを使うと色々面倒な部分も出てきます。カスタムモジュールでカスタムテーブルに書きこむほうが楽かもしれません。どちらにせよ、Views モジュールを使って集計できる訳ではないですし、ノードを使うメリットがどこにあるかを査定することをお勧めします。
それから僭越ながら、このシステムには2つの問題があると思います。一つは入力上の制約、もうひとつは実務上の問題です。
入力上の制約とは、主にユーザーインターフェイスに起因します。例えば、不運なAさんの勤務が、納期直前のため 09:00 - 翌日03:00、その後3時間休んで 06:00 - 17:00、休憩・仮眠を取って 23:00 - 翌日9:00 まで働いたとします。
kenppx さんの提示されたユーザーインターフェイスでは、このような、日を跨いだり、一日に複数の入力をするといったユースケースをカバーできません。
それから、実務上の問題とは、「このシステムで本当に全ての勤務時間を正しく記録できるのか」というものです。在庫管理システムなどでよくあるのは、出庫の際、「忙しいから後で記録しよう」と思いつつ入力を忘れたり、帳簿に手記入した出入庫情報を後からシステムに入力する際の入力ミスなどです。手続きの最初に出入庫情報を入力しない限り実際の物品の移動ができないようなシステムやワークフローがないと、記録された情報の正確さが低下します。十分機能している既存のシステムの書き換えなら問題ないと思いますが、新規の場合は注意が必要かもしれません。
あと、グーグルで「勤怠管理 オープンソース」をキーワードに探すと、よさそうなソフトが見つかりました。ご参考まで。(Drupal ではなくなってしまいますけど。。。)
説明不足でした…
dokumori様、プログラミングもdrupalも素人の私の意味不明な質問を
ここまでで理解して頂けるとは…。本当に、ありがとうございます。
そもそも、これは何のシステムなのかと言いますと水商売の女の子(以下『嬢』と呼ばせて頂きます)の出勤予定表の
様な物をイメージして頂ければと思います。友人が最近、無店舗型(デリバリー式)のお店を運営しておりまして、
こんなのを作れないかなぁ…。と相談されました。自分のスキルアップの意味もありましてトライしてみようと考えております。
ホームページにその日の出勤の嬢や、週間の勤務予定を反映できるようにする事が目的です。
それをまず知りたいと思っていました。そもそも、PHPとMySQLで組むのとdrupalとではどちらが良いのか…。
ただ、drupalの枠組みを知っていれば楽にできるのをお聞きしまして勉強の為にもdrupalで頑張ってみようと思いました。
ちなみに具体的には、drupalで組むと何が楽なのでしょうか?それと、phpを完全に勉強してからdrupalのapiやhookなどの
システムを学習した方が効果的でしょうか?それか、基本的なphpの理解があればdrupalのシステムは学習次第で扱えるものでしょうか?
何から手をつければ良いのか迷っている状態です。
今まで、コンテンツタイプを作り、CCKフィールドで情報を入力し、それをviewsを使って表示する
という事を行っていました。コンテンツはノードで保存されていましたので、頭の中にはノードの事
しか頭にありませんでした。カスタムモジュールとカスタムテーブルですか…。
具体的になにから勉強したら良いでしょうか?モジュールの作成方法からになりますか?
ノードとして扱った場合、viewsで操作できるのが魅力だなぁとも考えていました。
嬢はかなりの頻度で入れ替わりますので、できれば嬢をひとつのコンテンツタイプとして扱えれば
新人嬢の登録や引退嬢の管理がやりやすいのかとも考えております。
基本的に入力は一人の管理者が行うので、嬢が入力するという事は想定していないようです。
.
要件を知らないまま、憶測ばかりで書き進めてしまいました。勤怠管理ではなく、出勤予定一覧なのですね。関係のないことを書いて混乱を招いてしまい失礼しました。
最初にアーキテクチャーに関して、次に Drupal に関しての質問にお答えします。
まず、アーキテクチャーに関して言えば、プロファイルコンテンツタイプと、出勤日時コンテンツタイプで対応できると思います。
プロファイルコンテンツタイプ:
出勤日時コンテンツタイプ
年月日と時間を別のコンテンツタイプに分ける必要性は見られませんし、入力や管理が大変になるので避けたほうが良いと思います。
そして、カスタムモジュールとカスタムテーブル、というのは、勤怠管理システムを想定した場合の発言だったので無視してください。混乱させてしまいすみません。
次に、Drupal に関しての質問の答えです:
一言でいうと、開発効率の良さにあると思います。まずkenppx さんが開発を検討されているサイトの機能をリスト化してみます。
(上記はコンテンツ入力/サイト管理者のためのものと考えます)
最低でもこのくらい必要になると思います。
PHP で何も無いところから始める場合、ログイン機能やセッション管理、さらにはデータベースの接続など、根本から組んでいく必要があり、大変非効率的です。フレームワークなどで作る場合でも、それなりの量のコードを書く必要が出てきます。
Drupal 7 であればコードを書かずとも、コアの機能と Views、そしてテーマをインストール/設定するだけでこれらの機能を実現することができます。これは kenppx さんもすでにご承知のことと思います。
Drupal で組んだ場合でも、細かい部分での調整のためにコードを書く必要が出てくることがあると思いますので、単純な比較はできませんが、Drupal を採用する理由は、やはりサイト開発上の効率の良さにあると思います。
さらに、ウェブサイトというのは一度作ったら終わり、というケースはほとんど無く、新しい機能を順次追加していくことになるのが普通です(例えば facebook の「いいね!」ボタンやツイートボタンを付加する、ツイートのフィードの追加等々)。そういった場合の多くにも、モジュールの追加と微調整だけで対応できるのが Drupal の魅力です。
人によって学習方法が異なるので、一概には言えません。前者の方法が適しているという方もあると思います。僕自身は、実践をからめたほうが頭に入る性質なので、後者です。開発の必要に応じてコアやモジュールのソースコードを読むことで、PHP と Drupal APIs を効率よく習得してきたと思います。
極端な話、PHP をまったく書けなくても Drupal でサイトを構築して納品している人を知っていますし、そのためのモジュール群でもあります。
「何から手を付ければよいか」という問に対しての答えは、コードを書かずに組めるところまで組んでみる、というのはどうでしょう。どうしても既存の機能の設定で対応できず、適当な contrib モジュールも見つからない、というところでカスタムモジュールの作成に入ってみては如何でしょう。
とても参考になります
今までは3つのコンテンツタイプでしておりましたが、確かに3つはいらないですよね。
dokumori様の仰るとおり、2つのコンテンツタイプで組んでみようと思います。
課題①出勤日時コンテンツの自動生成
問題は、どの様に自動的に現在の日付から3週間分の出勤日時コンテンツタイプを
生成すれば良いのかです…。私の考えた方法としては、rulesモジュールを使って
なんとか自動化できないのかなぁと考えています。rulesだけで、できるものでしょうか?
課題②viewsでどの様に表示するべきか
嬢毎に出勤日を表示しなければなりません。現在考えている作戦は①問題が解決できれば、
自動生成された出勤日時コンテンツタイプをviewsでグリッドで並べて、嬢毎にグループ化して表示しようと思います。表示方法はrendered entityでentityをそのまま表示してみようと思います。
課題③どのように、フィールドを編集可能にするのか
素晴らしい、モジュールを見つけました。editablefieldsです。
フィールドを編集可能な状態で表示する事が出来るモジュールです。
これを使ってやってみようと思います。
http://drupal.org/project/editablefields
大変勉強になります。私は最近、htmlとcssを習得したレベルの人間です。
そして、無謀にもいきなりdrupalを勉強し始めたのでフルスクラッチで開発する
苦労を経験した事がありません。そのため、drupalを使わない時はどれだけ
大変なのかがイマイチ理解できない状態でした。dokumori様の説明をお聞きまして、
drupalを使うメリットを再認識する事ができました。
確かにそうですよね。私の場合は、drupalの書籍を読んでもなかなか理解出来ない
部分があります。apiやhookとなると、概念自体がイマイチ理解できません。
多分、理解するだけの最低限の知識が欠如しているからだと思います。
やはり、最低限のphpやmysqlの知識は持っていたほうが、今後の事を考えて
良いと実感しました。phpが使えると、drupalはもっと楽しくなりそうですし…。
views、cck、panelsとrulesでかなりの事はできると実感しています。
ちなみに、その方はコードを書かずどの程度のサイトを構築されていますか?
『コードを一行も書かずに、drupalでこんなサイトができました!!』
の様な、サンプルサイト集などが日本語でもあれば多くの人がdrupalに
興味を持ってくれるのではないかと考えております。
とりあえず、上記の事を踏まえまして組める所まで組んでみます。
rulesを使った自動化で恐らく止まると思います。出来ましたら、urlをアップします。
まさにこれ
こんにちは(ここではお久しぶりです)。
まさにこういうのが作りたくて、ググってたらこのスレッドが引っかかりました。そういえば先日、kenppx さんにこの話をお聞きしたことがあるような気がしたなぁ。
で、もしすでに稼働しているのであれば、近々見せていただければありがたいです。
……使わせてもらえるとなおいいのですが(^^ゞ
dokumori さんが書かれていることも含めて、まだ理解できないことばかりなのですが、もう一度よく読み込んでみたいと思います。
僕の場合はもっと単純なのですが
僕が作りたいものはたぶん kenppx さんのそれよりは単純で、一例を挙げればこんな感じのものです。
http://www.pediatrics-chiba-u.org/outpatient.html
ここにあるように、カレンダーのなかにあるグループのメンバーのその日の担当が表示されればいい。「何時から何時まで」みたいな時間要素は必要ありません。
このメンバーの名前をクリックすると、当該メンバーの個別に紹介ページに飛ばしたいわけです。
なにかカレンダーモジュールとの組み合わせでもっと簡単に実現することができそうにも思うのですが、いかがでしょうか?
簡単に、と言いつつ、僕自身はまだ方法にたどり着いていないのですが^^;
カレンダーモジュールでできると思います!
何時から、何時までという条件がなくてこのサイトの様に名前だけを表示するのであれば
カレンダーモジュールで実現可能だと思います!