"my ads" links are displayed to all users

It appears the default "my ads" and related views aren't properly showing up in the 5.x tree. The path was supposed to be "ad/user/UID" where UID was the user ID of the 1, but it looks like I need to revisit this logic. I'm not sure how you got an empty link, in my case there's no automatically generated link at all.

I also need to remove these links. I cannot seem to find where they are defined or get added into the system. I have modified the views to have no menu links, and then cleared my menu cache, but they are still there. (Even though they are not listed in the menu table)
Is there some function somewhere that stuffs them into the menu array after it has been loaded?

I have the same question about the navigation links. I don't want them to be available to anonomous or even authenticated users, only to site admin, but there is no way to remove the link since it doesn't show up on the menus page.

Unfortunately views support for the 5.x version of the ad module is lousy at the moment, and I've not had time to dig into it. (I don't use 5.x, so unfortunately this is a lower priority for me.) If you're having problems with the links generated by ad_views.inc, I suggest you remove that file (or rename it) then the ad views will go away. If you need the ad views, then perhaps you can submit a patch to help clean it up... ;) Otherwise, wait and I will eventually get to this.

this is still a problem for the released version today. Not that it is showing a page not found.

It's showing for non registered users like zhaor says.

Just adding a data-point . I am running ad-5.x-1.3-2 (on drupal 5.1) and the problem of having the 'my ads' menu item show for anon users still exists. Although when followed it does correctly state that "You have no ... ads."

Have the same problem - exept that I have two menus - "My ads" and "My active ads". Dont realy see the use for those menues anyway - at a normal site (like mine) the admin sets the ads - and that is possible (and more logic) from the Administer menu. Just give the location in the code for those menu objects so I just can remove them.

A fixing hack - disable the menu items "My ads" and "My active ads" by changing the lines 342 and 385 to:
$view->menu = FALSE;
the function can be reached att ad/user//active if you need it. (My ads shows 404 any way).

Sorry - forgot to name the file - its in ad_views.inc - and you need to run the update script afterwords.

I would prefer that it gets fixed by using a user_access such that if you do allow users to add Ads they can see the parts of that menu that make sense for them but for anon users I don't at least on my sites want them to see this.

Adding myself for tracking.

subscribing

changing title back to it's original titling.

I got the changes above to stick by clearing all the cache_ tables in the database. Hooray!

How'd ya do that?

go into phpmyadmin
locate all cache tables
check mark them
click empty

I had a very similar issue where roles that are only supposed to be able to see ads, but not manage or create them, were getting the My Ads menu appearing in the Navigation menu. Not a big deal. However, the major problem was that they were seeing *all* ads, not just their ads. When I added the Ad view to the main Views list, I noticed that the filter for "Ad: Owned by current user" had nothing set in the Value field. It should be TRUE. However, this still showed all ads to the current user. I had to add in a new filter "Node: Author is Current User" and that stopped other people's ads from showing up.

I tried the latest dev version (2007-12-05) too and the issue still existed. I have created a patch that adds in the TRUE value and the Node:Author filter.

Make sure you empty all the cache tables (or at least the menu and views ones) after applying the patch, otherwise things will not work properly.

Oh, and if someone can figure out a way for the View to pull in the access control settings for each role i.e. roles that cannot manage ads don't get to see the My Ads menu), that would be great. For now, I Added the views and set the access control settings manually.

This is still a problem with the released ad-5.x-1.4.tar.gz. Anonymous users see the my ads menu with the submenus available to them. Any planned fix for this with a newer version?

No patches have been submitted, and as I'm not currently using Views myself this is still low on my todo list. (I'm actually surprised no-one has submit a patch yet, as it shouldn't really be all that difficult of a fix.)

yeah, this is kinda annoying...

"my ads" link shouldn't show up to anon users...

Close but no cigar. I don't think adding a second filter is the best idea. The attached patch fixes the problem of the original filter: the query was being cached by the views cache but it included the uid of the first person to view the filtered View. In your case this was probably uid=1, thereby allowing all ads to be visible to all users. Setting the filter to use '***CURRENT_USER***' instead of '$user->uid' prevents the query from being cached.

I'm not sure that it's possible to configure Views menu items to only be displayed under certain conditions, but I'm pretty sure that's a bug in Views, not a bug in Advertisements. I'll keep tinkering anyway.

