automattic / p2-resolved-posts Goto Github PK

Currently, the plugin only works with P2, which is intended, and will kick out of everything if P2 isn't active. We don't show any sort of notice though and this could be confusing. Let's show an admin notice when P2 isn't active but you've activated the plugin.

When a user flags a post as a given state, let's log the state they changed it to, the timestamp, who did it and then make that information visible on the post. Transparency in action.

The output should be cached and regenerated when a post is marked as resolved, etc.

It would be great if you could assign a post to a user, or claim a post for yourself.

It's hardcoded to resolved and unresolved right now.

Plugin widget aren't displayed in Widgets area.

there are some minor Javascript optimizations that can be done for readability and performance

3fe7f11 fixed a syntax error that looks to have made it in 0.3.1. The current version on .org is 0.3, which can break due to this.

A request from the forums

To make the states of P2 Resolved Posts easy to customize, we should offer helper functions. I'm thinking there should be two, one to register a new state, and one to remove a new state.

The basic model for a state looks like this:

$states[] = (object)array(
                        'slug'          => 'totally-resolved',
                        'name'          => __( 'Totally resolved', 'p2-resolved' ),
                        'link_text'     => __( 'Totally resolved', 'p2-resolve' ),
                        'next_action'   => __( 'Remove resolved flag', 'p2-resolve' ),
                    );

The 'slug' and 'name' should be required arguments, and 'link_text' and 'next_action' can be optional. If they aren't included, they'll be derived from the required arguments.

A bonus is that you'd be able to insert this state either 'before' or 'after' a given state (e.g. an additional parameter, and then you'd get the array key of the index state).

Currently, anyone whether they're logged in or not can change the state of a post. We should allow the admin to restrict to logged in users, or restrict to specific users.

Do it right before release.

Because we love it.

support for !resolved, !unresolved and !reset when creating a post or making a comment which should change the state of the post

It would be nice to simplify the process of marking a post as resolved when commenting on it. Currently, I have to write a comment then mark it as resolved. Instead, I'd like to have a checkbox to mark the post as resolved that I can check as I comment on the post,

When you resolve a thread, the comments should then be closed. It would be nice if you could then "pin" a comment to the top of the thread as the resolution and/or open a new thread as a spin-off of this existing thread

With just over 1000 lines of code, it's becoming difficult to find things within the plugin and general readability is affected. I'd like to clean-up the plugin by doing the following:

• Refactor a few functions that are either very long, repetitive or duplicate code from other function(s).
• Move the widgets to an external file
• Move css to an external file
• Re-order functions for a more logical flow

Plugin does not save. Or am I doing something wrong?
http://www.youtube.com/watch?v=r0VZroDjruU&feature=youtu.be

It would be nice to simplify the process of marking a post as unresolved when creating it. Currently, I have to write the post and then mark it as unresolved. Instead, I'd like to have a checkbox to mark the post as unresolved that I can check as I create the post,

It would be nice if you could register arbitrary states, and have those states reflexed in various parts of the user experience.

We use the To-do flags a log in make.wordpress.org/polyglots/.
It would be wonderful if the "to-do" status was also directly visible in the backend post list. Perhaps as an optional column, or as a CSS class that could be used to change the color of a border, etc.

It would be lovely to package screenshots of the plugin in the wild.

• The plugin needs to load_plugin_textdomain( 'p2-resolve', false, dirname( plugin_basename( FILE ) ) ); on init
• A p2-resolve.pot file needs to be generated to a directory ('langs' or 'languages'), so that translators can localize