RSSフィードについて

RSSリーダーで、フォーラムの新着投稿情報がチェックできます。
詳しくは下記ページを参照して下さい。

RSSフィード  RSSフィードについて

ご自由に情報交換の場として御利用ください。
また質問の前には「回答を得るには?」を参照してください。


GroupSessionへの要望があれば参考にさせていただきます。
要望リストも参考にしてください。


 
フォーラム  フォーラム
99_その他フォーラム
スレッド  タイトル

稟議機能(GS Ver.4.0.5)において、承認者が全て承認する前に決裁されてしまう


[ 5308 ] 稟議機能(GS Ver.4.0.5)において、承認者が全て承認する前に決裁されてしまう
投稿者: YL
投稿日時:  2013/03/04 16:37:50
GroupSession(Ver.4.0.5)の稟議機能について、件名のとおり、承認経路に複数の人
を登録して稟議申請し、最初の人が「承認」すると、「決裁」の状態になり、申請者に
「決裁通知メール」が発信されてしまいます。また稟議一覧も「完了」の状態になります。

この状態ですと、最終承認者(経路の一番最後の人が相当)が承認する前に決裁されて
しまうことになり、実用に耐えません。

以前はちゃんと全員が承認されるまで「決裁」とはならなかったので、業務に適用したのですが、
このままでと支障が出ます。どなたかご存知の方いらっしゃいませんでしょうか?
よろしくお願い致します。
  引用返信
[ 5310 ] Re: 稟議機能(GS Ver.4.0.5)において、承認者が全て承認する前に決裁されてしまう
投稿者: YL
投稿日時:  2013/03/04 19:05:51
原因を調べるため以下の動作を確認してみました。
1.GroupSessionのバージョンを4.0.5 で、データをまっさらな状態にして稟議
  を申請してみた。
  ⇒ 一人目の承認者が「承認」しても「決裁」にならずに「進行中」となる。
  ⇒ OK!

2.GroupSessionのバージョンを4.0.5 で現在のデータ(3/4深夜にバックアップ)
  をリストアしてから、稟議を申請してみた。
  ⇒ 一人目の承認者が「承認」すると「決裁」になり、「完了」してしまう。
  ⇒ NG!

3.GroupSessionのバージョンを4.1.0 にバージョンアップし、
  現在のデータ(3/4深夜にバックアップ)をリストアしてから、稟議を申請してみた。
  ⇒ 上記2と同様、一人目の承認者が「承認」すると「決裁」になり、「完了」してしまう。
  ⇒ NG!

この結果から、以下のデータのいずれかに問題があることがわかるのですが、
データの中身は解析できず、私の方ではこれ以上は原因究明できない状態です。
$GSESSION_DIR\WEB-INF\db
$GSESSION_DIR\WEB-INF\file
$GSESSION_DIR\WEB-INF\filekanri
$GSESSION_DIR\WEB-INF\webmail

既に本番運用しており、捨てることはできないので、なんとか通常に稟議機能を使える
ような対処方法はないでしょうか?
  引用返信
[ 6175 ] Re: 稟議機能(GS Ver.4.0.5)において、承認者が全て承認する前に決裁されてしまう
投稿者: MK
投稿日時:  2015/04/14 08:50:46
当方も同様の現象が発生しております。
環境はWindows2008Server
dbフォルダのgs2db.h2ファイルが4Gを超えたあたりからこの現象が発生しだしたように思います。

対応お願いできないでしょうか?
よろしくお願いしいたします。
  引用返信
[ 6176 ] Re: 稟議機能(GS Ver.4.0.5)において、承認者が全て承認する前に決裁されてしまう
投稿者: YL
投稿日時:  2015/04/15 10:44:39
前回、投稿した者です。
無料相談にも行ったのですが、そういった事象も認めてもらえず(無料だから?)、
対応はいただけなかったので、新たにPCを用意し、そこに新規インストール(Ver.4.1.0)
しましたが、最近、また同じ状態となりました。
ただ、当方の「gs2db.h2」は、約194mbでした。
対処しようがなく、困っています。
やっぱり、違うソフトも探さないという声も上がっており、どうしようかと思っていたところです。
対応してほしいですね。
  引用返信
[ 6179 ] Re: 稟議機能(GS Ver.4.0.5)において、承認者が全て承認する前に決裁されてしまう
投稿者: MK
投稿日時:  2015/04/17 14:23:49
YL様
そうですか。

当方も何とか今のままで正常動作させるように手を尽くしたのですが、どうにもなりませんでした。
結論として、新規インストール状態なら正常動作するので、新環境を用意し、グループ、ユーザー、スケジュール、日報等、エクスポート、インポートできるもは移行し、来週から新環境で運用することにしました。
※)db,file,filekanriをコピーして使用すると同様の現象が発生するので、ファイルコピーは出来ない。

当方は2011年から4年間使用して、この現象が発生しだしました。
YL様も同様の対応されて、再発されたとのこと。
また発生する可能性があるのは、ちょっと怖いですね。
  引用返信
[ 6415 ] Re: 稟議機能(GS Ver.4.0.5)において、承認者が全て承認する前に決裁されてしまう
投稿者: Unbabo
投稿日時:  2016/01/07 22:25:16
今更ですが、最近私のところも同じ現象が発生しました。
バージョンは4.2.6で、新しいバージョン4.5.4にバックアップを移す前は問題なし、
リストアすると同じ現象になりました。
YLの最初の記載と同様です。

きっかけは無かったように思います。突然ある日、気づいたら・・・という感じでした。
稟議以外は正常に動作しています。
状況から推測するにてデータベースもしくはインデックス系に何か不具合があるのではないかと思っています。

過去のデータを持っておいて、一度稟議のデータだけ全削除してみようと思う今日頃です。

本当に誰か助けて欲しいです。
  引用返信
[ 6416 ] Re: 稟議機能(GS Ver.4.0.5)において、承認者が全て承認する前に決裁されてしまう
投稿者: Unbabo
投稿日時:  2016/01/09 22:57:04
解決しました。
もしお困りの方がいればご参考までに。

●原因

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の扱いを変更するかは日本トータルシステム様のご判断にお任せするとして、
私は上記例で言うところの『一般』グループを削除し、
無事に稟議が途中で決裁されることはなくなりました。


ひとつ前の投稿にも書いたように最新バージョンでも発生します。
同様の現象が発生して同じように困っている方の救いになれば幸いです。
  引用返信
 
スレッドURL:
 

クラウド版グループウェアbycloud

Twitter
開発スタッフのつぶやき http://twitter.com/gsession_jts
Facebook
メールマガジン
GroupSessionのセキュリティ情報、アップデート情報をお伝えするメールマガジンです。(無料)
メルマガ『速報!GroupSession』
ブログ
スタッフによる開発日誌を公開しています。
「Public JTS スタッフブログ」


Copyright 日本トータルシステム株式会社