Forum OpenACS Improvement Proposals (TIPs): Tip #77: (Approved) Package parameter scope and permissioning

I would like to add the following two fields to parameters in the .info file with associated support in the apm: SCOPE and CONTEXT.

Scope would be package or sitewide and would indicate whether there was a single sitewide parameters which would apply to all package instances or a per package parameter. The default would be package (matching current behavior).

Context would be either package, subsite, or mainsite and would indicate the permissioning context of the parameter and would default to "package" which matches the current defacto permissioning (which is to check admin on the package to get access to the parameter).

The motiviation for these changes is to allow us to create an admin interface which uses parameter permissions to drive which parameters a package admin can see and to correct the longstanding problem that some parameters are not sensible to have as per package parameters (executable paths for example where they are really site-wide).

I have not done the work for this but I wanted to gauge the level of interest in doing this before I approached it.

I totally agree that hits makes a lot of sense, so yes. Approved.
Collapse
Posted by Dave Bauer on
I have been thinking about this exact idea for a while now. We really need it. Especially in something like .LRN where you have hundreds of package instances and need to change parameter for all of them.
Collapse
Posted by Jade Rubick on
Great idea, Jeff. I approve.
Collapse
Posted by Caroline Meeks on
Approve. Very good idea.
Would it be useful to have parameters that are not visible through the web UI at all? Right now XCMS, and BCMS set the content folder, template folder etc as parameters. These should be set when the folder is created in an install callback. It probably doesn't make sense to allow changing it through the web interface.

I think using parameters for this is handy because they are stored in RAM and the cache is updated when they are changed or added, so its easy to write code that works as you expect.
This would require another permissioning context "none" or another way to control the ability to change the parameter through the web UI.