This one has me stumped, not that it is difficult to stump me.

When i turn on this module, all blogs on my test site disappear back to Feb. 8th 2007. The individual entries can be accessed, but the blogs turn up blank pages. Not "page not found" or "access denied", just blank pages.

i have two views that are filter out blog entries by particular users and display them in specific themes, and these pages also come up blank.

Turn off module and everything is fine.

i have no idea what's going on. i have "nodeapi_access_4.patch" applied, and these modules among many others: pathauto, taxonomy_theme, accounttypes, TAC, OG Content Types, OG Mandatory Groups by Role.

Comments

ben soo’s picture

ben soo commented

OK, tracked this one down to the OG audience targetting system. Early in Feb. i went from selecting 1 target group and also checking the "Public" key to not selecting any groups. The explanation under the "Public" check box says posts without groups are defacto Public. This doesn't seem to be happening for the blog posts.

If i take a blog entry that the anonymous user currently can't see, select a group audience and check the "Public" box, then it becomes visible to the anonymous user. Deselect all audience groups and the blog becomes invisible again to the anonymous user.

ben soo’s picture

ben soo commented

--It all goes back to normal if i turn off the OG User Role module.

ben soo’s picture

ben soo commented

Hm, things also go back to normal if i turn off "Integrate TAC and OG Access Control" in the OG User Role admin.

ben soo’s picture

ben soo commented

... now that i've read through all the online docs, the conclusion is that this is the desired behavior for this module, that it bypasses the visibility choices in the OG audience targetting system of the OG admin. Is that right?

i'll see what i can do with TAC for this. The big problem here is that most bloggers want to use remote blogging tools for entering blogs content and from a remote tool it isn't possible to select vocabulary terms.

i guess this might point to a deficiency somewhere, i mean aside from the one in my head.

somebodysysop’s picture

somebodysysop commented
Assigned: Unassigned » somebodysysop
Status: Active » Closed (works as designed)

Thanks for following up on this.

First off, TAC/OG integration was designed for a very specific use. If this conflicts with any more important function in your site, it is highly suggested that you turn if off.

OK, tracked this one down to the OG audience targetting system. Early in Feb. i went from selecting 1 target group and also checking the "Public" key to not selecting any groups. The explanation under the "Public" check box says posts without groups are defacto Public. This doesn't seem to be happening for the blog posts.

With TAC/OG engaged, it can't see these public blog posts unless they are in "og_public" (node_access table) realm. When you select 1 target group and also check "Public", this puts them in this realm, which is why you can see all of these posts. When you don't select any groups, then the audience defaults to public, but OG doesn't write them into the node_access table under "og_public".

If you also have no taxonomy term assigned to this latter group of nodes, then in the TAC/OG environment, they are effectively invisible.

i'll see what i can do with TAC for this. The big problem here is that most bloggers want to use remote blogging tools for entering blogs content and from a remote tool it isn't possible to select vocabulary terms.

If you don't really need TAC/OG, then turn it off. By design, your nodes *should* have taxonomy terms assigned with permissions (configured in Taxonomy Access Control) which determine who can see what. That was the whole point of creating this feature. I resolve the problem you're having by creating and assigning a "Public" vocabulary term to nodes that do not belong to any group but need to be available to "anonymous" users.

If you still want to continue to use TAC/OG integration with your remote blogging, then you will need to find a module which will automatically assign a vocabulary term to these posts entered remotely. Try Taxonomy Defaults: http://drupal.org/project/taxonomy_defaults

ben soo’s picture

ben soo commented

Wow. SomebodySysop, that is like extra crystal clear and super finestkind helpful. Thanks! Taxonomy Defaults looks like just what's needed.

We're trying to put together a public city site with self administering, semi-private sections for any local community org that wants one. Given the multitude of language and socio-political possibilities that might open up, i can't do without well defined access control and user role admin systems, and TAC / OG / OG User Roles are looking to be the modules around which the design will be built.

i don't think it could really work without your module. It's great.

As you can see, i'm sorting out the blend of what will be public and what will be private, and figuring out simple content input methods. i can't make it as nice as i'd like, not being a programmer, but it will hopefully be functional.

b

ben soo’s picture

ben soo commented

--i don't know if this should be a separate issue, and apologies if i post inappropriately.

On the blog filter views shown to anonymous users i'm seeing warnings like this:

user warning: Unknown column 'term_node_157.name' in 'field list' query: SELECT DISTINCT(node.nid), node.created AS node_created_created, term_node_157.name AS term_node_157_name FROM node node INNER JOIN users users ON node.uid = users.uid INNER JOIN node_access na ON na.nid = node.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 0 AND na.realm = 'og_public') OR (na.gid = 1 AND na.realm = 'workflow_access') OR (na.gid = 0 AND na.realm = 'workflow_access_owner') OR (na.gid = 1 AND na.realm = 'term_access'))) AND ( (node.type IN ('blog')) AND (users.uid IN ('9')) ) ORDER BY node_created_created DESC LIMIT 0, 35 in /www/docs/d5test/includes/database.mysql.inc on line 172.

Goes away on reload. Other pages generate other, similar warnings, which also go away on page reload.

Can't tell what generates it, but it only started showing up around the time i began seriously playing with blog views OG User Roles.

b

ben soo’s picture

ben soo commented

On a different blog filter view page, logged in user 1 sees this warning:

user warning: Unknown column 'term_node_157.name' in 'field list' query: SELECT DISTINCT(node.nid), node.created AS node_created_created, term_node_157.name AS term_node_157_name FROM node node INNER JOIN users users ON node.uid = users.uid WHERE (node.type IN ('blog')) AND (users.uid IN ('8')) ORDER BY node_created_created DESC LIMIT 0, 10 in /www/docs/d5test/includes/database.mysql.inc on line 172.

--i really don't know if this is the right place to post this since i can't trace the warnings to a module: many apologies.

b

somebodysysop’s picture

somebodysysop commented

user warning: Unknown column 'term_node_157.name' in 'field list' query: SELECT DISTINCT(node.nid), node.created AS node_created_created, term_node_157.name AS term_node_157_name FROM node node INNER JOIN users users ON node.uid = users.uid INNER JOIN node_access na ON na.nid = node.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 0 AND na.realm = 'og_public') OR (na.gid = 1 AND na.realm = 'workflow_access') OR (na.gid = 0 AND na.realm = 'workflow_access_owner') OR (na.gid = 1 AND na.realm = 'term_access'))) AND ( (node.type IN ('blog')) AND (users.uid IN ('9')) ) ORDER BY node_created_created DESC LIMIT 0, 35 in /www/docs/d5test/includes/database.mysql.inc on line 172.

OG User Roles does not generate this SQL.

ben soo’s picture

ben soo commented

ok, thanks. It must be the View then as that is the filter and sorting criteria it has. i'll go and post something there. Odd thing is i'm also seeing that warning on unrelated pages, like admin pages.

b

ben soo’s picture

ben soo commented

Narrowed it down to the RSS feeds that i set these views to provide. The feeds were always empty, and generated these warnings. Turn off the feeds, the warnings go away.

No idea why. Posted in the Views module issues section about it already.