Grayside.Org's Syndication Island

Adding a Content Type to the Open Atrium Calendar Views

Grayside — Wed, 08 Sep 2010 23:04:50 +0000

People often seem to wonder how they can get their new date-specified content types to show up on the Atrium Calendar. The following Views snippet makes it happen for a content type called “example_type” in module “custom”. Note that this code is specific to the Views as they were renamed for Kit-compatibility in Open Atrium 1.0-beta8.

Step 1

Build your “example_type” content type. You can build this out however you want, but for the purpose of this post you need to add the same field_date that the Event type uses.

Step 2

/**
 * Implementation of hook_views_default_views_alter().
 */
function custom_views_default_views_alter(&$views) {
  $views['calendar_listing']->display['default']->display_options['filters']['type']['value']['example_type'] = 'example_type';
  $views['calendar_upcoming']->display['default']->display_options['filters']['type']['value']['example_type'] = 'example_type';
}

Why Not Override the View with Views UI?

Once you have overridden the core Views in Atrium, you take a potentially stressful upgrade/maintenance path and make it vaguely nightmarish. Your changes will disappear into the ether when you upgrade. Restoring your changes would require building out a site based on a backup database to grab the key pieces of your override.

By keeping these changes in code, you can much more easily determine how to fix them… assuming any changes are even necessary!

Happy calendar hooking.

Terms:

openatrium

views

calendar

Adding Items to the Open Atrium Settings Menu

Grayside — Tue, 24 Aug 2010 16:55:07 +0000

Recently I dusted off OG Vocabularies with an eye toward integration with OpenAtrium. To my mild surprise, there was really not much that needed to be done. The menu path (node/%node/og/vocab) isn’t great, but that can be tackled later.

All I wanted was to avoid another hidden tab that can only be reached by clicking on Settings > Customize Features. I wanted the group vocabularies to be accessible directly in the Settings menu.

It turns out it’s really simple. There is a hook.

/**
 * Implementation of hook_atrium_admin_links_alter().
 */
function custom_atrium_admin_links_alter(&$links, $space) {
  if ($space->type == 'og') {
    $item = menu_get_item("node/{$space->id}/og/vocab");
    if ($item && $item['access']) {
      $links['og_vocab'] = array(
        'title' => t('Manage Taxonomy'),
        'href' => $item['href'],
      );
    }
  }
}

Terms:

openatrium

interface

Kicking Off OG Privacy

Grayside — Mon, 16 Aug 2010 20:38:15 +0000

I’ve just published the Organic Groups Privacy module to Drupal.Org. It’s an API module intended to help give developers an easy and flexible way to define public access to Organic Groups posts. It exists specifically so I can convince Spaces that I really mean it when I say an arbitrary 90% of an Organic Group should be private.

It is bundled with a Feature that demonstrates how you might integrate it with an Open Atrium site, but the core of OG Privacy can be useful even without Spaces being in the mix at all.

With it, you can do such neat things as declare all Blog posts private to group members with a simple hook implementation:

/**
 * Implementation of hook_og_privacy_policy_info().
 */
function custom_og_privacy_policy_info($node) {
  $policies = array();
  $policies['private_blog_type'] = array(
    'access callback' => 'custom_private_blog_policy',
    'reason' => t('Blog posts are only viewable by group members.'),
  );
  return $policies;
}
 
/**
 * Blog type privacy policy callback.
 */
function og_privacy_blog_type_policy($node) {
  return $node->type != 'blog';
}

If you read through the API documentation, you will see that the above policy is implicitly non-exclusive meaning any old module could come along with it’s own policy to make a blog post visible.

For an example of an exclusive policy, which exercises supreme executive veto power to guarantee the privacy of, say, all the content from your Atrium Casetracker feature, it might look like this:

/**
 * Implementation of hook_og_privacy_policy_info().
 */
function custom_og_privacy_policy_info($node) {
  $policies = array();
  $policies['private_atrium_casetracker'] = array(
    'access callback' => 'custom_private_atrium_casetracker_policy',
    'reason' => t('Content types created by the casetracker feature are viewable only by group members.'),
    'exclusive' => TRUE,
  );
  return $policies;
}
 
/**
 * Atrium Case Tracker privacy policy callback.
 */
function og_privacy_atrium_casetracker_policy($node) {
  $map = features_get_component_map('node');
  if (!empty($map[$node->type])) {
    $feature = reset($map[$node->type]);
    return $feature != 'atrium_casetracker';
  }
  return TRUE;
}

