GroupSession
私がGroup Sessionに期待している下記の要点ができそうかどうかを当掲示板の先輩方にまずざっくりとお知恵を拝借した上で、できそうであれば、Group Sessionのテストサーバを建ててあれこれと検証をしたいと考えています。企業の情シス部門で同様の経験のある方等、どなたかご親切な方のresを期待しております。ちなみに、私は営業２０年、情シス部門はたった５年のキャリアの文系人間です。どちらかというとユーザー部門（特に私自身経験豊富な営業部）の視点で社内情報システムの企画・推進や行政指導を行う立場にいる者で細かい技術的な話は苦手です。日ごろ、社内向けの各種プログラム開発や、オープンソースのカスタマイズやサーバ構築と維持管理などの実装部分は部内のSEが担当します。■Group Sesssionの運用イメージ・サービス開始時に、情シス部門が全社員分の次の情報を人事DBからCSVでGroup Sessoinにimportする。 1. 職員番号（5桁の数字）→これをGroup SessionのユーザーIDにしたい ２．職員番号（5桁の数字）→これをGroup Sessionの初期パスワードにしたい ３．部署名（例： ｘｘ事業部 ｘｘ部 ｘｘチーム ｘｘグループ、最大で５階層） ４．氏名（例：田中 太郎） ５．フリガナ（例：タナカ タロウ） ６．勤務地コード（例：本社ならHO） ７．電話番号 （人事DBには電話番号がないため、空欄のままimport）・サービス開始直後にエンドユーザーが次の２つを自分で入力、変更などメンテナンスする １．パスワード （※初期パスワードのままだとログインできないようにエラーチェックを実装したい） ２．電話番号・本番サービス開始後のアカウント情報のメンテナンス 原則としてエンドユーザーが自分のIDとパスワードでログインして自分の個人属性情報をメンテナンスする。 なお、異動の場合、自分で３、６、７を変更登録する 退職者はGroup Sessionの管理者（情シス部門）が月次で棚卸しし、退職者のアカウントを 一括削除する。・エンドユーザーがhttp://[Group Sessionのホスト名]/ をWEBブラウザで開くと Group Sessionの次の２つの機能が利用できる ・スケジュール ・社員情報■質問１．初期パスワードではログインできないようにエラーチェックがかけられるようにできるか？２．エンドユーザーがパスワードを失念した場合、情シス部門の担当者は初期パスワードに リセットする形が望ましいが、この運用ルールで問題ないか？３．Group Sessionで不要な機能を簡単に削除できるか？
以下、参考情報です。■当社の現状（参考）：弊社情シス部門では全社員共用のイントラサーバに、基幹システムIDを持っている社員のみを対象として手作りのCGI等で既に次の機能（サービス）を開放しています。・全社共用イントラサーバのアクセス制御のポリシー 人事DBの職番をキーとした、基幹システムのPasswordをほぼリアルタイムにapacheの ベーシック認証と紐付け、社員のみにイントラサーバ上のコンテンツの閲覧を許している。・その全社共用イントラサーバ上で稼動している手作りのCGIによる全社員共用の主なサービス １．掲示板（イントラトップページ自体が全社共用掲示板のCGIです） ２．会議室予約 ３．フロア別座席表（電話番号記載） ４．アドレス検索（人事DBと月次で同期、ただし、部署名、氏名、勤務地、emailのみ） ※他にも多数手作りCGIがありますが、グループウェアに類する全社員共用の サービスは上記４点です。・その他、各部門独自運用のWEBサーバ、アプリケーションサーバ、DBサーバ、 サイボウズなどの部門グループウェアなどは、必要に応じて適宜、上記の全社共用イントラサーバの トップページ（通称：イントラトップページ）の左端メニューにリンクを張っています。グループウェアに関しては、各部門内で最適化したサイボウズ Office6 や Notes等が既に長年運用されていて間に合っていますので、いまさら全社員共用のグループウェアサーバを建てて、そこに片寄せするという案は考えておりません。
> ・サービス開始時に、情シス部門が全社員分の次の情報を人事DBからCSVで> Group Sessoinにimportする。> 1. 職員番号（5桁の数字）→これをGroup SessionのユーザーIDにしたい> ２．職員番号（5桁の数字）→これをGroup Sessionの初期パスワードにしたい> ３．部署名（例： ｘｘ事業部 ｘｘ部 ｘｘチーム ｘｘグループ、最大で５階層）> ４．氏名（例：田中 太郎）> ５．フリガナ（例：タナカ タロウ）> ６．勤務地コード（例：本社ならHO）> ７．電話番号 （人事DBには電話番号がないため、空欄のままimport）勤務地コードは項目がないと思います。部署名は所属という項目が該当すると思います。> ・サービス開始直後にエンドユーザーが次の２つを自分で入力、変更などメンテナンスする> １．パスワード （※初期パスワードのままだとログインできないようにエラーチェックを実装したい）> ２．電話番号「個人情報の修正」機能があるのでこれは可能だと思います。> ・本番サービス開始後のアカウント情報のメンテナンス> > 原則としてエンドユーザーが自分のIDとパスワードでログインして自分の個人属性情報をメンテナンスする。> なお、異動の場合、自分で３、６、７を変更登録する勤務地コードを除いてこれも「個人情報の修正」機能で可能だと思います。> 退職者はGroup Sessionの管理者（情シス部門）が月次で棚卸しし、退職者のアカウントを> 一括削除する。問題ないと思います。> ・エンドユーザーがhttp://[Group Sessionのホスト名]/ をWEBブラウザで開くと> Group Sessionの次の２つの機能が利用できる> ・スケジュール> ・社員情報プラグインマネージャーという機能で、使用する機能のON/OFFができるので可能だと思います。> > ■質問> > １．初期パスワードではログインできないようにエラーチェックがかけられるようにできるか？パスワードは1つしかありません。(初期と通常の様に分けて保存されているわけではない)> ２．エンドユーザーがパスワードを失念した場合、情シス部門の担当者は初期パスワードに> リセットする形が望ましいが、この運用ルールで問題ないか？初期パスワードはないので、情シスで何か適当なパスワードを設定する運用になるのではないでしょうか？> ３．Group Sessionで不要な機能を簡単に削除できるか？これは上記の通りプラグインマネージャーという機能で、使用する機能のON/OFFができるので可能だと思います。
> ■質問> > １．初期パスワードではログインできないようにエラーチェックがかけられるようにできるか？これは検証機を立てて確認します。> ２．エンドユーザーがパスワードを失念した場合、情シス部門の担当者は初期パスワードに> リセットする形が望ましいが、この運用ルールで問題ないか？これはこれはデモサイトに管理者IDでログイン後に管理者画面で問題ないことがわかりました。> ３．Group Sessionで不要な機能を簡単に削除できるか？これはデモサイトに管理者IDでログイン後に管理者画面で簡単に設定できることがわかりました。
REFさん、フォローありがとうございます。> 勤務地コードは項目がないと思います。はい、さしあたって住所のフィールドににぶちこもうと思います。※社外のお客様オフィスに常駐している社員が結構いますのでそういう社員は デフォルトで入力されている勤務地コードを 分室の住所に修正してもらうシナリオを考えています。> 部署名は所属という項目が該当すると思います。はい。> > ２．電話番号> > 「個人情報の修正」機能があるのでこれは可能だと思います。はい、デモサイトで確認できました。> > ・本番サービス開始後のアカウント情報のメンテナンス> > > > 原則としてエンドユーザーが自分のIDとパスワードでログインして自分の個人属性情報をメンテナンスする。> > なお、異動の場合、自分で３、６、７を変更登録する> > 勤務地コードを除いてこれも「個人情報の修正」機能で可能だと思います。はい。> > 退職者はGroup Sessionの管理者（情シス部門）が月次で棚卸しし、退職者のアカウントを> > 一括削除する。> > 問題ないと思います。はい。> > ・エンドユーザーがhttp://[Group Sessionのホスト名]/ をWEBブラウザで開くと> > Group Sessionの次の２つの機能が利用できる> > ・スケジュール> > ・社員情報> > プラグインマネージャーという機能で、使用する機能のON/OFFができるので可能だと思います。はい、デモサイトに管理者IDでログインし確認できました。> > ■質問> > > > １．初期パスワードではログインできないようにエラーチェックがかけられるようにできるか？> > パスワードは1つしかありません。(初期と通常の様に分けて保存されているわけではない)はい。これは当社のパスワードポリシー（デフォルトPWはNG、９０日以内に更新、パスワード長など）にあわせて、将来エラーチェックプログラムを作りこみをして実装する方向でソースをチェックしてみます。> > ２．エンドユーザーがパスワードを失念した場合、情シス部門の担当者は初期パスワードに> > リセットする形が望ましいが、この運用ルールで問題ないか？> > 初期パスワードはないので、情シスで何か適当なパスワードを設定する運用に> なるのではないでしょうか？はい、どうやらユーザーIDと職員番号の２つのフィールドがあるようですので、ユーザーID、職員番号、初期パスワードをいずれも職員番号にして初回サービス開始時にアカウント情報を人事DBからimportし、後はユーザー側で更新してねというスタンスでとりあえずサービスを開始してみたいと思います。> > ３．Group Sessionで不要な機能を簡単に削除できるか？> > これは上記の通りプラグインマネージャーという機能で、使用する機能のON/OFFができるので可能だと思います。はい。デモサイトがあけっぴろげで何でもできますので（ゲストのログインPWの変更すら可能のようですね）今日一日で実に多くを学べました。こちらが知りたい技術情報も簡潔に要領よく開示されていて、日本トータルシステム株式会社さんに感謝、感謝です！
２点ほど質問させてください。Q1. GS管理者と管理者のロールや権限の違いを教えて下さい。この数日、デモサイトを触っている段階でまだGSのパイロット環境構築の前段階なのですが、GS管理者（ID: admin）と管理者(ID: kanri）の違いがよくわかりませんのでどなたかご教示いただければ幸いです。当方がやりたいことは次の通りです：１．GS管理者 が各事業部門の代表窓口を“部門ユーザー管理者”として登録し、 にユーザー登録・削除の権限を委譲したい。２．人事DBに登録されている職員番号を有する出向社員、正社員等については 職員番号＝GSのIDとして月末月初の夜間バッチ処理で機械的にユーザーアカウントの削除・登録を行う。 ※但し、ユーザーが自分で変更した電話番号、勤務先住所、パスワードなどについては 上書きせず、前月のデータを維持する。３．各事業部門で契約している派遣社員、請負契約の社員については、“部門ユーザー管理者” にGSのGUIで新規登録・削除などのアカウントのメンテナンスを行ってもらう。Q2. GSの標準のH2データベースに外部プログラムから直接データを上書きすることは可能ですか？上記の２．をやるために、外部プログラムで作成した出向社員と正社員のアカウント情報を職員番号＝GSのID をキーとして、H2のDBに直接上書きをしたいのですが、可能でしょうか？最悪、GUIからCSVファイルでimportを覚悟してはおりますが…以上よろしくお願い致します。
> Q1. GS管理者と管理者のロールや権限の違いを教えて下さい。> > この数日、デモサイトを触っている段階でまだGSのパイロット環境構築の前段階なのですが、> GS管理者（ID: admin）と管理者(ID: kanri）の違いがよくわかりませんのでどなたか> ご教示いただければ幸いです。GS管理者(admin)はインストール直後にグループを作成したりユーザを作成したりするためのシステムユーザみたいな役割だと思います。なのでスケジュールなどの機能はGS管理者では利用できません。管理者(ID: kanri）はシステム管理グループに所属しているユーザです。GroupSessionではシステム管理グループに所属することでスーパーユーザ権限を設定する仕様になっているようです。> Q2. GSの標準のH2データベースに外部プログラムから直接データを上書きすることは可能ですか？> > 上記の２．をやるために、外部プログラムで作成した出向社員と正社員のアカウント情報を> 職員番号＝GSのID をキーとして、H2のDBに直接上書きをしたいのですが、可能でしょうか？> 最悪、GUIからCSVファイルでimportを覚悟してはおりますが…組み込みデータベースなのでTomcatが起動している間はアクセスできないと思います。アクセスするにはTomcatを停止するか、プログラムを作ってGroupSession内にバッチ処理を埋め込むしかないと思います。
田中様、早速のヒントありがとうございます。助かります。> > Q1. GS管理者と管理者のロールや権限の違いを教えて下さい。> GS管理者(admin)はインストール直後にグループを作成したりユーザを作成したりするためのシステムユーザみたいな役割だと思います。なのでスケジュールなどの機能はGS管理者では利用できません。はい、デモサイトであれこれ試した限りではGS管理者でログインした場合、画面上部のプラグインのサブメニューが無いというだけで、他に管理者（kanri）との違いが見つけられませんでした。> 管理者(ID: kanri）はシステム管理グループに所属しているユーザです。> GroupSessionではシステム管理グループに所属することでスーパーユーザ権限を設定する仕様になっているようです。おーなるほど。ということは、ユーザーアカウントの新規登録や削除権限を有するシステム管理グループというのがデフォルトであるということなのですね。文系の技術オンチの私ですが、やっと要領を得ました。では、私がやりたいことは簡単にできそうですね。早速デモサイトでGS管理者（admin）と管理者（kanri）の両方ででログインしてそれを試してみます。> > Q2. GSの標準のH2データベースに外部プログラムから直接データを上書きすることは可能ですか？> > > > 上記の２．をやるために、外部プログラムで作成した出向社員と正社員のアカウント情報を> > 職員番号＝GSのID をキーとして、H2のDBに直接上書きをしたいのですが、可能でしょうか？> > 最悪、GUIからCSVファイルでimportを覚悟してはおりますが…> > 組み込みデータベースなのでTomcatが起動している間はアクセスできないと思います。> アクセスするにはTomcatを停止するか、プログラムを作ってGroupSession内にバッチ処理を埋め込むしかないと思います。http://www.gs.sjts.co.jp/v2/tec/about_db_access.htmlを手がかりにして、夜間バッチのスクリプトでTomcatを停止し、H2データベースを書き換えてから、Tomcatを再起動する処理を検討してみます。あとは、当方に知見がほとんどないH2を使わずに外部データベースでGSを使い、外部プログラムで夜間バッチ処理でのアカウント情報の自動更新機能を実装するという簡単そうな選択肢がありそうですね。しかしH2使わないととっても遅いヨ というオチが予見されます。以上
TOP