Making WordPress.org

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#1570 closed enhancement (fixed)

Reviewer Admin

Reported by: obenland's profile obenland Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

Enhancements to the standard WordPress plugin to enable plugin reviews.

  • Create two Reviewer roles: Plugin Reviewer, Plugin Admin.
  • Meta boxes with SVN/Trac Links.
  • Internal notes, only viewable to Plugin Admins.

Plugin reviewers can only suggest to accept a plugin, Plugin Admins can change status.

Attachments (2)

MA.jpg (19.9 KB) - added by obenland 8 years ago.
1570.diff (4.3 KB) - added by obenland 8 years ago.

Download all attachments as: .zip

Change History (104)

#1 @obenland
8 years ago

  • Type changed from defect to enhancement

#2 @obenland
8 years ago

Got started today on internal notes and experimented a little bit there. Should have something presentable by tomorrow.

#3 @dd32
8 years ago

In 2655:

Plugin Directory: Add several metaboxes for the Plugin Review/Admin.
This change includes switching to custom taxonomies, a custom publish metabox, a custom tags metabox, and the start of a plugin-reviewer metabox.

See #1570, #1584

#4 @obenland
8 years ago

In 2659:

Plugin Directory: Add support for internal notes.

Needs some more permission checks.

See #1570.

This ticket was mentioned in Slack in #meta by obenland. View the logs.


8 years ago

#6 @obenland
8 years ago

@ipstenu, what should a Plugin Reviewer be able to do vs. a Plugin Admin?

#7 @Ipstenu
8 years ago

Admin: Approve, Reject, Open, Close, Disable, Contact developer from 'interface' (plus everything a reviewer can do)

Reviewer: Download plugin (have link to it, whichever), leave private review for admin to act on, report plugin to admins for shenanigans.

#8 follow-up: @obenland
8 years ago

So a Reviewer would be able to edit_plugins and edit_others_plugins. An Admin could additionally publish_plugins and edit_published_plugins.

In terms of statuses, we currently have pending, rejected, published, disabled, and closed.

Does that sound sane?

Last edited 8 years ago by obenland (previous) (diff)

#9 follow-up: @Ipstenu
8 years ago

I take it edit_plugins doesn't mean they can edit published ones?

Would Reviewers be able to see internal notes? I'm trying to see envision how we'd flag a plugin as reviewed but not approved... pending-not-reviewed, pending-reviewed?

#10 in reply to: ↑ 8 @samuelsidler
8 years ago

Replying to obenland:

In terms of statuses, we currently have pending, rejected, published, disabled, and closed.

What's the difference between disabled and closed?

#11 @Ipstenu
8 years ago

  • disabled still serves updates but cannot be found in search
  • closed is fully closed.

Closed is more common. Disabled is for things like we want to push an update to secure a plugin but it's been abandoned.

https://wordpress.org/plugins/custom-content-type-manager/ should probably be disabled, for example.

#12 @obenland
8 years ago

Is hidden a better term for disabled maybe?

Last edited 8 years ago by obenland (previous) (diff)

#13 @Ipstenu
8 years ago

Yeah, probably. :)

#14 in reply to: ↑ 9 @obenland
8 years ago

Replying to Ipstenu:

I'm trying to see envision how we'd flag a plugin as reviewed but not approved... pending-not-reviewed, pending-reviewed?

We could use the built-in draft and pending stati.

#15 @obenland
8 years ago

In 2735:

Plugin Directory: Use a custom comment type for internal notes.

See #1570, #1603.

#16 @obenland
8 years ago

Used by @ipstenu when managing plugins:

  • Link to SVN repo.
  • Revision log.
  • Controlling permitted committers.
  • Primary author.

I believe all of these are already covered.

#17 @obenland
8 years ago

In 2763:

Plugin Directory: Move list table classes into their own directory.

See #1570, #1571.

#18 @obenland
8 years ago

In 2764:

Plugin Directory: After [2763], update @package docs.

See #1570, #1571.

#19 @obenland
8 years ago

