<p>Here is a quick code summary of how this can be done.</p>

<pre class="lang-php prettyprint-override"><code>// GasTankElementType
public function hasStatuses()
{
    return true;
}

public function getStatuses()
{
    return array(
        'full' =&gt; Craft::t('Full Tank'),
        'half' =&gt; Craft::t('Half Full/Empty'),
        'empty' =&gt; Craft::t('Totally Empty'),
    );
}

// GasTankModel
// If this method is missing, your actual elements may display the default green status
public function getStatus()
{
    return $this-&gt;status;
}

// ElementTemplate
{% extends "_layouts/elementindex" %}

{% set statusSnippet %}
    .status.full {
        background-position: 0 0; // @green
    }
    .status.half {
        background-position: 0 -10px; // @orange
    }
    .status.empty {
        background-position: 0 -20px; // @red
    }
{% endset %}

{% includeCss(statusSnippet) %}
</code></pre>

<p>This example is very brief and may lack context for people that don't have a good grasp on how this all works but I know you've been digging into this for a while and I just wanted to throw something together that you can <strong>adapt</strong> and <strong>optimize</strong>. At the very least, it should provide an example of all the moving parts that are required and serve as reference if you need to ask a more specific question.</p>

<p>I do want to note that we're riding on top of entry specific behavior here as far as the templates classes are concerned but everything else is standardized elemental stuff so, I don't see things completely breaking any time soon.</p>

<p>Good Luck!</p>

<p><a href="http://twitter.com/selvinortiz" rel="nofollow">@selvinortiz</a></p>

CC BY-SA 3.0
2014-07-14T08:07:20.200Z
Adding getStatus() to the model was the trick, don't know how I missed that examining the UserModel but thankfully you answered this question!
Jason McCallister
CC BY-SA 3.0
2014-07-14T07:45:25.133Z
2014-10-25T09:31:11.877Z
2014-10-25T09:31:11.877Z
Selvin Ortiz
<p>I looked into this a little bit... It looks like the color of the circles is dependent on one of these CSS classes by default:</p>

<ul>
<li><code>.status.live</code> - Green</li>
<li><code>.status.pending</code> - Orange</li>
<li><code>.status.expired</code> - Red</li>
<li><code>.status.disabled</code> - White</li>
</ul>

<p>I'm assuming (haven't checked this) that the status gets applied to the color dot as a <strong>lowercased</strong> version of the name. So for example, if you have a status called "Awesome", you would end up with a dot with the class <code>.status.awesome</code>.*</p>

<p><em>* If I'm mistaken about how this works, anyone is welcome to correct me.</em></p>

<p>Now that you've got your <code>.status.awesome</code> classes applied to the <code>&lt;span&gt;</code> which produces the color dots, you get to make your own dot! The default versions are pulling from two sprite files... You'll be served up the version which best matches your display:</p>

<pre class="lang-none prettyprint-override"><code>/app/resources/images/status.png
/app/resources/images/status_2x.png
</code></pre>

<p>Since you're not going to be changing anything in the <code>app</code> folder, you'll need to make your own image to represent your dot. One great bonus of this: Your dot doesn't have to be dot shaped! You could just as easily make a star, question mark icon, etc. I'd suggest making both a "regular" and "2x" versions, to stay compliant with the native Craft handling.</p>

<p>Put your new image files into your plugin's resources folder:</p>

<pre class="lang-none prettyprint-override"><code>/myplugin/resources/images/customstatus.png
/myplugin/resources/images/customstatus_2x.png
</code></pre>

<p>Then, you'd reference those in your plugin's CSS:</p>

<pre class="lang-css prettyprint-override"><code>.status.awesome {
    background: url(/myplugin/resources/images/customstatus.png);
}
</code></pre>

<p>The default <code>.status</code> class handles a lot of the generic positioning, so you shouldn't have to override much.</p>

<p>Anyway, most of this is speculative and untested... But let us know if it works out for you!</p>

CC BY-SA 3.0
2014-07-14T07:06:24.747Z
The case for the status does not get converted to lower case, so if your status is Awesome, you should be targeting `.status.Awesome`. Additionally, you should not have to reference any custom image, you can simply use the CP sprite and adjust the positioning `background-position: 0 0;`,  `background-position: 0 -10px;`, etc.
Selvin Ortiz
CC BY-SA 3.0
2014-07-12T03:18:15.660Z
2014-07-14T04:06:18.930Z
2014-07-14T04:06:18.930Z
Lindsey D
<p>I made a lot of progress on my custom element type from this post and with the help of @selvinortiz:</p>

<p><a href="https://craftcms.stackexchange.com/questions/887/best-way-to-implement-my-own-statuses-on-my-custom-element-type">Best way to implement my own statuses on my custom element type?</a></p>

<p>I know have custom statuses that look like this:</p>

<p><img src="https://i.sstatic.net/pwpfN.png" alt="custom statuses"></p>

<p>However, there are a few things I'm stuck on:</p>

<ol>
<li><p>How do you assign colors to the statuses? I could target them with CSS but I feel there may be a way with Craft itself.</p></li>
<li><p>When listing entries in my templates, the default status is "green" for enabled. So how do I correlate my custom statuses with the enabled/disabled featured thats all ready in place?</p></li>
</ol>

<p><img src="https://i.sstatic.net/rnMpm.png" alt="enabled element types"></p>

<p>I feel like Craft is the perfect tool for developing a workflow style plugin but I am having a few issues with statuses specifically. Does anyone have personal experience with creating a workflow, using native functionality, with Craft?</p>

