New Content Types are Disapearing and Reappearing

Wow that's crazy. I'll be checking this out in the next couple of days and I'm nearing the time when I need this to work for my own projects, so this is a priority for me as well.

To clarify. One state is fine, the other is not, correct? So if you leave it in the fine state, you're okay for now?

I'm bumping this up to critical. Thanks.

Meanwhile, if you want to throw a drupal_set_message('<pre>Form values: ' .print_r($form_values, TRUE). '</pre>'); in the submit (and maybe validate) function for that page and see if there is anything obvious, that would be great. Otherwise, you can wait for me to do it. Either something must be changing in $form_values, or something must get handled differently when the page is loaded. Or...???

did a form_values dump at beginning of function "og_content_type_admin_submit", and values seems to reflect what is expected : all content types are listed with appropriate settings.

this is a print_r of $required_status after beiing unserialized...

after clicking on "save assignement" again, I find :

So this confirms my first comment... I'll investigate deeper ...

click on "save assignament" justs take back to first situation.

problem come from there :

What activated in gid = -1 (in siteWide configuration) will be deactivated. And what is not activated will be activated...

I'm not sure I'm understanding correctly your option. This is how I thought it works : "Allow" on a type "t" on group "g" meaned in my view that type "t" was allowed to group admins of group "g" to give or not rights to group "g" users to use type "t".
So unchecking "allow" was a way to ensure that this group would never be able to use content type "t".
Checking "allow" was a way to give the possibilities to group_admin to choose if their users could use or not type "t".
And "required" was a way to ensure that group "g" members should have access to content type "t" without their group admin beiing able to cancel their access...

If this is not how that meant to be, please help ! ;)

I corrected my problem for now by changing DEACTIVATED to ACTIVATED in the line :

You are correct in understanding what the code is SUPPOSED to do for groups, but not for site-wide content types. I am on the page you specified (admin/og/og_content_types/admin/-1) and am clicking 'save assignments' over and over and nothing on that page changes. Do you see a visible change there? Or just in using the content types?

I think I followed your procedure, but I don't get any problems. Here is what I did: As admin, went to the above-mentioned page (let's call it "page -1"), clicked 'save assignments', logged out, logged in as a regular user, went to node/add, saw that everything was okay. Then, I logged out, logged in as admin again, clicked "save assignments" on "page -1", logged out, logged in as a regular user again, went to node/add, saw that everything was still okay. I repeated this a few times with no changes.

So I'm wondering if you are using the latest dev version. You mentioned that you placed that printr inside og_content_type_admin_submit, but that function was renamed quite a while ago to og_content_type_admin_admin_submit (someone pointed out that the function, which is admin_submit, and the module name, og_content_type_admin are the two parts that should make up a full function name which is why the 'admin' part is now doubled). Also, the "page -1" should have all checkboxes in the ALLOWED column disabled and checked. Is that what you see? The only checkboxes that the admin should be able to use for the "site-wide" settings are the REQUIRED ones. See the attached screen shot for a partial page view of what is should look like.

Anyway, if you see the above page as it should be, then you should only have to REQUIRE site wide pages and the portion of code just before the part you pasted should take care of it.

It would seem that since you are the only one having this problem, there is something unique going on here. With that said, the unserialized $required_status is wrong. All of those 1s should be 2s. The types_active database column holds 0s, 1s, and 2s meaning DEACTIVATED, ACTIVATED, and REQUIRED, respectively. As was mentioned before, you should not be able to ACTIVATE site-wide content types, only REQUIRE them. If those 1s were all 2s, then you wouldn't be getting to the code you posted and everything would be fine.

So you should change back the code to the way it was (because it actually is correct), and figure out why those 1s are not 2s. Or just hack your database entry and change them to 2s manually.

Attachment	Size
OG Content Types - Anatolia_1189105188078.png	12.87 KB