It doesn’t look like edit-comment.js can be used for more than once comment box in the edit screen. So for the custom comment type for plugin author communication, I’m looking at either rewriting edit-comments or starting from scratch :/

#20 @Ipstenu
8 years ago

Bah.

Okay so comments would be useful MOST for plugin reviewers with the plugin authors, hands down. Keeping the official communique in one place wins.

If it comes down to brass tacks, we can use the P2 for reviewers to leave reviews.

  • link to plugin
  • What they see wrong

They can then flag it un-resolved and an admin/approved reviewer can swoop in and send the official notice.

It's a little back and forth, but in a perfect world would lead to more admins ;)

This ticket was mentioned in Slack in #meta by obenland. View the logs.


8 years ago

#22 @obenland
8 years ago

In 2788:

Plugin Directory: Don't let Plugin Committers and Reviewers quickedit plugins.

Only PLugin Admins and above have the necessary privileges to change the things
quickedit allows users to change.

See #1570, #1571.

#23 @obenland
8 years ago

In 2789:

Plugin Directory: Make plugin post available in global scope.

\List_Table\Committers::single_row() needs it to be available globally, so
that permission checks for removing a committer work.

See #1570.

#24 @obenland
8 years ago

In 2790:

Plugin Directory: Don't show review tools to Plugin Committers.

See #1570, #1571.

#25 @obenland
8 years ago

In 2793:

Plugin Directory: Don't link to non-existent plugin previews.

See #1570, #1571.

#26 @obenland
8 years ago

In 2798:

Plugin Directory: Handle list view links in Plugin_Posts class.

Overwrites WP_Posts_List_Table's get_views() method, taking plugins into
account that the current user might not have authored, but has commit access to.

See #1570, #1571.

#27 @obenland
8 years ago

In 2830:

Plugin Directory: Capability improvements.

  • Fill built-in roles with custom caps.
  • Let Plugin Reviewers be able to manage their own plugins like regular authors.

See #1570, #1571.

#28 @obenland
8 years ago

In 2831:

Plugin Directory: Let Reviewers see all pending plugins.

See #1570.

#29 @obenland
8 years ago

In 2834:

Plugin Directory: Don't show pending plugins in Mine view.

See #1570.

#30 @obenland
8 years ago

In 2836:

Plugin Directory: Cache commit access data to avoid multible db calls.

Reduces DB calls on edit.php from 127 to 11.

See #1570, #1571.

#31 @obenland
8 years ago

For the review workflow, see 7 and following.

  • Original author should be notified on approval/disapproval.
  • We should think about what a re-submit process could look like after a plugin was not approved

I can't think of other actions right now that need to take place during the review, what am I missing?

This ticket was mentioned in Slack in #meta by obenland. View the logs.


8 years ago

#33 @dd32
8 years ago

The review process currently is

  • Submit
  • Review
    • Reject
    • Approve
    • Work with the author to fix issues (resubmit)

The last case there is currently done by keeping the plugin in the pending state, with the author emailing updated zip files to plugins@ in response to the feedback they've received.

My first thought was multiple statuses as part of a Workflow:

  • Submitted, awaiting review
  • Reviewed, waiting for developer feedback
  • Reviewed, waiting for admin feedback (If plugin reviewers need their reviews reviewed by an admin)
  • Hold - Reviewed, not waiting for Developer feedback, admin feedback, nor rejected/approved. Basically "This is being discussed".
  • Rejected
  • Approved

Reviewed, waiting for admin feedback and Hold could be merged together to form a Second Opinion status - basically some way of saying "This has been looked at, and someone else needs to look at it".

@Ipstenu Does the above sound right to you?

Finally, If a plugin author has uploaded a ZIP originally, Ideally, plugin authors would update that ZIP which the reviewers are reviewing, so plugin owners probably need access to the plugin admin screen before approval.

#34 @Ipstenu
8 years ago

Hold and 'Reviewed waiting for more admins' can be combined, yes. That works for me :)

Finally, If a plugin author has uploaded a ZIP originally, Ideally, plugin authors would update that ZIP which the reviewers are reviewing, so plugin owners probably need access to the plugin admin screen before approval.

