Follow-up Comment #17, sr #711 (project savane):
MORE information:
I installed webmin (so I can dig around in MySQL easily without having to
deal with its infernal commandline interface and syntax). I am looking
inside the "savane" database. In the "group_type" table, I see that
"can_use_bug" is set to "1" rather than "0" (in ALL of my Group Types). So,
we at least know that when I told each Group Type form to allow Groups that
belong to that Type to permit use of the Bugs Tracker that this preference
was in fact recorded in the database.
This tells me that the This Group Active Options script editgroupfeatures.php
(or something that it depends on) is not properly querying this item. And
attempting to go to the Bugs Tracker page for any project gets an error
message that the feature in question was turned off for this group, so we
also know that the script that the .../bugs script is having the same
problem. The editgroupfeatures.php script is NOT getting false results for
anything else when it comes to what should be *available* according to the
group type (as opposed to what is enabled or disabled for the group in
question). For example, I changed the Group Type for a type that I called
"Test1 Type" so that its "can_use_mailing_list" now says "0", and the group
"Test1" available under this group type no longer has a Mailing-List option
available under it. That is as it should be, then. None of the groups, in
any type, are showing Patch Tracker, Forum, Arch or SVN either, since I made
them unavailable in all group types. So far so good, and we know that the
group_type table (and whatever writes to it) is not the problem.
The table "group_preferences" is completely empty. That seems a little
disturbing.
The table "groups" seems to be VERY problematic. The group data does not
seem to come anywhere close to matching what the This Groups Active Features
script (editgroupfeatures.php) reports. For example:
Group "test1" has all of its "use_*" values in the "groups" table set to "0",
except for "use_homepage" = "1". But in editgroupfeatures.php for this group,
everything is checked ON when this script loads, except for "Bugs Tracker"
(and not counting disabled things like Forum and Patch Tracker, which are
just absent, as they should be).
Group "test2" has ALL of the "use_*" columns set to "0", but its
editgroupfeatures.php has all of them turned on except for "Mailing-List",
"Bugs Tracker" (which should be on but isn't), and again the unavailable ones
like Forum, SVN and Patch. So, really test1 and test2 are giving essentially
the same results in editgroupfeatures.php, while their "groups" table options
are virtually opposites. (But see below - I think this may be because I
haven't attempted to edit "test2" through the Active Features script yet.)
Group "test3" has the following listed as "1": use_homepage, use_mail,
use_task, use_cvs, use_news, use_support, use_bugs. In
editgroupfeatures.php, the options that are turned on are Homepage,
Mailing-List, Task, CVS, News, and Support, but also Download. The
"use_download" column is definitely "0" in the database!
Group "test4" is precisely the same as "test2" in every way.
Group "test5" has all of them set to "0" except "use_bugs" = "1". It's Active
Features page has everything turned on except "Mailing-List" and (as usual)
"Bugs Tracker".
I did earlier, during my php.ini tests, try changing the Active Features
options for test1, test3 and possibly test5. This probably accounts for
their differences in the database, though it's notable that their displayed
options enabled on their Active Features pages differ.
As an experiment, let's monkey around with the test4 group. All of its
database "use_*" columns are "0". Its Active Features page says that
everything that the group type has made available to it (Home, DL, Support,
Mail, Bugs, Task, News) are ON, except Mailing-List and Bugs Tracker. I have
just changed Mailing-List to ON and submitted the form.
It shows up as being turned on in the form, when it reloads, as I expected.
What I did not expect is the database result. group4's database "use_*"
columns were all "0" before, but now all of the following are "1":
use_homepage, use_mail, use_task, use_cvs, use_news, use_support,
use_download. On the other hand "use_bugs" remains "0", as do the options
the group type did not allow (use_forum, use_patch, use_svn, use_arch,
use_extralink_documentation).
Back to the editgroupfeatures.php for this project, everything available is
now "on" except for "Bugs Tracker". After logging out and logging back in,
this is still true. Oh, FYI, test4 was still flagged as a "pending" group.
The group "test2" was the same as "test4" except "approved" rather than
"pending". Again, everything is "on" in editgroupfeatures.php except for
Mailing-List and Bugs Tracker, and the "groups" database table has "0" for
all of its "use_*" columns. I am repeating the previous test, and turning on
"Mailing-List" on the Active Features page for "test2".
I get precisely the same results in the database as I got for test4. Still
in "test2", I turn OFF "Mailing-List" and attempt to turn ON "Bugs Tracker".
After editgroupfeatures.php reloads, it shows "Mailing-List" OFF (correct) and
"Bugs Tracker" OFF (incorrect). Now it gets interesting. In the database it
now correctly says "use_mail" is "0" and again correctly that "use_bugs" is
1; nothing else changed. So, this means that the database now knows, as it
should, that I turned on the Bugs Tracker. But if I go and reload
editgroupfeatures.php for the "test2" group, it again correctly says
"Mailing-List" is off, and INCORRECTLY says that "Bugs Tracker" is off. If I
attempt to go to /bugs/?group=test2 in my browser, it says "Error: This
project has turned off that tracker;". So, despite the fact that the
database knows this feature is on (I just looked at the database again, and
it does still have "1" for "use_bugs" for the "test2" group), the frontend
can't seem to recognize this fact, not just in editgroupfeatures.php, but in
general.
Other group changes like adding a public description, or changing test5's
unix (or public) name to test6 (or Test6, respectively), are properly
reflected in both savane's frontend and in the database, no problem.
The "group_history" table doesn't seem to show anything informative as to
these problems. It does show "Changed Activated Features" entries for
"field_name" for the stuff I just tested.
The "groups_default_permission" table is completely empty of data, which
doesn't seem right either. Hmm... The columns are there ("bugs_flags",
etc.) but there are no values assigned for any
"groups_default_permissions_id" (in fact, there are no
groups_default_permissions_ids; no data at all.)
There appear to be 95 tables in this database. Any others I should examine
and report on?
Anyway, I am beginning to get the feeling that the values for the Active
Features in the "groups" table aren't what is actually controlling them.
They all seem to default to "0" on group creation, but when one first goes to
the Active Features script many of them appear checked "on". After submitting
that form, any that were checked (either by default when the script loaded the
first time, or because it was manually checked), show up as "1" in the
database, but this seems to have no effect at all on what it shown by the
Active Features script upon reloading, and also has no effect on what
features are *actually* available and which produce "This project has turned
off this tracker" errors.
So... where ARE these values stored for real? Where do .../bugs and
.../editgroupfeatures.php get their actual data from?
This is about all the debugging I can take for one night, so I'm signing off
here. :-)
_______________________________________________________
Reply to this item at:
<http://gna.org/support/?func=detailitem&item_id=711>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