CC BY-SA 3.0
2014-07-10T17:21:35.253Z
I explored the BaseElementType a little more and found getElementQueryStatusCondition(). Which the doc blocks state "Returns the element query condition for a custom status criteria". I'm looking into the core element types that come with Craft looking for this usage.
Jason McCallister
CC BY-SA 3.0
2014-07-10T18:51:56.177Z
getElementQueryStatusCondition worked for me and I now have a list of statuses. However, I still feel as if the "green" circle for statuses only really applies to the enabled/disabled but does not allow for the functionality of a workflow with custom statuses.
Jason McCallister
<plugin-development><elementtype>
How to integrate custom statuses in a workflow style custom element type?
# How to integrate custom statuses in a workflow style custom element type?

(Asked by: username_0 on 2014-07-10)

I made a lot of progress on my custom element type from this post and with the help of @selvinortiz:

[Best way to implement my own statuses on my custom element type?](https://craftcms.stackexchange.com/questions/887/best-way-to-implement-my-own-statuses-on-my-custom-element-type)

I know have custom statuses that look like this:

![custom statuses](https://i.sstatic.net/pwpfN.png)

However, there are a few things I'm stuck on:

1. How do you assign colors to the statuses? I could target them with CSS but I feel there may be a way with Craft itself.
2. When listing entries in my templates, the default status is "green" for enabled. So how do I correlate my custom statuses with the enabled/disabled featured thats all ready in place?

![enabled element types](https://i.sstatic.net/rnMpm.png)

I feel like Craft is the perfect tool for developing a workflow style plugin but I am having a few issues with statuses specifically. Does anyone have personal experience with creating a workflow, using native functionality, with Craft?

**Tags:** plugin-development, elementtype
> **Comments:**
> **username_0**: I explored the BaseElementType a little more and found getElementQueryStatusCondition(). Which the doc blocks state "Returns the element query condition for a custom status criteria". I'm looking into the core element types that come with Craft looking for this usage.  
> **username_0**: getElementQueryStatusCondition worked for me and I now have a list of statuses. However, I still feel as if the "green" circle for statuses only really applies to the enabled/disabled but does not allow for the functionality of a workflow with custom statuses.  

---

## 2 answers

### Answer by username_1 on 2014-07-14. Score: 3 | Accepted answer

Here is a quick code summary of how this can be done.
// GasTankElementType
public function hasStatuses()
{
    return true;
}

public function getStatuses()
{
    return array(
        'full' => Craft::t('Full Tank'),
        'half' => Craft::t('Half Full/Empty'),
        'empty' => Craft::t('Totally Empty'),
    );
}

// GasTankModel
// If this method is missing, your actual elements may display the default green status
public function getStatus()
{
    return $this->status;
}

// ElementTemplate
{% extends "_layouts/elementindex" %}

{% set statusSnippet %}
    .status.full {
        background-position: 0 0; // @green
    }
    .status.half {
        background-position: 0 -10px; // @orange
    }
    .status.empty {
        background-position: 0 -20px; // @red
    }
{% endset %}

{% includeCss(statusSnippet) %}

This example is very brief and may lack context for people that don't have a good grasp on how this all works but I know you've been digging into this for a while and I just wanted to throw something together that you can adapt and optimize. At the very least, it should provide an example of all the moving parts that are required and serve as reference if you need to ask a more specific question.
I do want to note that we're riding on top of entry specific behavior here as far as the templates classes are concerned but everything else is standardized elemental stuff so, I don't see things completely breaking any time soon.
Good Luck!
@selvinortiz

> **Comments:**
> **username_0**: Adding getStatus() to the model was the trick, don't know how I missed that examining the UserModel but thankfully you answered this question!  

---

### Answer by username_2 on 2014-07-12. Score: 4

I looked into this a little bit... It looks like the color of the circles is dependent on one of these CSS classes by default:

.status.live - Green
.status.pending - Orange
.status.expired - Red
.status.disabled - White

I'm assuming (haven't checked this) that the status gets applied to the color dot as a lowercased version of the name. So for example, if you have a status called "Awesome", you would end up with a dot with the class .status.awesome.*
* If I'm mistaken about how this works, anyone is welcome to correct me.
Now that you've got your .status.awesome classes applied to the  which produces the color dots, you get to make your own dot! The default versions are pulling from two sprite files... You'll be served up the version which best matches your display:
/app/resources/images/status.png
/app/resources/images/status_2x.png

Since you're not going to be changing anything in the app folder, you'll need to make your own image to represent your dot. One great bonus of this: Your dot doesn't have to be dot shaped! You could just as easily make a star, question mark icon, etc. I'd suggest making both a "regular" and "2x" versions, to stay compliant with the native Craft handling.
Put your new image files into your plugin's resources folder:
/myplugin/resources/images/customstatus.png
/myplugin/resources/images/customstatus_2x.png

Then, you'd reference those in your plugin's CSS:
.status.awesome {
    background: url(/myplugin/resources/images/customstatus.png);
}

The default .status class handles a lot of the generic positioning, so you shouldn't have to override much.
Anyway, most of this is speculative and untested... But let us know if it works out for you!

> **Comments:**
> **username_1**: The case for the status does not get converted to lower case, so if your status is Awesome, you should be targeting `.status.Awesome`. Additionally, you should not have to reference any custom image, you can simply use the CP sprite and adjust the positioning `background-position: 0 0;`,  `background-position: 0 -10px;`, etc.  

---