Have we decided then that we're going with uploading zips? I'm neither for it nor against it, but yes, if they're going to be re-uploading, we'll need that.

#35 follow-up: @coffee2code
8 years ago

Is there any plan with regards to the primary existing pain point when having multiple plugin reviewers: the potential for multiple plugin reviewers to step on each other's toes by inadvertently reviewing the same plugin at the same time?

A solution might suggest needing:

  • Another post status ("under-review")
  • A simple means for a reviewer to claim a plugin (action link in post table and/or button on edit page) and to unclaim the plugin (should they decide not to proceed with review).
  • To store reviewer as post meta
  • A post column to show reviewer
  • A post table filter link to easily take a reviewer to plugins they have under-review. (Though we could limit reviewers to only claiming one at a time, in which case this view wouldn't be necessary and we could just have an admin notice above the plugin posts table saying something like You are currently reviewing <a href="">Plugin Name</a>.)
  • To separately store who approved the plugin, again as post meta. (The person may differ from reviewer and recording this may be beneficial for future auditing)
  • Possible safeguards to only permit the user who claimed a plugin for review (and admins, of course) to act as the plugin's reviewer (such as being able to mark a plugin as some form of reviewed).
  • Possible ability to assign a plugin to another reviewer/admin for review.

In such a setup, reviewers should only proceed with reviews of plugins that they've successfully claimed.

#36 in reply to: ↑ 35 ; follow-up: @obenland
8 years ago

Replying to coffee2code:

Is there any plan with regards to the primary existing pain point when having multiple plugin reviewers: the potential for multiple plugin reviewers to step on each other's toes by inadvertently reviewing the same plugin at the same time?

We'll be using the built-in post lock. That and a status signaling that that plugin has been reviewed.

#37 in reply to: ↑ 36 ; follow-up: @DrewAPicture
8 years ago

Replying to obenland:

Replying to coffee2code:

Is there any plan with regards to the primary existing pain point when having multiple plugin reviewers: the potential for multiple plugin reviewers to step on each other's toes by inadvertently reviewing the same plugin at the same time?

We'll be using the built-in post lock. That and a status signaling that that plugin has been reviewed.

@coffee2code can correct me if I'm wrong, but I get the impression he's alluding to the fact that a plugin review might not be finished in a single session (a la post locking), thus needing a way to mark it as "In Progress by X reviewer".

#38 in reply to: ↑ 37 @coffee2code
8 years ago

Replying to DrewAPicture:

@coffee2code can correct me if I'm wrong, but I get the impression he's alluding to the fact that a plugin review might not be finished in a single session (a la post locking), thus needing a way to mark it as "In Progress by X reviewer".

Yep, what @DrewAPicture said is what I was thinking.

Unlike when actively editing a post (for which a post lock is appropriate), a plugin review happens outside of wp-admin. Once a reviewer has obtained the code (whether it was uploaded or available via a link) they only really need to return to the post to progress the status to the next state. In the meantime, the review is being performed elsewhere and may not occur in a single session.

As well, a reviewer may wish to preemptively claim a few plugins without actually sitting down to do the review(s) right that second. Or their machine or browser may crash. Or they're about to board a flight and would like to review a handful of plugins without having an internet connection. Or we may want to eventually allow assigning reviewers (such as cases requiring deeper security review or to deal with particularly complex code). All of which are not well handled (if at all) by post locking.

#39 @Ipstenu
8 years ago

So you want an assignment dropdown?

#40 follow-up: @obenland
8 years ago

How about they just write a internal note?

#41 in reply to: ↑ 40 @coffee2code
8 years ago

Replying to Ipstenu:

So you want an assignment dropdown?

For the reviewer assignment feature part of it, sure (though I wasn't concerned at this stage about a specific implementation).

My main belief is that we should have a way of explicitly having a reviewer be able to say "I will review this plugin" and make that clear to other reviewers.

That could certainly be done with a dropdown when editing the post (and on quick/bulk edit) whereby reviewers could assign it to themselves. (...which then populates a post meta field which is then used as the data source for a post column that clearly shows the assigned reviewer.)

#42 @coffee2code
8 years ago

Replying to obenland:

How about they just write a internal note?

It's not apparent at a glance what plugins are currently being reviewed.
You'd have to visit the edit page for any/all plugin(s) in the queue depending on what you wanted to do or know. If I wanted to review a plugin, I wouldn't relish going down the list and loading each post one by one until I found a plugin that doesn't have a reviewer. (Even if you can tell if a post has internal notes or not, you can't infer a reviewer has claimed it without reading the internal notes of a plugin. And you'd have to read them all, as someone could claim it but after a number of other notes decide not to proceed with the review.)

It's not easy to determine which plugins are specifically assigned to me (or anyone else).
Maybe I've forgotten which one(s) I said I'd review. Or I got sick and asked someone else to take on my reviews. Or a reviewer quit or got kicked off the review team and now their claimed plugins need to be unclaimed/reassigned.

It's not easy to programmatically determine the reviewer for a plugin.
Thus you can't really do any filtering (e.g. list only the plugins I'm reviewing, list only plugins needing a reviewer, list all plugins reviewed by UserX and approved (perhaps they all warrant a re-review), etc) or stats (percentage of plugin queue currently under review; number of reviews Ipstenu has performed last month) or analysis.

#43 @Ipstenu
8 years ago

Having an assignment drop down would fulfill that. If something is assigned to a person, much like themes, it's THEIR responsibility. The only time it might get chancy is if something is assigned (like Pippin assigns a review to Aaron) and we forget to tell the assignee.

Email: Plugin review x has been assigned to you by Bob.

A custom meta value could do it? Maybe... They're not very sortable as I've learned recently.

#44 @obenland
8 years ago

In 2926:

Plugin Directory: Display custom post stati in list table.

See #1570.

#45 @obenland
8 years ago

In 2927:

Plugin Directory: Make sure pagination in plugin list works.

See #1570.

#46 @obenland
8 years ago

In 2929:

Plugin Directory: Allow committer mangament only for active plugins.

Plugins that are not yet live or are deprecated/hidden, should not have
committers added to them.

See #1570.

#47 @obenland
8 years ago

In 2930:

Plugin Directory: Initial setup for post status transitions.

Provides a place to handle post status transitions for plugins.

See #1570.

#48 follow-up: @obenland
8 years ago

@dd32: Should we make Tools\SVN closer to Automattic_SVN? What were your plans for it going forward?

@Ipstenu: Are there any actions we need to execute when post statuses change? I added some for when a plugin gets published/rejected. Is there anything we need to do when one gets hidden, closed etc.

#49 @Ipstenu
8 years ago

I almost said "Gee wouldn't it be nice if it automatically posted in the P2 and emailed..." except sometimes we close posts and then check to make sure we should have. So ... No nothing needs to be triggered unless I'm forgetting something ( @otto42 @mordauk ?)

#50 @mordauk
8 years ago

Nothing that I can think of immediately.

#51 in reply to: ↑ 48 ; follow-up: @dd32
8 years ago

Replying to obenland:

@dd32: Should we make Tools\SVN closer to Automattic_SVN? What were your plans for it going forward?

I was planning to just add wrapper methods for the core functionalities needed (as we need them), rather than the kitchen sink & abstraction that Automattic_SVN offers. I haven't seen a need for extra methods there yet - have I missed something?

#52 @obenland
8 years ago

In 2975:

Plugins Directory: Avoid a missing namespace warning.

See #1570.

#53 @obenland
8 years ago

In 2976:

Plugins Directory: Fix namespace typo after [2975].

See #1570.

#54 @obenland
8 years ago

In 2978:

Plugins Directory: Always show link to zip file if available.

Restricting it to only pending does not reflect the review flow anymore.

See #1570.

#55 @obenland
8 years ago

In 2979:

Plugins Directory: Smoothen out capability set up.

Only adds caps to built-in roles if they still exist.
Sets the default role to what plugin authors/committers will have.

See #1570, #1571.

#56 @obenland
8 years ago

In 2980:

Plugin Directory: Base post status access on user level.

Restricts plugin reviewers access to only set plugins to reviewed ('pending')
and doesn't let them publish a plugin. This will need more cap checks when
saving a plugin.

See #1570.

#57 @obenland
8 years ago

In 2981:

Plugin Directory: Attachments are not 0-based but ID-based.

Makes sure that the submitted zip file gets read and removed when publishing
a new plugin.

See #1570.

#58 @obenland
8 years ago

In 2982:

Plugin Directory: Add plugin count to dashboard widget.

Not high priority, but I had time on a flight and thought it would be neat.

See #1570.

#59 @obenland
8 years ago

In 2983:

Plugin Directory: Add meta data on plugin submission.

Adds readme meta data to the plugin post after uploading a new plugin.

See #1570, #1571.

#60 in reply to: ↑ 51 ; follow-up: @obenland
8 years ago

Replying to dd32:

I was planning to just add wrapper methods for the core functionalities needed (as we need them), rather than the kitchen sink & abstraction that Automattic_SVN offers. I haven't seen a need for extra methods there yet - have I missed something?

Makes sense. We'll need a way to create a new repo for uploaded plugins once they're approved.

#61 @obenland
8 years ago

In 2995:

Plugin Directory: Don't process publish transition twice.

Bails if the plugin has been published before.

See #1570.

#62 @obenland
8 years ago

In 2996:

Plugin Directory: Make sure post_status changes are kosher.

Adds a cap check to make sure everyone can only set plugins to the status they
are supposed to:

  • Plugin Admins: Any post status.
  • Plugin Reviewers: Draft and Pending.
  • Everyone else: No changes allowed.

See #1570.

#63 in reply to: ↑ 60 @dd32
8 years ago

Replying to obenland:

Replying to dd32:

I was planning to just add wrapper methods for the core functionalities needed (as we need them), rather than the kitchen sink & abstraction that Automattic_SVN offers. I haven't seen a need for extra methods there yet - have I missed something?

Makes sense. We'll need a way to create a new repo for uploaded plugins once they're approved.

Yep, SVN::mkdir( $remote_paths ) and SVN::import( $url, $local_path ) will be needed then.

Will need to check how mkdir deals with making */{trunk,tags,branches} and if it can be done in a single remote operation.
We could also get away with using just an import command for /plugin-name/ which includes trunk, branches, tags in the structure already.

#64 follow-up: @obenland
8 years ago

In 3026:

Plugin Directory: Import plugin files to SVN upon approval.

We need to create an SVN repo anyway, adding the approved files also gives us
a nice baseline to compare commits to. And it saves plugin authors one more
step in the process of initially publishing the plugin.

See #1570.

#65 in reply to: ↑ 64 @Ipstenu
8 years ago

The ONLY catch with this is some people do not want plugins to be active right away. They want to be approved and have the code ready and waiting until they make some public declaration on their websites. Remember we get companies who need to time releases :)

