Workflow for approving changes/closures of cases

[mfosse71]

I propose that there is a approval flow for case closures(only cases not tasks etc.) so that there is somekind of "second opinion" / "Segregation of Duties" for case handling

Request Type

Feature Request

Work Environment

Question	Answer
OS version (server)	Ubuntu, 16.04 LTS
TheHive version / git hash	2.x, hash of the commit
Package Type	Binary

Problem Description

Lets say that a analyst is working on a case, and he/she thinks that they have found a explanation/artifact that supports their theory/hypothesis of the actual case in question, What, When, Why and How..
In order to close the case, it should be possible to "ask for a second opinion" that is, to have another analyst(this probably have to be in a structured/tiered setup) look at and "approve" the closure, perhaps a "on-call" person is the one that should be responsible for both dispatching items as well as approving closures. So more Feature requests to be written in terms of roles etc.

Steps to Reproduce

N/A

Possible Solutions

Maybe by creating some more roles and also adding a "workflow" for actually approving all closures of cases(only on a case level, tasks should be individually handled and closed)

Complementary information

[saadkadhi]

Sorry but this seems too stringent for the design philosophy that drives TheHive development. Our goal is not to create a "management" tool that obliges analysts to request validation/moderation before doing some actions. Rather, we believe that as human beings we can talk to each other and if a team would like to force analysts to seek validation or a second opinion from someone else, they can inform team members of such a requirement or write their own TH user guide.

Please note that you always have the option of reopening a case and even change its status (TP, FP, ...)

[mfosse71]

Ok
I kind of can see your point, and I agree that we are humans that can talk, but in my team we are #1 GeoGraphically Spread all across the globe(hence different working hours and then hard to "Talk") and #2 "tiered" in a L1--L3 approach which makes it possible to have different levels of analysts and that impacts the OPEX(L1s are usually less costly than L3) of running a IR Team as well as any other team... Just a thought