Displaying only content types that user has permissions to

I was just about to report this too.

I will take this on as something that I think I can do. I'm changing this to a task and assigning it to myself. I hope that's OK.

Fago, feel free to correct and instruct me. This my first time to contribute code, and get acquainted with that aspect of the issue queue.

Indeed, that's broken. It's related to http://drupal.org/node/236926.

further note: We need to properly check node_access() and not "emulate" it.

I've updated some code, and it seems to fix the problem. The solution was to use core menu access features, instead of checking on our own. (emulating it.) I removed a lot of the main "if", and used access arguments instead. I tried adding 'administer users' to the access arguments array, but that resulted in array errors.

Here is the code, which updates the content_profile_user() function, the 'categories' op:

    case 'categories':
      foreach (content_profile_get_types() as $type) {
        if (content_profile_get_settings($type->type, 'edit_link_sub')) {
          $data[] = array(
            'name' => $type->type,
            'title' => $type->name,
            'weight' => content_profile_get_settings($type->type, 'weight'),
            'access callback' => 'user_access',
            'access arguments' => array('edit own '. $type->type .' content'),
          );
        }
      }
      return $data;
      break;

I'll try to get this into a real patch or diff format, but I wanted to go ahead and try to get some more eyes on this, to see

yep, but you still emulate node_access.

Another possible way to fix this and possible other issues would be NOT using hook_user(). I gave this a quick try - basically it works but unfortunately the tabs don't appear right. You have to manually enter the URL or visit a category provided by the profile module, then they appear!? I don't know why drupal treats my tabs different than the tabs created by user_menu(), but it does.

The advantage of this approach would be also that we could easily do tabs on the user profile view like bio does in 5.x.

Anyway here is the quick patch I did, at least it contains a proper access callback we can reuse.

I'll see if I can figure out how to apply the patch (I'm new at patching, but I'm determined to get involved), and test out your approach_b.

re. #5, could you point out how I'm still emulating node_access? point out specific lines maybe?

I am unsure of the importance of node_access versus user_access. By having a user permission check, making sure the user is allowed to edit the specified content type, seems to take care of the bulk of the issue. ('access arguments' of the code I posted in #5.) I haven't looked into the actual loading of the node, but it seems like that would already be handled by the node loading process. Or is this the very point that you're hitting?

Is the importance or logic like this?: "If we're loading a node into the user's profile, we need to make sure the user has permission to edit THIS particular node. (But it's also helpful to check to see if the user is allowed to edit this particular content type, but that is a more general check.)"

I tried your patch, and I see the logic in it, but it behaves funny for me. It's doing for me what you described: you have to manually enter the url of the pages you want to edit, then the subtabs show up, and the main edit tab disappears.

yep, it's odd. I tried to make the tabs work below user/% - but the same behaviour occured. I did some testing and noticed that it works once we use a direct call to user_access.. -> see http://drupal.org/node/335769

Do you think it would be better to go with the hook_user method that was already used, or to wait until this core bug is fixed? Or can we even flesh it out with the core bug happening, and pass arguments to user_access? Hmmm... that sounds like a possibility.

Glad you posted that bug. I got just a little further. If I update the access callback lines to use user_access,

      'access callback' => 'user_access',
      'access arguments' => array('edit own '. $type .' content'),

it works better. When you go to the edit tab, you see the appropriate subtabs. You can click on them, and edit.

There are still some of the original problems. If I have two profile types that I can edit, when I click one of the profile subtabs, then the Account subtab disappears and the Edit tab disappears. And if I only have one profile type that I can edit, when I click on my profile subtab, then the whole subtab area disappears.

Could the issue be that these are user menus? Maybe they behave differently than regular menus, because of hook_user(). I added the categories op back (like in #5) and all the tabs behave predictably. Unfortunately however, the profile pages are empty. This is probably because hook_user() is taking over the display, instead of hook_menu().

Personally I dislike the user_categories() approach as I fear troubles with it. Actually there are some issues in the queue, which I think stem from this implementation:

• http://drupal.org/node/335562
• http://drupal.org/node/331929
• http://drupal.org/node/336067
• http://drupal.org/node/333998

In a quick test the CCK add-more-button working with AHAH did work - but http://drupal.org/node/336067 let's me think I've not clicked save.. ;) Looking at CCK's content_js() I'm not surprised about that. However even it would work with CCK, there is no guarantee that it works with other modules (e.g. imagefield, ..) or better said it's likely to not work. Read my older posts http://drupal.org/node/293836 or http://more.zites.net/embed-a-node-form-with-drupal-6 for more about that.

So I think we need to find a workaround for hook_menu() issue - which looks to me to be a core bug. :(
Unfortunately we cannot rely on user_access, so we could try to not use arguments for our access callback (3, 1).

@fago about #6: when i comment out the "'tab_parent' => 'user/%/edit'," line, the tabs magically show up. I really have no ideea what tab_parent should do (even though the name suggests some ideas to me :) )

edit: sorry, i just realized that I modified "content_profile_page_access" by adding a return TRUE;.... for testing purposes. though the issue with tab_parent still remains.

I fixed some stuff in fago's patch. It seems to work now.
Please have a look.

Forgot to change some variables name.

Edit: i just noticed that when you go to user/%/profile-edit/profile_name the default "Edit" disappears. I have no clue why.

re #16 - this patch seems to work well. Almost there! Fixes the repeating field problem mentioned earlier.

Couple comments

1)
The added tabs show up on the same level as View.. e.g. View | Edit | Track | Profile. My preference would be to display them as subtabs under the Edit tab. I was able to accomplish this by changing the $items path to this:
$items['user/%/edit/' . $type]

What are your thoughts? Do they make more sense as subtabs under Edit?

2)
The disappearing edit tab. This one is stickier. I have tried a lot of different things, but nothing I've tried makes it stick around. I have an idea where the issue is, but I'm not sure. I think it's really with the user module and how it builds its menus. There is a

user_category_load()

function that is called by some menu definitions

$items['user/%user_category/edit']
... snip ...
$items['user/%user_category/edit/account']

... all defined in user.module.

(I learned today that %whatever in the $items array causes the function whatever_load() to be called.)

If I'm on the wrong track with this, hopefully this will inspire someone onto the right track. :-)

I am wondering if it's possible that some use of hook_menu_alter() would enable us to fix the disappearing edit tab issue.

re #17
1) I think that subtabs option is the correct one too. And it seems that fago thinks this too - he made the original patch :)
But there is a problem: in my patch you can see that the path is $items['user/%/profile-edit/' . $type]. If you change the path into 'user/%/edit/' . $type then the tab doesn't show up.