The default should still be 'not active' and need some sanity check from the users, since we're changing a decade of expectation, basically!

#66 @obenland
8 years ago

If the trunk readme has a stable tag defined that is other than trunk, does it still fall back to trunk?

It also occurred to me that when a plugin is approved in the directory, it shouldn't show up in the directory until there is a "tagged" version.

#67 follow-up: @obenland
8 years ago

In 3027:

Plugin Directory: Remove mac resources fork files after unzipping.

See #1570.

#68 @Ipstenu
8 years ago

If the trunk readme has a stable tag defined that is other than trunk, does it still fall back to trunk?

I believe it does - @otto42 would know for sure.

#69 @Otto42
8 years ago

If the Stable Tag line is missing entirely, then "trunk" is assumed.

If Stable Tag is set to trunk, then trunk it is.

If Stable Tag is set to XYZ, and /tags/XYZ exists, then that is used.

If Stable Tag is set to ABC, and /tags/ABC does not exist, then "trunk" is assumed.

#70 @Otto42
8 years ago

Note: If the Stable Tag line exists, but it is left blank, then it tries to use the root directory of the plugin. This is a bug, which does not come up a lot. It should use trunk in such a case.

Version 0, edited 8 years ago by Otto42 (next)

#71 follow-up: @Otto42
8 years ago