Excellent, thanks for spending the time to track this down, and for the patch! Committed.

Please test this, as I haven't actually started using Ads module yet.

Here's what this patch does:

1. adds an access rule to only allow authenticated users to view the user_ads and user_*_ads views
2. converts the user_*_ads menu items to tabs instead of sub-menus
3. removes the call to global $user; that I missed from the last patch

I should note here that I was very confused by the 'access all views' Access Control setting. I did have it checked for all, but it's clear from the views.module source that it is in fact an Administrator role's setting and should not be checked for the Anonymous role.

Updating issue status. Note, please generate patches against latest CVS -- the global $user was already removed when I manually merged your earlier patch.

Here's an alternative patch for the issue of ad views & their associated menu items (My ads) being available to inappropriate roles. This patch sets the views' access to those roles that have the "create advertisements" permission. I have tested it in my own setup and found that it works as required, with the following provisos.

• Make sure 'access all views' permission is NOT granted to any roles that should not be able to access the ad views (as wad says at #23).
• Empty table cache_views, then cache_menu (in that order) after:
  • applying the patch;
  • changing the roles that have "create advertisements" permission in Access Control.
• Changes to a user's roles, taking them into or out of roles having "create advertisements" permission, appear to take effect without needing to empty cache tables.

Testing, comments & improvements welcome!

Dave

Looks nice and simple. Feedback from testers would be great -- any reason not to merge this?

Sorry for the profusion of patches but here's a more efficient version of my patch at #25 - avoids running the same db query (in user_roles) for each view, so saves 7 queries each time ad_views_default_views runs.

Still looking for feedback/testers, people using ad and views...

I've added the patches available in this thread, but I'm having an issue where a user cannot see his submitted ads.

I've checked the permissions, the views filters, the sql queries, but I just can't seem to find the issue.

My issue was that I needed to rebuild the the permissions in post settings. I will proceed to test the patches!

im a noob at this stuff and i cant figure out how to set my iis. im trying to find out how to stop the cozz but im not sure where to start. i think it might have something to do with a proxy or something but im not too sure.

wtf? Why are you changing the title to something completely meaningless and changing the topic to something completely irrelevant? I'm setting it back again.

I'm hoping to roll a new release this week -- it would be great to have this issue fixed (otherwise I'm going to remove Views support altogether in the next release). Anybody willing to own this issue, and do some testing?

I don't have a lot of time but could devote 1-2 hours per day to testing.

I've had issues with ads not displaying in the past as well. Since I also run Domain Access, it would be useful to test how Ads works with DA

I'm referring to the "my ads" bug reported in this issue -- there are patches in this issue that need to be tested and reviewed. Please keep things topical to this issue, if you have other problems please discuss them in the correct issue.

Sorry. Just trying to help

Help is appreciated -- if you wish to help, please review the above problem reports and test the provided patches, then provide feedback... :)

Last patch was applied. Testing appreciated.

I upgraded to the 5.x-1.5-rc1 version of this module today. As far as I understand through reading through this issue, the "my ads" should no longer be showing for anonymous users. Unfortunately, it still does for me. I even tried unchecking any permission related to the module, then rebuilding the access permissions, but to no avail. So, I guess the status should be returned to active.

There are several patches in this issue queue -- anyone with an interest in seeing views support in the next release of the ad module, please test them all and provide feedback. Otherwise, it's looking very likely that views support will be removed.

I may have been a bit premature in stating the problem still exists. I tried the April 19th 5.x-1.x-dev release and at a first glance, it seems to work as it should. I no longer have the "my ads" menu item showing for anonymous user or people without "create advertisements" permissions.

My bad, I guess. Not sure if I should return the status to fixed though, or if more testing by others is desirable instead.

There have been no views related changes between 5.x-1.5-rc1 and 5.x-1.x-dev. The only change at all was this one here.

If things are fixed now, I'm guessing the problem was cache related. If so, it needs to be tracked down and an update needs to be added to ad.install.

Yes, code looks good and works when tested.

This somehow didn't make it into either 5.x-1.x-dev or 5.x-1.5-rc1. It fixes the current user filter as in #21 above.

Ha! Well spotted. How did that get back in there?

Thanks, applied.

Automatically closed -- issue fixed for two weeks with no activity.