If there is a query on features_access if the space is passed the check is performed on the current space, not the space passed in.

See patch: altered the variable_get to use the space controllers variable get.

CommentFileSizeAuthor
#6 825048_access_feature_is_being_akward.patch680 byteshefox
plugins_space_type--1.patch780 byteschristianchristensen

Comments

jmiccolis’s picture

jmiccolis commented

This patch looks ok to me, but I'm somewhat concerned about all the other spots in the API that aren't going to support this type of usage. Speaking of... what exactly are you trying to do which brought this to your attention?

christianchristensen’s picture

christianchristensen commented

I believe the way we saw a problem here was with cache; it was a little unclear as to why (even with saving enabled/disabled) the states of the features would not load correctly. A coworker (randallknutson) had used the spaces variables api through the class and thought this might be more appropriate solution this low in the spaces classes. It has seemed to work fine since the change...

Would it be worth changing the references to variable_get's to using the spaces class accessor...maybe just in the spaces.module?

jmiccolis’s picture

jmiccolis commented

I don't completely understand what you're saying. What do you mean by "I believe the way we saw a problem here was with cache"? The Drupal page cache? A reverse proxy cache?

thx.

christianchristensen’s picture

christianchristensen commented

Sorry about that - to be more clear: we were looking at the return value from the variable_get after going to a feature admin menu (Enable/Disable) and saving the form. Upon submit the enable value of a specific feature would remain in the previous state, despite saving the form. I looked into it as far as altering the variable_get to actually using the spaces object, so I have made an assumption that the variable_get was returning cached values (I guess if I dug in a little more this might not be true...)

glennpratt’s picture

glennpratt commented

My memory is foggy because this was a while ago, but I thought I'd try to help explain.

We ran into this because we were trying to check enabled feature in a different space than the current space. Example, render a link to Case Tracker in various groups, only if it's enabled in those groups.

So we load a space, then check if a feature is enabled in that space at $space->access_feature, except this returned the expected results for the current space, not the loaded space.

hefox’s picture

hefox commented
StatusFileSize
new 825048_access_feature_is_being_akward.patch680 bytes

Should this function be checking 'access content' or someone above? that assumes a feature is 'content' which is not necessirly so, though the general case is true. (I'd be weary of using the function based that to test things for a space as it fails if current user doesn't have access content despite the feature being enabled for the space).

Anyhow, the access content check has an issue also, cause $account is being passed in but isn't being passed to it.

patricksettle’s picture

patricksettle commented
Status: Needs review » Reviewed & tested by the community

#6 patch tested successfully here.

patricksettle’s picture

patricksettle commented
Status: Reviewed & tested by the community » Closed (fixed)

Patch commited in 6.x-3.x and 7.x-1.x