2) i'll look into user_category_load, maybe we can get this fixed soon.

Edit: found it. I'll attach a patch soon.

I've attached another version of fago's patch. I think he mistakenly deleted the wrong "case 'categories'" statement in hook_user. That was the reason that user_category_load was failing.
@nadavoid thanks for showing the right direction.
This patch solves both issues at #17

The b_3 patch doesn't work for me.
I get the same with content_profile.module patched and without patch.

@azuledu have you cleared the cache ? If that doesn't work maybe the patch didn't apply correctly? - because for me it works.

Edit: i forgot to mention: the tab is located under the EDIT tab. So You will see it appearing only when you go to the node's edit TAB. That is not a bug it is how it is meant to behave.

There is a problem with the b_3 patch. Leaving the categories case in there ends up causing problems. When I cleared cache as user 1, all submenus would show up for everyone, regardless of role. When I cleared cache as a less privileged user, the links would appear properly.

Following my suggestion of #5 helps the access issue, but the problem is that the user system is taking over the rendering of the form, and not letting the regular menu system do it.

I think we have to choose between whether to 1) use the user system, or 2) use the menu + node system, as in content_profile_approach_b.patch.

1) Using the user system (hook_user) we run into problems including the profile node, especially the node edit/update/add forms.

2) Using the menu + node system seems to fix the node form issues. This seems to be the better route, if we have to choose. The big problem at this point is the disappearing edit menu. It must have something to do with the user pages.

I am attaching a very simple "menudev" module I wrote that isolates the problem. You can add subtabs to the node pages, and they work as expected. But when you go to the subtabs of your user page, the Edit tab and the Account subtab disappear.

I'm wondering if I should post this somewhere else, but I'm not sure if a Forum, a bug report, or a group would be the appropriate place. Thoughts?

@nadavoid thanks for testing.
You are right. Same thing happens here with the cache clearing issue. I'll look into it soon. Very weird though.

Edit: i tested your module. The reason for those subtabs not appearing is that you forgot to implement a hook_user in your module. It is a little bit tricky so let me explain in more detail. In user.module in the user_category_load function you can see these specific 4 lines of code:

if (!isset($user_categories)) {
  $empty_account = new stdClass();
  $user_categories = _user_categories($empty_account);
}

If you take a look at the function _user_categories you will see a line like this

$data = module_invoke($module, 'user', 'categories', NULL, $account, '')

So that tells you that you must implement the hook_user function like this in your module:

/**
 * Implementation of hook_user().
 */
function menudev_user($op, &$edit, &$account, $category = NULL) {
  if($op == 'categories') {
    $data = array();
    $data[] = array(
      'name' => 'fred',
      'title' => 'Fred',
      'weight' => -10,
    );
    $data[] = array(
      'name' => 'ginger',
      'title' => 'Ginger',
      'weight' => 0,
    );
    return $data;
  }
}

and subtabs should work oki after this.

The cache clearing issue at #23 still remains though...

Edit: I uploaded an archive with cp with all the latest patches from issue queue. Please try to test it to see if it works better.

I'm using content_profile_b but it still doesn't work for me.

I've tried in a clean installation.

If it works for you in a clean installation I can list the steps I did.