it shouldn't show up in the directory until there is a "tagged" version.

Simple plugins (quite of lot of them, probably the majority) only use trunk, not tagged versions. These should work too, so possibly simply putting the plugin into /trunk alone would work for the initial commit.

#72 in reply to: ↑ 71 ; follow-up: @obenland
8 years ago

Replying to Otto42:
Thanks!

So should we refrain from importing the entire plugin to account for authors who'd like to wait with the first release?

#73 in reply to: ↑ 72 @obenland
8 years ago

Replying to obenland:

So should we refrain from importing the entire plugin to account for authors who'd like to wait with the first release?

And if the answer is Yes, how should we handle the discrepancy between a published plugin and a "truly" published plugin, one that also has a stable version in the repo.

#74 @obenland
8 years ago

In 3029:

Plugin Directory: Promote authors without a role.

Gives authors access to manage their plugin(s) if they don't have that already.

See #1570, #1571.

This ticket was mentioned in Slack in #meta by obenland. View the logs.


8 years ago

#76 in reply to: ↑ 67 ; follow-up: @dd32
8 years ago

Replying to obenland:

In 3027:

Plugin Directory: Remove mac resources fork files after unzipping.

See #1570.

@obenland You should use the -delete flag here instead of -exec rm :)

#77 in reply to: ↑ 76 ; follow-up: @obenland
8 years ago