By building your own selection of exportables and hook_form_alter() implementations around such policy definitions you can control public access very easily.

For a somewhat more detailed explanation of the guts of how this works, README.txt?view=markup">check out the README.

Terms:

modules

spaces

access

Spaces Integrating a CCK Field

Grayside — Mon, 26 Jul 2010 20:25:09 +0000

I wanted to make a CCK Field available only when a given feature was enabled. It turns out it’s really easy.

CCK comes with a hook_field_access() hook (see content_access()). Any implementation of this function that returns FALSE for a given field results in that field being denied to the user.

By implementing this function with a Spaces API call instead of the content_permissions module approach of a new, field-specific permission, all kinds of magic becomes possible.

Read on for demonstration code.

/**
 * Implementation of hook_field_access().
 * Allow View/Edit access to 'field_my_cck_field' only when 'feature_name' is enabled.
 */
function custom_field_access($op, $field, $account, $node = NULL) {
  // Be sure not to affect other fields.
  if ($field['field_name'] != 'field_my_cck_field') {
    return TRUE;
  }
  
  switch ($op) {
    case 'edit':
    case 'view':
      // Make access contingent on whether a given feature is enabled in the current space, such as atrium_book.
      return spaces_access_feature('view', 'feature_name');
  }
}

EDIT: Issue posted to the Spaces queue with patch to add this functionality generically for all fields.

Terms:

Integrating Some Other Feature with Spaces

Grayside — Fri, 23 Jul 2010 16:10:17 +0000

I have found more than once a situation in which I had a basic feature that could be used on any site which I would like to see integrated with Spaces (for OpenAtrium magic). It usually runs like this:

I have the FeatureServer feature.
I want it in OpenAtrium.
Here’s a new Feature that provides some Contexts and some Groups variables.
Here’s a patch that you must apply to FeatureServer to make Spaces aware of it. (And other stuff).

#4 is a pain, but I’ve recently discovered how to shrink it down a little more: hook_system_info_alter().

/**
 * Implementation of hook_system_info_alter().
 */
function my_atrium_savvy_feature_system_info_alter(&$info, $row) {
  if ($row->name == 'some_other_feature') {
    $info['spaces']['types'][] = 'og';
  }
}

This hook is called from features_get_info() in features.module. The hook allows you to changes all the info files settings of a feature. Note: Row is apparently a huge variable to dump to the screen.

Terms:

openatrium

spaces

features

Modifying Contexts the Old-Fashioned Way

Grayside — Mon, 21 Jun 2010 23:05:01 +0000

There are two ways to change contexts. The new awesomeness is to use Features or other exportable techniques to create a new version of your modified contexts, and push the old ones out of the way.

However, when I avoid hacking [atrium] core, I prefer the old way–today that’s alter hooks.

Alter hooks in Context allow you to do zany things like modifying the conditions or reactions associated with a given context. Naturally, if the original context slides out from under your original assumptions you’ll have to make some changes. In the meantime, just remember that using such powerful things as hook_context_load_alter() you can completely break a context if you are not careful.

Below are some examples of context manipulations I’ve learned through a bit of code trawling and error trials.

For the sake of (some) future compatibility I am using the Context API as of 3.0-beta4.

> EDIT: The method previously illustrated here for altering context conditions via hook_context_load_alter() was flat-out wrong, and will not work. Unless you were to use it to preload the context_ui just to go to the context ui edit page and click save. Then it would do something.

Adding a Content Type Condition

In my approach to integrating Feature Servers into OpenAtrium, I decided to pull the Project content type created by the Feature Server module into the casetracker project context. This required a new condition.

/**
 * Implementation of hook_context_default_contexts_alter().
 */
function custom_context_default_contexts_alter(&$contexts) {
  $contexts['spaces-feature-casetracker']->conditions['node']['values']['fserver_project'] = 'fserver_project';
}

Adding a Path Condition

In working out OA Book Manager, I wanted to add my new admin pages to the book context so the sidebar book navigation would stick around. Do you see where this code is broken?

/**
 * Implementation of hook_context_default_contexts_alter().
 \*/
function custom_context_default_contexts_alter(&$contexts) {
  $contexts['spaces-feature-book']->conditions['path'] = array(
    'values' => array(
      'notebook/manage/\*' => 'notebook/manage/*',
    ),
  );
}

