Posted by sirkitree on November 26, 2008 at 8:27pm
| Project: | SimpleTest automator |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
I can install this module fine on my dev environment... however anytime I go to configure the darn thing it is somehow enabling a crapload of my modules that I do not want enabled. Note that it is enabling them, not installing them, therefore I get all kinds of "{table} doesn't exists" errors. Very infuriating and not usable. I've put all the necessary settings.php logic that simpletest and simpletest automator tells me to do. Have I done something wrong?
Setting as critical because at this point it is not usable.
Comments
#1
I can duplicated this with the DRUPAL-6--1 branch. Fortunately i had a database backup.
All the modules are enabled with the following call on line 405 of simpletest_automator.module:
<?phpmodule_enable(array_keys(module_rebuild_cache()));
?>
#2
I've got the same problem.
It enabled my all modules which were disabled, even those which were invalid causing WSOD and breaking the website.
Tested with latest dev.
Fortunately I had a database backup as well.
#3
#4
Removing this line helps.
#5
Hm, we need to enable the modules to get their permissions I guess... but perhaps we've forgotten to disable them afterwards? I don't think removing that line is the solution.
#6
1. Why not to invoke hook_perm from all active modules?
2. Or drupal_get_form of permission table (user_admin_perm)?
3. Or to read permission list from permission table based on specified roles which can be changed of course.
4. Or something similar to user_admin_perm()
<?phpforeach (module_list(FALSE, FALSE, TRUE) as $module) {
if ($permissions = module_invoke($module, 'perm')) {
$form['permission'][] = array(
'#value' => $module,
);
...
?>
Because nobody want to test some permission from inactive module.
#7
Right, but modules may have been enabled for SimpleTest automator that currently are not enabled on the site, so we're going to need to do some trickery here, I believe. I need to look more closely at the code.
#8
any news?
sorry, but I don't know even what this code is trying to do.
why activating all the module on the Drupal installation is needed again?
if somebody need some additional permission, he can activate the module by him-self manually.
#9
If you have better solution, please commit the critical bug fix first, and then you can commit some changes, because currently this module breaks the whole website completely.
If you don't have time, please assign me to CVS access.
#10
In case anyone else is still following along, the version in this commit (just a couple of commits back), is functional. I haven't tested it extensively, but I was able to generate some basic tests without having the rename a bunch of the generated function names, as I had to with the 6.x-1.0-beta2 version. Also, it does not exhibit the bug mentioned here where all modules get enabled.
The one minor issue I did notice when recording tests was that clicking on the "Stop automator" link also prompted me to choose whether I wanted that link text added to the test. I would assume that removing the event from that link shouldn't be too difficult, but I haven't looked into that yet.