GroupSession
GroupSession（Ver.4.0.5）の稟議機能について、件名のとおり、承認経路に複数の人を登録して稟議申請し、最初の人が「承認」すると、「決裁」の状態になり、申請者に「決裁通知メール」が発信されてしまいます。また稟議一覧も「完了」の状態になります。この状態ですと、最終承認者（経路の一番最後の人が相当）が承認する前に決裁されてしまうことになり、実用に耐えません。以前はちゃんと全員が承認されるまで「決裁」とはならなかったので、業務に適用したのですが、このままでと支障が出ます。どなたかご存知の方いらっしゃいませんでしょうか？よろしくお願い致します。
原因を調べるため以下の動作を確認してみました。１．GroupSessionのバージョンを4.0.5 で、データをまっさらな状態にして稟議 を申請してみた。 ⇒ 一人目の承認者が「承認」しても「決裁」にならずに「進行中」となる。 ⇒ OK！２．GroupSessionのバージョンを4.0.5 で現在のデータ（3/4深夜にバックアップ） をリストアしてから、稟議を申請してみた。 ⇒ 一人目の承認者が「承認」すると「決裁」になり、「完了」してしまう。 ⇒ NG！３．GroupSessionのバージョンを4.1.0 にバージョンアップし、 現在のデータ（3/4深夜にバックアップ）をリストアしてから、稟議を申請してみた。 ⇒ 上記２と同様、一人目の承認者が「承認」すると「決裁」になり、「完了」してしまう。 ⇒ NG！この結果から、以下のデータのいずれかに問題があることがわかるのですが、データの中身は解析できず、私の方ではこれ以上は原因究明できない状態です。$GSESSION_DIR\WEB-INF\db $GSESSION_DIR\WEB-INF\file $GSESSION_DIR\WEB-INF\filekanri $GSESSION_DIR\WEB-INF\webmail 既に本番運用しており、捨てることはできないので、なんとか通常に稟議機能を使えるような対処方法はないでしょうか？
当方も同様の現象が発生しております。環境はWindows2008Serverｄｂフォルダのgs2db.h2ファイルが４Gを超えたあたりからこの現象が発生しだしたように思います。対応お願いできないでしょうか？よろしくお願いしいたします。
前回、投稿した者です。無料相談にも行ったのですが、そういった事象も認めてもらえず（無料だから？）、対応はいただけなかったので、新たにPCを用意し、そこに新規インストール（Ver.4.1.0）しましたが、最近、また同じ状態となりました。ただ、当方の「gs2db.h2」は、約194mbでした。対処しようがなく、困っています。やっぱり、違うソフトも探さないという声も上がっており、どうしようかと思っていたところです。対応してほしいですね。
YL様そうですか。当方も何とか今のままで正常動作させるように手を尽くしたのですが、どうにもなりませんでした。結論として、新規インストール状態なら正常動作するので、新環境を用意し、グループ、ユーザー、スケジュール、日報等、エクスポート、インポートできるもは移行し、来週から新環境で運用することにしました。※）db,file,filekanriをコピーして使用すると同様の現象が発生するので、ファイルコピーは出来ない。当方は2011年から4年間使用して、この現象が発生しだしました。YL様も同様の対応されて、再発されたとのこと。また発生する可能性があるのは、ちょっと怖いですね。
今更ですが、最近私のところも同じ現象が発生しました。バージョンは4.2.6で、新しいバージョン4.5.4にバックアップを移す前は問題なし、リストアすると同じ現象になりました。YLの最初の記載と同様です。きっかけは無かったように思います。突然ある日、気づいたら・・・という感じでした。稟議以外は正常に動作しています。状況から推測するにてデータベースもしくはインデックス系に何か不具合があるのではないかと思っています。過去のデータを持っておいて、一度稟議のデータだけ全削除してみようと思う今日頃です。本当に誰か助けて欲しいです。
解決しました。もしお困りの方がいればご参考までに。●原因SQLの動きを追跡すると、以下のクエリで期待している結果が得られていませんでした。 select RNG_CHANNEL.USR_SID as USR_SID from CMN_USRM, RNG_CHANNEL where RNG_CHANNEL.RNG_SID = xxx and RNG_CHANNEL.RNC_TYPE = 0 and CMN_USRM.USR_SID = RNG_CHANNEL.USR_SID and CMN_USRM.USR_JKBN = 0 and CMN_USRM.USR_SID not in ( select case CMN_PLUGIN_CONTROL_MEMBER.USR_SID when -1 then CMN_BELONGM.USR_SID else CMN_PLUGIN_CONTROL_MEMBER.USR_SID end as MEMBER_SID from CMN_PLUGIN_CONTROL_MEMBER left join CMN_BELONGM on CMN_PLUGIN_CONTROL_MEMBER.GRP_SID = CMN_BELONGM.GRP_SID where PCT_PID = 'ringi' group by MEMBER_SID ) and RNG_CHANNEL.RNC_SORT > ( select RNC_SORT from RNG_CHANNEL where RNG_SID = xxx and USR_SID = yyy ) order by RNG_CHANNEL.RNC_SORTこのクエリは稟議を承認をした後に、次の承認者のSIDを取得するためのものです。途中で決裁される現象発生時は、このクエリを実行すると該当なしとなってしまいます。該当なしの場合は今承認した人が最終承認者として判断され、稟議が完了するわけです。該当なしになる原因は、真ん中らへんの not in の サブクエリです。突き詰めていくと本来 CMN_PLUGIN_CONTROL_MEMBER にあるはずのとある GRP_SID がCMN_BELONGM の中に無かったため、サブクエリが NULL を返し、not in の条件が正常に機能していなかった模様です。ちなみに GRP_SID のマスタは、CMN_GROUPM で、この中にはもちろん存在していますし、グループも正しく表示されています。従って、原因は CMN_BELONGM に GRP_SID が無いことです。（not in は原因というか要因ですね。）●再現方法それらの状況を踏まえて、再現方法を考えてみました。1. 『一般』というグループを作成し、そこに「Aさん」を入れます2. プラグインマネージャーで稟議のアクセス権の変更を選びます3. 使用制限で、『一般』を制限します ※制限するユーザ/グループを指定する方4. 「Aさん」を『一般』から抜きます1～3のいずれかのタイミングで CMN_BELONGM に『一般』と「Aさん」のSID情報が追加されますが、4.のタイミングで CMN_BELONGMから 『一般』と「Aさん」のSID情報がなくなります。（細かく動きは見ていませんが）テストして実際に現象が発生することまで確認できています。●対策原因に記載したサブクエリの not in を exists 等に変更するかCMN_BELONGMの扱いを変更するかは日本トータルシステム様のご判断にお任せするとして、私は上記例で言うところの『一般』グループを削除し、無事に稟議が途中で決裁されることはなくなりました。ひとつ前の投稿にも書いたように最新バージョンでも発生します。同様の現象が発生して同じように困っている方の救いになれば幸いです。
同じ現象で困っています。下記内容をもう少し具体的に教えてください。> 1. 『一般』というグループを作成し、そこに「Aさん」を入れます> 2. プラグインマネージャーで稟議のアクセス権の変更を選びます> 3. 使用制限で、『一般』を制限します ※制限するユーザ/グループを指定する方> 4. 「Aさん」を『一般』から抜きます> 私は上記例で言うところの『一般』グループを削除し、> 無事に稟議が途中で決裁されることはなくなりました。よろしくお願いいたします。
TOP