When manipulating contexts, you need to keep a close lookout for when you are adding new array elements and when you are overriding array elements. By setting the path in this way, I am clearing out any existing path-based conditions. Instead, I should assign the new path element at a deeper part of the array.

/**
 * Implementation of hook_context_default_contexts_alter().
 \*/
function custom_context_default_contexts_alteer(&$contexts) {
  $contexts['spaces-feature-book']->conditions['path']['values']['notebook/manage/\*'] = 'notebook/manage/\*';
  } 
}

This code does not blast away existing path conditions.

Adding a Block Reaction

Recently I’ve been working on creating a dashboard RSS feed for OpenAtrium. I wanted to add a new block to the user profile page to present some links and use instructions.

/**
 * Implementation of hook_context_load_alter().
 */
function custom_context_load_alter(&$context) {
  if ($context->name == 'atrium_profile') {
    $block = array(
      'custom-some_new_block' => array(
        'module' => 'custom',
        'delta' => 'some_new_block',
        'region' => 'right',
        'weight' => 10,
      ),
    );
    $context->reactions['block']['blocks'] = array_merge($context->reactions['block']['blocks'], $block);
  }
}

This time I threw in an array_merge to avoid clobbering the existing blocks.

Terms:

drupal

context

don't-hack-core

Optional Spaces Integration for a View

Grayside — Tue, 15 Jun 2010 21:05:02 +0000

If you want to make an exported [node-based] View smoothly integrate with Spaces, you can use the following code to modify the View structure with the “Content in current space” filter. This filter does nothing if the View is not itself in a Space, otherwise it restricts all results to content in the same space. Add any conditions you want to control whether the Spaces integration is applied.

/**
 * Implementation of hook_views_default_views_alter().
 */ 
function custom_views_default_views_alter(&$views) {
  if (module_exists('spaces')) {
    $views['view_name_here']->display['default']->display_options['filters']['current'] = array(
      'operator' => 'all',
      'value' => '',
      'group' => '0',
      'exposed' => FALSE,
      'expose' => array(
        'operator' => FALSE,
        'label' => '',
      ),
      'id' => 'current',
      'table' => 'spaces',
      'field' => 'current',
      'relationship' => 'none',
    );
  }
}

If you would like to take it a step further, and create OpenAtrium features integration, insert the following:

$views['view_name_here']->display['default']->display_options['access'] = array(
  'type' => 'atrium_feature',
  'spaces_feature' => 'feature_name',
  'perm' => 'access content', // or any other permission
);

hook_views_default_views_alter() fires off before the View is cached, so be sure to clear your cache after adding this code to see the results.

This code snippet is a finding from my work on OpenAtrium-FeatureServer integration.

Terms:

drupal

views

spaces

Drush with Bash Aliases

Grayside — Thu, 10 Jun 2010 06:18:40 +0000

I’ve been looking for some decent ways of managing the use of modules hosted in random Features Servers. Particularly, how do I use Drush as seamlessly with a Features Server as it works with Drupal.Org?

It turns out that Drush has a lot of special options buried in the pm-download (dl) command, the very Drush maneuver most helpful for my goal. Naturally, these options can be included in a Bash Alias for Drush.

alias dds='drush --source=http://code.developmentseed.org/fserver dl'

This alias specifically searches DevSeed’s features server for projects. Slide it into your .bashrc file. Now a quick $> dds fserver works like a charm.

I still think project repositories like Ubuntu’s package repos (or really, Arch repositories like Core, Extra, and Aur) have a lesson for us. But that can wait on the smoothing out of functionality like –destination, which allows you to say where a project will be saved, but not with the same grace as Drupal.Org projects and the modules/contrib/ directory.

Terms:

drush

features-servers

Integrating the Features Server into OpenAtrium

Grayside — Thu, 03 Jun 2010 16:32:53 +0000

Working on integrating the Features Server feature into OpenAtrium. My intention is to set it up as another Casetracker Project type.

OpenAtrium provides a solid case tracker and documentation system, and is a natural fit for the infrastructure of a Drupal.Org-style project ecosphere. Integrating them will allow me to post Features I’ve created to a place where I might actually have a means to get feedback on my work, let alone provide support.

Project Status of OA Features Server feature

