subuser access

I've been implementing the subusers module to allow delegation of user creation and editing for non-admin users. 

That works ok, but I had to do a couple of things:

I've got organizations that have staff members, and a general manager who should be able to add/edit those users.

Modules that we're using to enable the org->member relationship.

CCK - defines the content types for org and contact

Content profile - associates the contact cck type with users. Had to be patched with this: http://drupal.org/node/425144#comment-3410500 to add a permission to allow content profiles to be administered by roles other than admin.

subuser - allow users to create users under their account, and edit/delete them.

Subuser required two patches to work with content profile. They're both found on this issue: http://drupal.org/node/571660#comment-3984138

Permissions required to get all this working:

• content profile module::administer content profiles
• subuser::administer subusers
• subuser::create subuser

views_attach - used to put a list of content profiles on the organization node based on the 'belongs to' nodereference field on contacts.

For users who don't have the 'administer users' permission, you'd think you can visit the profile of any of their subusers, but that's not always the case. 

The core user module throws an access denied error when you try to visit the profile of a non-logged in user and you don't have administer users permissions. 

There are some cases where a non-admin user like the ones on my site might want to edit their users regardless of whether they've logged in or not.  For instance, if I type in an email address wrong, I'll want to fix that, but I won't be able to visit their user profile.  I can visit their edit screen, but not the user profile.  The subuser module overrides the user/%/edit access_callback, but not the one for the view page.  May have to adjust that in the subuser module and file a patch. 

Posted via email from dsayswhat's posterous

git setup for new drupal site.

I've been developing a drupal site, and am ready to add it to a git repository for initial deployment.

One of the things I've noticed is that some things you shouldn't version...sites/default/settings.php shouldn't be in git, also sites/default/files and backup/ aren't good to have in there.

So I did the following:

- created the repo out on github.
- cd'd to my site root.
- rashly ran 'git add .'
- ran 'git rm -r --cached sites/default/files/*', 'git rm -r --cached backup/*', and 'git rm --cached sites/default/settings.php'
- created a .gitignore file in the root of my drupal site.  It contains the following lines:

backup/*
sites/default/settings.php
sites/default/files/*

 That will ignore those directories in the future when I got to commit or update.

- ran 'git commit'
- ran 'git remote add origin git@github.com:{repo_path_here}' and 'git push origin master'

Posted via email from dsayswhat's posterous

noderelationships and nodereferrer

Noderelationships sets up the ability to do nice js-enabled usability enhancements for cck nodereference fields.

However, I had more specific constraints...I needed to customize the view that you use when selecting nodes.  Normal arguments and filters don't work when set on noderelationships-based views, provided for your use by the module.

I tried using some instructions found on drupal.org ( issue refs here ) to filter by url arguments, etc but it didn't work...however, plain 'ol ( fancy 'ol ) hook_views_pre_view worked like a charm, using $view->default_handler->override_option('filter', $filter = array( {assoc array defining a views filter} ) );

Also, I needed to filter so that previously referenced nodes wouldn't show in the view - single noderef only please.  I had to install nodereferrer...

Now, node_relationships special treatment of views prevents filters and arguments, but it allows relationships.  So you have to set a nodereferrer relationship on the view, then add a filter such that referencing nodes is empty.  But the filter doesn't take since node_relationships is doing it's fancy thing.  So I ran a views export, copied the resulting filter array, and added another filter in my hook_views_pre_view. 

I feel like I triumphed...huzzah.

Posted via email from dsayswhat's posterous

What to do when Cron gets stuck...

If you're trying to run cron via drush, and it gets stuck due to insufficient memory or something, use drush to delete the 'cron_semaphore' variable.

drush vdel cron_semaphore

Ta-daaa.

Posted via email from dsayswhat's posterous

nice menus + context

Active menu trails set by the context module aren't respected by the nice menus module. 

I found this patch: http://drupal.org/files/issues/835090-4-context_reaction_menu_trail.patch which told me the right thing to do: write a ctools plugin for context that would expose a reaction for nice menus.

However, I didn't do the right thing. It probably took me the same amount of time, but I went and found
- the theme function that nice menus uses to style its list items: {themename}_nice_menus_build
- the function in the context module that gives you the active contexts: context_active_contexts()

I get my active contexts inside the theme function, and set any menu reactions into $context_active_trail.  Later in that function, I compare them with the menu being built:

<code>
 if ($context_active_trail) {
        if(in_array($menu_item['link']['link_path'], $context_active_trail)){
          $trail[] = $menu_item['link']['mlid'];
        }
      }
</code>

The trail variable is used next to test the current menu item and set the active-trail class if it matches. 

Now Nice menus respects Context's active menu assignments.  It would be nice if I went back and figured out the process to do it the right way, where the theme isn't so tightly coupled to the context module.

Posted via email from dsayswhat's posterous