ah thanks a lot andreiashu for pointing out the problems with my patch and thanks to others for testing...
With the $type issue fixed the tab appears correctly - but only as long as you don't click another category... So now I see a light at the end of this issue.. ;)

I think we can do it this way:
* register our tab as category, so user_menu generates the tab
* alter the menu item so our own access and page callbacks are used.

-> As there is now an valid category %user_category, we can use it too and our tabs should appear also when another category like 'account' is active.
-> Furthermore we need to fix the form to stay at the edit form after editing and probably hide the preview button by default. (Should we create an option for that or just do it?)
-> Then I think we should make a top-level tab by option. -> Best convert the current checkbox to radios ('edit_top', 'edit_sub', 'none') and generate appropriate menu items.

About the "we need to fix the form to stay at the edit form after editing" maybe you can take a look at the patch I submitted at #335365: don't redirect back to the user profile view after editing

Hi!

I did upgrade from drupal 5 to drupal and now I am trying to use content_profile for my node profile.

I used my own menu, with links to edit account and edit profile.
With Node profile I could use mysite/user/$user->uid/edit-profile in Drupal 5, but now, with content profile it doesn't works.

I found that the access to edit profile is e.g.
http://www.somvprahe.sk/node/5898/edit?destination=user%2F19
But I would ask you, if there is an option how to do some 'nice' url which can be used in menu
my cck type used for content profile names 'uprofile' so it would be possible to do profile edit url like this:
www.example.com/edit-profile/uprofile/userid? (www.example.com/edit-profile/cckTypeName/UserID)

Thanks for the answer
Igorik
http://www.somvprahe.sk

Hi

Sorry for the last post, it was a mistake, I wanted to add as a separate feature request not here.
I returned last settings for this bug.

Igorik

Oki there are more issues here...

1. This I feel it is the most important, it is described at #23 by nadavoid: when you clear the cache as admin then all tabs appear even if you log in as normal user. I noticed that the access callback function 'content_profile_page_access' is not called anymore... I have no clue why... Everything gets back to normal after you clear the cache as a normal user: the 'content_profile_page_access' function gets called and all tabs that should not be visible don't appear. Maybe someone with more experience can help us here...

2. There is another bug related to permissions: you have a content type with custom fields. You don't set any permissions to it, but you check the "Use on Registration" option (under 'admin/content/node-type/type_name/profile'). On registration form the field appears (it shouldn't) and you can create a the new user, but data written in the field doesn't get saved.
I'll open a separate issue for this.

@azuledu: can you please tell me what feature doesn't work ? Please note that you have to set the proper permissions for the content types in order for them to work.

We kinda drifted apart from the original bug report so now it is harder to test exactly what stuff are not working. We must break this bug into more pieces I think...

ok I think I got it right now with the menu items approach. I've just committed it. -> Please test the next generated development snapshot and make sure to have your menu cache cleared when testing, e.g. hit submit at the admin modules page after updating the module.

The code is also already capable of doing tabs directly at user/X, so what's missing for this is just a follow up:
* implement a setting whether tabs should be at user/X or user/X/edit (radios..)
* fix the content_profile_default_path_handler() to make use of the right edit paths.

@fago, is there any way we can test the new dev right now ? Because on the module page I still get the "2008-Nov-18" dev build.

yes, check out the latest code from cvs.
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/content_pro...

@andreiashu: using your content_profile_b.zip or the "2008-Nov-18" dev build I get the same result. Under the Edit tab, a tab for each profile appears (I think that only should appear tabs for permitted profiles for this role). Pushing a tab of a permitted profile, only a save button appears (no fields). Pushing a tab of not permitted profile, a "page not found" page appears. Each role has permission to "create profile_n content" and "edit own profile content".

@fago: the cvs repository appears to be empty.

@azuledu: thanks very much for testing. Then most probably that build is broken. I'll wait for fago's build to appear in the cvs repository and then we will see what was going wrong in our build :)
@fago: as azuledu said above. I'll wait for it to appear in the repo.

I just checked it out from the repository, and it seems to work great so far. I do need to test it more thoroughly still.

I am happy. Elated. Joyful. Relieved.

You guys are fantastic.

@fago, your implementation of hook_menu_alter is just the thing I was missing.

@fago, Could you go ahead and create another dev release from the current CVS? (the most recent one I see is Nov. 17.) ... for people not yet comfortable with checking out from CVS.

For anyone who would like to checkout the module from CVS (that basically must means downloading it) ... here's the command I used, which worked great for me. It downloads to your current working directory. I picked it up from the lullabot site: http://www.lullabot.com/articles/cvs_quick_reference.

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-6--1 contributions/modules/content_profile

When browsing the web interface of CVS, you have to select the tag: DRUPAL-6--1.

OK! I'm gonna go really really test it now!

Well, finally the "6.x-1.x-dev 2008-Nov-25" version works for me too.
Thank you very much.