Features Project as a Casetracker Project ✓
Features Project automatically a Notebook ✓
Converting Projects View to a Site/Group feature. [in progress]
Trivial Modification of Features Server code to play nice with OpenAtrium and Atrium Casetracker .✓ [will ship with patch]

Conundrums

Features Server feature uses Context 2.0, OA uses Context 3.0
hook_views_default_views_alter() has limited to no best practices or examples I’ve been able to find, given it’s currently documented intention as a site-specific hook. Somehow I don’t think it’s role will remain in site-customization in the world of Features.

Terms:

drupal

openatrium

features-servers

cat kit | specificity

Grayside — Tue, 01 Jun 2010 06:52:43 +0000

When you read through Kit, one of the themes that keeps cropping up is the concept of specific relevance. How do you know when it is a good idea to include a given variable, permission, or other component in your Feature?

The answer boils down to this: Keep your Feature lean and mean. Include only what’s necessary for a good, mission-complete piece of functionality. The primary reason for this rule strikes me as the worthy goal of avoiding a horde of bloated, conflicting Features that will make an ill-configured wreckage of the sites that try to use them.

Behind the fold for further thoughts about what specificity means in a well-built Feature.

In thinking about it further (and the way I’ve used Features so far), I found a couple examples of why specificity is worth thinking about.

1. The Over-Configured Content Type

I created a Feature around a new content type. The Feature itself related to how that content was listed around the site (a couple of Views). I exported every variable related to how I had configured the content type, even though my Vertical Tabs settings had no specific relevance to the functionality I was seeking to isolate and export.

For an internal-use sort of Feature, I’m sure this does not matter. (Unless you are trying to define all your Vertical Tabs settings in a different Feature). For a publicly-shared feature, you have now introduced a piece of Vertical Tabs configuration which really has no bearing on the reason someone else might have been interested in your Feature.

2. It’s How I Use It

People disagree on how specialized any given modular website nugget should be. Just look at all the Drupal Modules with overly-themed defaults. Kit specificity in a Feature means the Feature includes only the aspects of theming and site integration necessary for the Feature to make sense, not that your specific use case for that Feature is realized in a shiny exported module.

For internal-use… go for it! Kit is clearly intended as a standard for the growing world of shared Features. Exportables purely for deployment facilitation need not apply. Of course, Kit-compliance from the get-go will surely help you make the unlooked for transition to a publicly published Feature much easier.

Terms:

drupal

features

kit

cat kit | summarize namespacing

Grayside — Sun, 23 May 2010 06:03:15 +0000

I decided a few notes would help me grok the Kit Specification. I post them here in case someone else finds them useful.

Shortest Summary

Project Name and Feature Name should be the same. They should have a nice, unique namespace. The human readable version doesn’t need to show the prefix. Views and other individually exported pieces should be prefixed with the not-necessarily-unique part of the Feature name.

Barely-Shorter Sumary

This summary currently covers the Features Specification 1.0-draft.

Code Namespace

Covers: Filenames, function names, directory name.
Rule: Make the namespace (prefix) unique.

> Domain names and Drupal.Org user names make good prefixes. Why? Because they are guaranteed unique by an external authority everyone in the Drupal community is bound to bump into.

Project Namespace

Covers: Project name, as defined in .info file and a Features Server feature node.
Rule: Same as the code namespace for a single-feature project.

Machine Name

Covers: Generic part of the feature name.
Rule: Should be short and descriptive.

Features will generally be called <namespace>_<machine name>.

Human Readable Name

Covers: Name of the feature, such as on the modules page. (As defined by name in .info file.)
Rule: Skip the namespace. Stick with a descriptive name.

(I interpret this to be a human-readable version of the Machine Name.)

Component Namespace

Covers: All the bits that are exportable. (Views, Content Types, Rules, etc)
Rule: Prefix with the Machine Name.

Example

Here are the namespace selections for a project enhancing the OpenAtrium Notebook.

Namespace: grayside
Project Name: grayside_oa_book_manager
Machine Name: oa_book_manager
Human Readable Name: OA Book Manager
Component Namespace:
- View: oa_book_manager_bulk_update
- Rule: oa_book_manager_new_page_message

Terms:

Feature Server: Not That Hard

Grayside — Fri, 07 May 2010 06:27:40 +0000

It turns out that running your own Feature Server isn’t that complicated. Get a Drupal site. Install the fserver feature. It’s most exotic requirements are Filefield and Context, and context is just their to facilitate easy block placement of release information.