I think I followed your procedure, but I don't get any problems. Here is what I did: As admin, went to the above-mentioned page (let's call it "page -1"), clicked 'save assignments', logged out, logged in as a regular user, went to node/add, saw that everything was okay. Then, I logged out, logged in as admin again, clicked "save assignments" on "page -1", logged out, logged in as a regular user again, went to node/add, saw that everything was still okay. I repeated this a few times with no changes.

Very quick procedure is to enable the Naviguation Block, and let "Create Content" menu to be always expanded (or expanded by the mean of DHTML module). With this trick, I had to click only on "save assignements" to see the change in menu "Create Content". And this was happening in with full privileges (logged in a role with all ticks in "Access Control") !

Other bugs where happening as a result in other roles.

You mentioned that you placed that printr inside og_content_type_admin_submit, but that function was renamed quite a while ago to og_content_type_admin_admin_submit

I'm sorry, after checking, I've added the print_r in the og_content_type_admin_admin (double admin). I just didn't realize this double affair when writing my comment ;).

Also, the "page -1" should have all checkboxes in the ALLOWED column disabled and checked. Is that what you see?

Yes, that is what I was seeing. (I solved the problem as indicated in my previous post). But I think I could reproduce the behavior by setting back the code as it was written.
After looking to your screen capture, I am sure that we have the same display (at the exception that I hadn't any tick in the REQUIRE column).

With that said, the unserialized $required_status is wrong. All of those 1s should be 2s. The types_active database column holds 0s, 1s, and 2s meaning DEACTIVATED, ACTIVATED, and REQUIRED, respectively. As was mentioned before, you should not be able to ACTIVATE site-wide content types, only REQUIRE them. If those 1s were all 2s, then you wouldn't be getting to the code you posted and everything would be fine.

I'm aware that I seem to be the only one having this problem. This might come from a bad module installation or something else.
But your answer seems to confirm that I must have misunderstood the DEACTIVATED, ACTIVATED and REQUIRED semantics ... Let me ask these simple question that might light my bulb :

Should a non-REQUIRED content type (in site-Wide configuration) be displayed in "Create Content" page ? What would be their code (0, 1, or 2) ?
"you should not be able to ACTIVATE site-wide content types" : is it because it would be redundant with "Content Types" administration page where you create content types expectedly to use them somewhere on the site ?
That's why you have a disabled AND checked checkbox in the ACTIVATE columns ? So sitewide settings for content type should be always ACTIVATED (or REQUIRED which implies ACTIVATED) ?

Why if "you should not be able to ACTIVATE site-wide content types" did you write :

which tests ((type == activated) && (page == -1)) (which is a case that should not happen ?!)
as a result of this test, why do you set type to DEACTIVATED ?! (these should'nt be ACTIVATED always by default ?)

Setting types to DEACTIVATED in this special case seems to deactivate type for everyone on all the site.

And why :

here you are testing ($group == 0) ? , this looks like an horrible bug !! "$group" is the group name, isn't it ? a string !!, so ($group == 0) is always true... ? And logically, this will lead to :
if (type==DEACTIVATED) then assign type=ACTIVATED).

Which seems to perfectly match what is happening on my computer.

Why is it so important to set DEACTIVATED in the first case ?

if those 1s were all 2s, then you wouldn't be getting to the code you posted and everything would be fine.

Should I understand that I have to check the REQUIRED boxes in the site Wide to use a "Content Types" ?

Hope all that will help...

You ask some good questions and I'm happy to answer them.

First:

Should a non-REQUIRED content type (in site-Wide configuration) be displayed in "Create Content" page ? What would be their code (0, 1, or 2) ?

Because the site-admin is essentially the supreme group owner (if you look at site-wide as a super group) and there is no place to put a "Manage group content type" menu item for the whole site; and as it would be redundant anyway, there should only be two states for site-wide content types - on or off. In the case of site-wide content types, on = REQUIRED = 2, and off = DEACTIVATED = 0. The unused option, ACTIVATED, is only useful for group owners. In this case the site admin has said to groups, you may use this, because I have ASSIGNED_TO_GROUP it, but I have not REQUIRED it, so it is up to you to ACTIVATE it if you want to use it.

A caveat here is the group owners can use all ALLOWED content types, even if they don't ACTIVATE them for the rest of their group. In this way, you could ALLOW groups to have blogs, but instruct group owners not to ACTIVATE them (or disable their ability to change their own settings). That way, the group owners could run a group blog without each user starting one.

That's why you have a disabled AND checked checkbox in the ACTIVATE columns ?

It's actually the ALLOW column. There are two sets of constants. I've already explained the first set, DEACTIVATED, ACTIVATED, and REQUIRED are handled by the Required column. The second set is ASSIGNED_TO_GROUP, NOT_ASSIGNED_TO_GROUP and is handled by the Allow column. This last set refers to whether the group has the ability to use a content type. If ASSIGNED_TO_GROUP, a content type must also be ACTIVATED or REQUIRED for general group members to be able to use it. The exception is the caveat I mentioned above.

Why if "you should not be able to ACTIVATE site-wide content types" did you write :

What I mean here is that no user, admin or group owner, should set it MANUALLY. There is no form that would result in a content type in the site-wide group to be set to ACTIVATED. The only options are DEACTIVATED and REQUIRED.

here you are testing ($group == 0) ? , this looks like an horrible bug !! "$group" is the group name, isn't it ? a string !!, so ($group == 0) is always true... ?

First, $group is the group ID which is a number. Second, strings and numbers in PHP get along quite nicely and strings are not equal to 0 unless the string is actually the number 0 or equivalent to the number 0. Third, two fictitious groups are in use here - the first is the site-wide group which is using the fake group ID of -1. The second is the default group and is using the group ID of 0. So don't worry about all content types be deactivated/activated with this code. That won't happen at all. The reason for using these fake group IDs is so that all sections of the content type management can be handled with the same code. And as group IDs are all greater than 0, it makes sense to use the first two available numbers, 0 and -1 for fake group IDs.

Should I understand that I have to check the REQUIRED boxes in the site Wide to use a "Content Types" ?

Yep. And I bet that if you restore the code to how it was in the first place, then check ALL of the REQUIRED boxes in the site-wide section, save it, then uncheck the ones you don't want used, that the bug would go away.

I suspect you used an early version of this module and then upgraded. For some reason I myself was not afflicted with this issue and so did not find this case. What puzzles me is that once DEACTIVATED, those content types don't stay that way. I'll have to double check, but for now, I would suggest simply copying over your existing module files with the latest version.

Hope that makes the light bulb turn on for you.

BTW, in the Site-wide section of the content type assignments, it reads:

Since you are the group owner of the entire site, it doesn't make sense to have more than one control. REQUIRE the content types you would like to have activated at the site-wide level.

Thx, this is a little bit clearer.

We know have 2 problems left :

I did a print_r on the group variable "$group", and it is a string in my installation. It's the group name. This explains why ($group == 0) is always true, thus DEACTIVATED content type gets ACTIVATED for siteWide assignements. I've looked at the code and this seems quite normal that it is a string, you might have wanted to check $form_values['group'][$group]['gid'] == 0 . I must admit that it maybe a bad idea to have your array index beiing '$group' the name of the group rather that it's gid ! (gids are unique, not group names !). I did download 5.x-1.x-dev a second time to check that I had the correct version.

To this part responds the second fragment of code which appears to me correct, will DEACTIVATE all content type in SiteWide configuration if found to be ACTIVATED.

I've corrected this in my code, reset my previous changes, and after 2 "saving assignement" I got a stable behavior : With no checked boxes in REQUIRE nor in any other group, I cannot access any "Content Types", which seems to me that it is what is expected.

This do not answers why this bug isn't showing in your installation !

I just ran a test on the value of $group just before and just after that elseif statement. It is not TRUE all of the time as I would expect it not to be. In my case at least, it's only firing the contents of the elseif for the site-wide group. If yours was firing for the site-wide as well, and none of the REQUIRED boxes were checked, then upgrading from a previous version of this module would have produced the behavior you've been describing.

In any case, you are correct in that the line with the $group == 0 is wrong. It should read:
PATCH inside the function og_content_type_admin_admin_submit
if ((($form_values['no_change'] == 1) && ($form_values['groups'][$group][$type]['allowed'] == ASSIGNED_TO_GROUP)) || (($form_values['groups'][$group]['gid'] == 0) && ($form_values['groups'][$group][$type]['allowed'] == ASSIGNED_TO_GROUP))) {

Notice that I did it correctly a few lines up in checking if the gid == -1.

The first conditional (before the ||) will set all group's ASSIGNED_TO_GROUP content types to ACTIVATED if you've checked the box preventing group owners from ACTIVATING them themselves. Otherwise group users will never be able to use those types. I suppose I could have set them to REQUIRED.

Anyway, the second set of conditionals SHOULD deal only with the 'Default' group. So you're right that the gid should be checked. Because group owners who haven't customized their content types may not want to, if you add a new content type, they might not know to ACTIVATE it. So, by default, I make any ALLOWED types in the default group ACTIVATED. This ensures that all non-customized groups are in the same state. At least, that's what was supposed to happen. I'm not sure what it was doing before. Actually, like I said, in my case, it looks like it was working on the site-wide group.

SOOOOO, it looks like we found the bug you identified and why it was doing what it was doing. But that little bit of code does seem to be the only problem.

I'll include the fix in the next release. Thanks for noodling this out.

So I think this is fixed.

Okay, all seems to be working now that I did the changes...

But I'm concerned by an other problem that is illustrated here : you use the group name as index in your table.

A simple test case can be made :

Say you use subgroups and that you have several community groups :

CommunityA
CommunityB

In each community, you want to add distinct subgroup titled "news". Each community could then subscribe to a specific "news" category : if in group "news" of "CommunityA" you'll have access to "Aggregate News" Content or a FeedApi content that would feed new nodes ONLY for the corresponding "Community/news" group.

The problem with your module is that two groups have the same name : "news"...

The effect of the current implementation is that all settings made to one group "news" will be done on both group "news"... Or that it what we seem to understand when using your interface.

Do you understand this second and unrelated problem ? do you want me to open a second bug report ?

That would not be a bug in my opinion, but rather a feature request for compatibility with a module for which this module was not originally designed to be used with. I will, however, put a note on the front page to not name your groups the same thing.

I just tried having two groups with the same name, and it partially works. It is able to store and maintain the content type assignments, but it can't display both on the page where you're trying to adjust all groups' settings at once.

Anyway, this is all separate from the issue that was fixed and needs to be treated that way, not tacked on to this issue.

I had a similar problem in that I wanted to add a new content type that was sitewide and not group specific. It would not show up on the "Create Content" page. I found this page here and installed the new version of OG Content Type Administration. That still did not fix it. I had to completely delete the module, uninstall it from the module interface, set up the new content type, reinstall the OG Content Type Administration, mucked around a bit more, and now I think it's finally working.

Only, I started to get a syntax error with the SQL on an old unused group even though the site was working fine. Then I deleted that group and the bug somehow navigated to the rest of the site (don't ask me why). I finally gave up and commented out the error message being generated since otherwise it all seemed to work.

Still, it seems a little harder than it should be to add a new content type that is not specifically just for groups.

Thanks for your work on the module however.

That's very strange behavior you report and should have been opened as a new issue. It's only chance that I happened upon this message since the issue is closed.

On my installed systems, I am able to add content types as I wish. When I do, one of the messages indicating successful creation of the content type tells me to remember to change the OGCTA settings and provides a link to do so. Assigning and unassigning from the groups, including the fake 'sitewide' group works as expected. On multiple installs, I have created or installed modules which created, new content types which I then 'required' only in the 'sitewide' group and which were not used in individual groups.

So if you still have issues, post them as new ones.

I am using Content Type Administration by Organic Group.
My new content types will not appear on the block...tearing my hair out playing with the OG content types checkboxes, as fiddling with this seemed to fix the bug last time...no such luck now.
how do i overcome the bug?
thanks