Replying to dd32:

@obenland You should use the -delete flag here instead of -exec rm :)

Thanks for taking a look! I tried, but for some reason it doesn't actually remove it. I tried:

exec( "find {$esc_directory} -name '__MACOSX' -delete" );

Am I missing something?

#78 in reply to: ↑ 77 @dd32
8 years ago

Replying to obenland:

Replying to dd32:

@obenland You should use the -delete flag here instead of -exec rm :)

Thanks for taking a look! I tried, but for some reason it doesn't actually remove it. I tried:

exec( "find {$esc_directory} -name '__MACOSX' -delete" );

Am I missing something?

Doesn't seem like it, It looks like on linux it doesn't remove non-empty directories
This should work, but I don't think it needs changing, I'll take my recommendation back :)

exec( "find {$esc_directory} -path '*/__MACOSX*' -delete" );

You might also want to look for .DS_Store files from windows-based plugin authors.

#79 in reply to: ↑ description @mfalhi_155
8 years ago

Replying to obenland:

Enhancements to the standard WordPress plugin to enable plugin reviews.

  • Create two Reviewer roles: Plugin Reviewer, Plugin Admin.
  • Meta boxes with SVN/Trac Links.
  • Internal notes, only viewable to Plugin Admins.

Plugin reviewers can only suggest to accept a plugin, Plugin Admins can change status.

#80 @Ipstenu
8 years ago

@mfalhi_155 - What's that a question about? :)

#81 @obenland
8 years ago

In 3033:

Plugin Directory: Also remove .DS_Store files from plugin zip.

H/t dd32.
See #1570.

#82 @obenland
8 years ago

In 3034:

Plugin Directory: Allow authors to update their plugin submissions.

If the initial version of a plugin does not satisfy review requirements, plugin
authors need a way to update their plugin for further review.
This now adds subsequent zip files by the same author to existing tickets and
adjusts logic and UI in a few places to handle multiple zip files.

See #1570.

#83 @obenland
8 years ago

In 3035:

Plugin Directory: Document zip file prefix.

See #1570, [3034].

#84 @obenland
8 years ago

In 3036:

Plugin Directory: Introduce an approved post status.

Approving a plugin creates the SVN repo and commits the approved plugin files
to that repo. It also add the plugin author to the list of authorised
committers and sends out a congratulatory email.

A plugin will require an initial SVN commit by the post author to then be moved
to publish, making it visible in the directory.

See https://wordpress.slack.com/archives/meta/p1461805883000448
See #1570.