All the feature really does is provide a fancy XML Views style plugin, a couple content types with their CCK fields to specify things like version information, and some special file-handling magic to push files and tarballs around.

It slid into this blog site very easily, and now I have a very clean way of upload and sharing Drupal code and functionality snippets. But should I leave the fserver as part of my blog? The last thing I need is to release a couple popular features into the wild and have to worry about the Update Status module pinging my words to death.

Terms:

features

features-servers

OpenAtrium Group Manager as Content Administrator

Grayside — Thu, 06 May 2010 07:38:13 +0000

In Drupal, it only takes a couple hours (or perhaps a couple days) to build the concept of a site-wide content manager into your system. It gets mighty tricky to start parceling out administrative tasks for parts of the site.

With Organic Groups (the module behind OpenAtrium’s groups), the solution to this problem has always been messy. But with the advent of Spaces and Group Administrator configuration, it seems like OA and related sites are within shouting distance of giving Group Managers the power of Content Administration.

Between my OA Change Group and OA Book Manager modules, I’ve started experimenting with how to bring that kind of capability to light.

OA Change Group adds a new subtab to admin/content/node. That works fine, for site-wide administrators. It also allowed me to punt on the whole notion of double-checking that the logged in user has the right to post content to the destination group. But it doesn’t help group managers, except to the extent that the site admins are ready and willing to take content management tickets.

OA Book Manager takes a cue from the content-management-lite Archive feature in OA, and slaps a sub-tab into the feature it’s related to. In this case, adding a “Manage” tab to the Notebook feature.

But if OA content management is going to remain a cohesive experience for site administrators and group managers alike, a few more best practices need to be worked out, and OA needs to come packaged with more of a skeletal administration system in the groups themselves so feature-builders know what to be thinking about in working together.

Terms:

drupal

openatrium

content manager

Drush and Features Servers

Grayside — Sat, 01 May 2010 07:14:15 +0000

Feature Servers have great potential to help structure the use of code sourced outside the formal ecosphere around Drupal.Org this has it’s pro’s and con’s, but I already see their usefulness in providing a little more structure to issue-queue code exchanges and organization-internal modules. So let’s bring Drush into this and boost the ease of use of that usefulness another step up.

For those who need more catching up:
Features are a special kind of Drupal module built on the features project. They allow you to easily export configuration from your site into a module usable on any site. Modules downloaded from a Features Server are the next best thing to one posted to Drupal.org. DrupalConSF has a great video.

Current State

The rise of Feature Servers, and perhaps other types of code release repositories would benefit from a little Drush magic. The little-documented option of –source is a starting place:

drush --source=http://code.developmentseed.org/fserver/ dl fserver

This code will grab the latest, most recommended release of the Feature Server code from DevSeed’s feature server.

Future Directions

I’ve started an issue in the Drush queue to talk about some kind of repository scheme to help manage the download and file placement of code from individually preferred repositories.

Terms:

Single Group Login Redirect

Grayside — Wed, 28 Apr 2010 21:39:37 +0000

Community.OA had a request for functionality that would redirect a user with a single group membership to that group’s homepage.

I packaged that functionality up as a Feature, so you can use it too. The oa_ prefix refers to the support for spaces_og/purl to generate a group URL.

Terms:

Changing Node Group Audience

Grayside — Mon, 12 Apr 2010 18:33:31 +0000

In OpenAtrium, it’s not easy to change the group affiliation of a node once it has been created. OA locks down the interface to set group audience specifically to make the interface easier to understand.

I have just posted a quick feature that demonstrates how to grant administrators the ability to shuffle nodes around between groups, it can be found in the issue queue at community.OA.

It introduces two things–a new Action that toggles the group audience of a given node, and a Views Bulk Operations View that allows you to apply that action to batches.

There is a special column in the View labeled “Member of Private Group”. This column lets the administrator know whether the current group is a private group, meaning the content is almost certainly private as well. Any quality of the group a node starts in will be lost once you move a node to a new group, and that includes whether it is private content. Remember that, and use with care!

Note: If you preface the URL of the View with a group namespace, it will limit the content to the nodes of that group.

Download feature from my Features Server here

Terms:

Simple Spaces Recipe for a Static Welcome Widget

Grayside — Sun, 07 Mar 2010 08:33:50 +0000

One of the little conundrums in OpenAtrium (and I imagine in Spaces) is building static content for the space. (Or in OpenAtrium terms, getting a nice dashboard box to stay put, yet be customizable by group.)

