From 53e9df43dd7962275d000fb1b4dda9ff33e320ee Mon Sep 17 00:00:00 2001 From: Julian Fitzell Date: Wed, 21 Aug 2002 08:43:35 +0000 Subject: [PATCH] *** empty log message *** git-svn-id: http://mantisbt.svn.sourceforge.net/svnroot/mantisbt/trunk@1275 f5dc347c-c33d-0410-90a0-b07cc1902cb9 --- doc/FUTURE | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/doc/FUTURE b/doc/FUTURE index 6ee1fc2e5e..0a8ff30ade 100644 --- a/doc/FUTURE +++ b/doc/FUTURE @@ -1,6 +1,6 @@ -- Just Ideas (feel free to modify) -- -- david ulevitch -- --- $Id: FUTURE,v 1.5 2002-08-21 08:11:41 jlatour Exp $ -- +-- $Id: FUTURE,v 1.6 2002-08-21 08:43:35 jfitzell Exp $ -- Mantis rewrite. @@ -22,24 +22,37 @@ Primary: more complex and customized rules could be developed later. The basic idea is let something else decide whether the operation is allowed, not the API function itself. - (Why not? Doesn't it complicate it things if you move the rules elsewhere?) + -o (Why not? Doesn't it complicate it things if you move the rules elsewhere?) + -o [jf - I don't think so. Each API function has one call to check_permissions() + or something and passes what action it's doing (maybe just the function name). + At worst, we have whatever checks would have been at the top of the function + somewhere else (so no more complex code). At best, we can group functions + together that all require the same permissions. We could easily add a new rule + to all of them at once, etc. We could start storing it in a database, we + could change it so there is a permission matrix of permissions vs. users so + each user can have seperate permissions. We could add the ability to define + permissions by "groups" of users (I saw a bug filed about that). Basically, + there's some point in the code that maps permissions onto actions, rather than + the actions defining their own permissions.] -o Common functions to deal with INPUT, OUTPUT, STORAGE, etc. - -o Input? Isn't that just $_* and core_config_API.php? + -o Input? Isn't that just $_* and core_config_API.php? -o Output? You mean like core_html_API.php et al? -o Storage? As in ADODB's library? -o Use $_GET/$_POST/$_REQUEST/$_COOKIE/$_SERVER -o Consider moving configs to db. --o Create core_config_API.php, with configuration access functions. --o Move all core/function files to a seperate directory +-o Create core_config_API.php, with configuration access functions. +-o Move all core/function files to a seperate directory Secondary: -o Source documentation via phpdoc (or similar) - -o phpDoc (phpdoc.de) + -o phpDoc (phpdoc.de) -o phpDocumentor (phpdoc.org) -o Are there any DB schema cleanups that could be done while we're making major changes anyway? Might be a good time to justify one big change if necessary (not sure if there is, just throwing it out there to think about) -o We can update the version to use an index, while we're at it? + -o jf - that's the one thing I was specifically wondering about... + not sure if there are others What else?