#85 @obenland
8 years ago

In 3037:

Plugin Directory: Add a display state for approved plugins.

See #1570, [3036].

#86 @obenland
8 years ago

In 3038:

Plugin Directory: Make sure approved plugins stay approved on update.

Makes sure the status dropdown is populated with the right statuses.
Otherwise an approved plugin would be published after updating the post.

See #1570, [3036].

#87 follow-up: @Ipstenu
8 years ago

FYI, Reviewer Admin is broken right now.

I can view a page, but I cannot edit anything and I have no access to leave comments etc as part of a review.

All I can do is see all posts and edit them and save changes, but I can't make any changes. :|

#88 in reply to: ↑ 87 @obenland
8 years ago

Replying to Ipstenu:

FYI, Reviewer Admin is broken right now.

Apologies, there was an error in how I added caps to existing roles. I didn't notice that because I've only been testing the custom roles directly. You should be good to go now.

@obenland
8 years ago

#89 @obenland
8 years ago

  • Resolution set to fixed
  • Status changed from new to closed


Major programming operations on the Reviewer Admin have ended. In the battle of the Reviewer Admin, the Meta team and our allies have prevailed.

This ticket was mentioned in Slack in #meta by obenland. View the logs.


8 years ago

#91 @obenland
8 years ago

In 3078:

Plugin Directory: Delete zip files on rejection.

After a plugin was rejected there is no use for its zip files anymore.

See #1570.

#92 @obenland
8 years ago

In 3079:

Plugin Directory: Properly add caps to existing user roles.

Probably not needed in the future, but for now let's make sure existing roles
can test the plugin directory as well.

See #1570.

#93 @obenland
8 years ago

In 3080:

Plugin Directory: Allow Plugin Admins to assign plugin categories.

See #1570.

#94 @dd32
8 years ago

In 3082:

Plugin Directory: Move the SVN authentication handlers into the SVN class.
This also fixes an issue where the commit message was being prefixed with a = due to invalid arguement creation.

See [3026]
See #1570

#95 follow-up: @obenland
8 years ago

In 3093:

Plugin Directory: Allow Committers and Reviewers to edit_others_posts.

WordPress seems to require users to have that capability globally for a post
type, in order to make changes to others posts, even if it's only certain
others posts.

This switches to using plugin_review and plugin_approve capabilities to
control Reviewers and Committers access to certain plugins. It also improves
the logic for displaying links to the various post status views in the plugins
list table.

See #1570.

#96 in reply to: ↑ 95 @dd32
8 years ago

Replying to obenland:

In 3093:

Plugin Directory: Allow Committers and Reviewers to edit_others_posts.

WordPress seems to require users to have that capability globally for a post
type, in order to make changes to others posts, even if it's only certain
others posts.

This switches to using plugin_review and plugin_approve capabilities to
control Reviewers and Committers access to certain plugins. It also improves
the logic for displaying links to the various post status views in the plugins
list table.

See #1570.

This works, but causes unexpected extra privileges that committers shouldn't have. There's a core ticket that needs fixing to fix the issue you were probably seeing.

This ticket was mentioned in Slack in #meta by obenland. View the logs.


8 years ago

#98 @obenland
8 years ago

In 3157:

Plugin Directory: Add a way to bulk reject plugins.

Probably most useful in draft or pending views.

See #1570.

@obenland
8 years ago

#99 @obenland
8 years ago

@dd32 could you let me know what you think of 1570.diff when you get a chance?

Short of a custom query, can you think of a better way to get meta values for a set of posts?

#100 @dd32
8 years ago

@obenland looks good to me, the only change I'd suggest is to move the import changes to the start where the post is created rather than always performing it. (If that's not possible, it's just another thing to change at switch over, no biggie)

#101 @obenland
8 years ago

In 3331:

Plugin Directory: Give Reviewers the ability to filter plugins by author IP.

See #1570.

#102 @samuelsidler
7 years ago

  • Milestone Plugin Directory v3 - M1 deleted

Milestone Plugin Directory v3 - M1 deleted

Note: See TracTickets for help on using tickets.