There are countless ways of doing this, but I opted to create a CCK Textarea field in my group content type (named field_group_welcome_message) and turn on the PHP filter.

Then I created a Box (which is what OpenAtrium uses, could just as well have been a block) using the following snippet:

$space = spaces_get_space();
$text = $space->group->field_group_welcome_message[0]['value'];
 
if ($text != NULL) {
  $format = $space->group->field_group_welcome_message[0]['format'];
  $text = check_markup($text, $format, '', TRUE);
}
else {
  $text = $space->group->og_description;
}
print $text;

The bit about $format and check_markup is only relevant if you turn on input filtering for your textarea. Can’t figure why you would not do that. UPDATE: Added a check for a null welcome message. If there is none, the group description will be inserted.

Now, whenever anyone goes to edit the group node/group settings, they are also offered the chance to play with the welcome message. You could just as well use this technique to pull out the Body of the group node, if that’s available. In OpenAtrium it’s removed, since it doesn’t fit into the dashboard concept without this kind of magic.

You could just as easily build some kind of zany view to achieve the same result, but you’d still need to do something to mark your target content uniquely. This method seems the most straightforward for the end-user.

I will update this another time with information about enabling such a block by default.

Terms:

Moving OpenAtrium Node Form Elements to the Right Column

Grayside — Sat, 06 Mar 2010 20:01:47 +0000

Previously, I discussed how you could move CCK fields into the node form sidebar by careful fieldgroup naming.

If you are of a programmer’s bent, you might instead try the more flexible programmer’s solution–preprocessor function. I dug this out of the atrium_blog feature.

This code snippet isolates a nodereference field attached to blog content and pushes it into the sidebar. This should work to move entire fieldgroups of form elements too.

/**
 * Preprocessor for theme('node_form').
 */
function atrium_blog_preprocess_node_form(&$vars) {
  if (!empty($vars['form']['field_referenced_book_page'])) {
    $vars['sidebar']['field_referenced_book_page'] = $vars['form']['field_referenced_book_page'];
    unset($vars['form']['field_referenced_book_page']);
  }
}

OpenAtrium 1.0-beta8

As of Beta 8, the above code does not seem to work. I haven’t found the ideal solution, but it’s match in Beta8 is as follows:
This is the result of Open Atrium’s move to using the Nodeformcols to facilitate sidebar wrangling.

/**
 * Preprocessor function for node form.
 * Move CCK field to the sidebar.
 */
function custom_preprocess_node_form($vars) {
  if (!empty($vars['form']['nodeformcols_region_main']['field_sidebar_reference'])) {
    $vars['form']['nodeformcols_region_right']['field_sidebar_reference'] = $vars['form']['nodeformcols_region_main']['field_sidebar_reference'];
    unset($vars['form']['nodeformcols_region_main']['field_sidebar_reference']);
  }
}

Terms:

node-form

openatrium

Atrium Casetracker: Change Which Case Statuses are "Closed"

Grayside — Mon, 08 Feb 2010 21:35:30 +0000

You might wonder how cases are considered “closed” for purposes of case filtering in the Case Tracker. It’s an attempt to be helpful on the Case Tracker’s part– hide the stuff that is no longer relevant unless the user specifically asks for it. Unfortunately, I don’t like the defaults on what it considers irrelevant.

This filtration occurs in the Atrium Casetracker feature, by filtering out cases that match a hardcoded list of statuses. By changing the hardcoded statuses, we can bring the casetracker in line with any customization you care to make to the state types. Eventually, this kind of functionality will be handled more smoothly by the Casetracker module itself, but that functionality is waiting on the next version of Casetracker. (Personally, I hope there is something like a checkbox on each status to declare it “inactive”.)

Changing Code

Visit line 335 of atrium_casetracker.module, and you will find the function atrium_casetracker_get_inactive_states(). Read down a few lines to find:
$search = array('closed', 'deferred', 'duplicate', 'postponed', 'fixed');

I want to drop “fixed” because I am not using that as a state and “deferred and “postponed” because I prefer to see delayed tasks so they don’t get forgotten. Lastly, the difference between Resolved and Closed is kind of hazy to some of my site’s users, so I changed “closed” to “archived” and need to reflect that here.

It becomes:

$search = array('archived', 'duplicate');

Terms:

drupal

casetracker

openatrium