Currently if 2 users edit the same information the last store will effectively overwrite the other one. At the very least the users should be made aware of this. A simple solution seems to be to create module that keeps track for each module which entry is added, edited and deleted in the last X minutes. This information can in turn be used to indicate to other users certain information is volatile. Note that JAS16MAR002 may also rely on this information.

Currently JAS doesn't deploy any protection against overloading of the system. It seems wise to add protection against brute force login attacks and mass adding of information. As JAS16MAR001 will probably already create a "temporary log" of what's going on this may be used for overload projection. Alternatively JAS16JAN006 may also provide a way to limit submissions.

Editing the workflows is rather difficult, to make it easier the module itself should give more guidance (i.e. limit what you can fill in or rather visualize the current flow somehow. A better approach would probably be to add a workflow manager (optionally using the graphics plugin) to visualize and edit workflows.

Currently session management is handled in the default PHP fashion and thus resides on the webserver. To make it more flexible we'll need to support the following alternatives:Database (aka module based) Memcache / Redis File based Since sessions (both _session and _config) are quite fundamental to the functioning of JAS it seems wise to have as little dependencies on JAS to avoid circular dependencies. That said, replicating the Cache class seems futile as well... Configuration...

The current MD5 file signatures allows end users to check whether the file is still in tact. However it doesn't garanty the file (and MD5) haven'/files/ field and API should support PGP signatures.

Log table can fill up quite a bit, so it would be nice if it would clean up automatically. Multiple ways of doing this but the most logical seems to be to remove everything older than X days (configurable). A similar approach already exists for cache cleanup which simply the "next clean up time" and checks every time whether it's passed it and if so removes everything older than X. The downside of this is that (currently) it uses the session to maintain the "next clean up time" which means...

Question is how do you show closed issues in case they're always filtered. Maybe a "Show closed" option could somehow do the trick.