WordPress.org

Making WordPress.org

Opened 22 months ago

Closed 20 months ago

Last modified 9 months ago

#1571 closed enhancement (fixed)

Plugin Author Admin

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

Description (last modified by obenland)

  • Create a Plugin Author role.
  • Allow access to Plugins they authored or have commit access to.
  • Automatically subscribe authors to review and support feeds. See this comment.

They can change "Tested up to", Tags, and add/remove committers. It would probably make sense to keep the title and content around but not editable for context.

Attachments (1)

after-2776.png (78.0 KB) - added by obenland 21 months ago.
edit.php after [2776].

Download all attachments as: .zip

Change History (59)

#1 @dd32
22 months ago

In 2562:

Plugin Directory: Add the starts of a Plugin Committers metabox & the methods required to alter the database records.
See #1571

#2 @obenland
22 months ago

  • Description modified (diff)

#3 @Otto42
22 months ago

Automatically subscribe authors to review and support feeds.

Make sure there is an unsubscribe option as well. I don't want to receive those emails.

#4 follow-up: @Otto42
22 months ago

After more thought, I would rather not have this automatic subscription option enabled at all. Instead, we could make it opt-in still, but more prominently displayed somewhere.

My concern is with the emails being sent by WordPress.org to not be perceived as "spam" by systems like Gmail and the like. If we start sending them automatically, then that's a risk. An opt-in is better than an opt-out here.

#5 in reply to: ↑ 4 @imath
22 months ago

Replying to Otto42:

Instead, we could make it opt-in still, but more prominently displayed somewhere.

+1

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


22 months ago

#7 @obenland
22 months ago

  • Milestone changed from Plugin Directory v3 - M2 to Plugin Directory v3 - M1

#8 @Otto42
22 months ago

Okay, so, existing Role explanation:

Plugins don't have "Authors" or "Owners" in the current system.

Plugins have:

  • Committers. These are people who have commit access to the plugin's SVN tree. Committers can add new committers by w.org usernames, and remove existing committers (including, until recently, themselves, to much hilarity for all involved).
  • Contributors. These are people who are listed in the readme.txt file and who thus show up as the "Authors" of the plugin on the plugin page. This also affects their profile on profiles.wordpress.org, as in those plugins show up on their profile.
  • "Primary Author". This is a mostly unused field which is the author of the "topic" in the bbPress installation. It is the original submitter of the plugin entry, and though we retain it (and serve the information as "author" in the API), it is unused by pretty much everything. We keep it around for historical information only. It occasionally comes in handy when resolving disputes as to who "owns" a plugin, but mostly it's useless. Note that this can be changed on the plugin Admin screen by directory Administrators, but not by anybody else. We don't change it without a valid reason. Again, historical context.
  • Administrators (plugin reviewers). All reviewers have admin access to the plugin directory. They can see closed plugins, disabled plugins (hidden but which still serve updates), and the Admin screen for all plugins. They can change any data.
  • Moderators. We don't use this in the current bbPress system. Admin or nothing. This is room for expansion in the new system if needs be.

Like themes, plugin committers have no backend access. Only access to the special "Admin" button on the front end, which grants them the ability to add or remove other plugin committers. This gives them, as one would guess, commit access to that plugin's SVN directory, after the sync process which happens once an hour. Nothing more than that.

#9 @obenland
22 months ago

Let's not take over the Generate POT file and Add Domain to Gettext Calls parts. See https://wordpress.slack.com/archives/meta/p1457113478001511

#10 follow-up: @dd32
22 months ago

Just noting that providing multiple users access to editing a post, without letting them edit every other post, is currently blocked by #wp36056

#11 in reply to: ↑ 10 @obenland
22 months ago

Replying to dd32:

Just noting that providing multiple users access to editing a post, without letting them edit every other post, is currently blocked by #wp36056

Just to be as clear as possible, that only concerns Committers, not "Primary Authors" as they'll be listed as the Plugin's author, correct?

#12 @dd32
22 months ago

Just to be as clear as possible, that only concerns Committers, not "Primary Authors" as they'll be listed as the Plugin's author, correct?

Correct, but the "Primary Author" is never exposed anywhere, it's a datapoint that is ignored everywhere.

#13 @obenland
21 months ago

In 2752:

Plugin Directory: Allow plugin committers to be added and removed.

Still needs cap checks.
Uses wpList to seemlessly add/remove committers. Works similar to the
category meta box.

See #1571.

#14 @obenland
21 months ago

In 2753:

Plugin Directory: After [2752], improve error handling and docs.

See #1571.

#15 follow-up: @obenland
21 months ago

@ipstenu's thoughts on plugin admin:

  • Tested up to
  • Tags
  • Committers
  • Contributors
  • Support moderators for plugin forums

We have the first three covered already. We should discuss if contributors (see definition in 8) should be displayed in the admin as well, or if it should stay in the readme.

Support moderators for plugin forums feels like a low priority feature to me. We could think about creating a ticket for it and circle back to it after the initial launch.

#16 in reply to: ↑ 15 ; follow-up: @DrewAPicture
21 months ago

Replying to obenland:

Support moderators for plugin forums feels like a low priority feature to me. We could think about creating a ticket for it and circle back to it after the initial launch.

I'd be curious to know what the experience is like for a non-moderator plugin author. I was always under the impression that being able to sticky posts and have some measure of control over your own plugin support forum was an oft-requested feature before whatever version of that was implemented in the current repo.

@ipstenu: What do you think?

#17 @obenland
21 months ago

In 2763:

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

See #1570, #1571.

#18 @obenland
21 months ago

In 2764:

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

See #1570, #1571.

#19 in reply to: ↑ 16 @Ipstenu
21 months ago

Replying to DrewAPicture:

I'd be curious to know what the experience is like for a non-moderator plugin author. I was always under the impression that being able to sticky posts and have some measure of control over your own plugin support forum was an oft-requested feature before whatever version of that was implemented in the current repo.

Not super often. All they really wanted was sticky and mark resolved. These days maybe once a month someone wants a sticky topic closed. I think we could even do away with that if we had something that hooked into the readme or the plugin repo admin page.

'Sticky Notice' - and that would show on the top of the forums. Be a lot easier for the plugin admins to control and edit and update as needed.

#20 @obenland
21 months ago

In 2776:

Plugin Directory: Make edit.php more of a dashboard for plugin authors.

H/t mcguive7.

See #1571.

@obenland
21 months ago

edit.php after [2776].

#21 @dd32
21 months ago

In 2777:

Plugin Directory: Introduce the Plugin Committer/Review & Admin roles. Use the capabilities throughout the core flows of the admin.
This also has a few hacks to make plugin committers/authors only see plugins which they can manage, although a few core bugs remain which cause non-owner committers not to be able to edit plugins properly.

See #1571

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


21 months ago

#23 @obenland
21 months 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.

#24 @obenland
21 months ago

In 2790:

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

See #1570, #1571.

#25 @obenland
21 months ago

In 2791:

Plugin Directory: Show Plugin Committers their unpublished plugins as well.

See #1571.

#26 @obenland
21 months ago

Plugin Authors currently can't edit a plugin that is in review. In reality that only prevents them from changing tags, as committers can currently still be added/removed. Should we allow Committers to change tags while their plugin is in review, or should we prevent them from adding/removing committers?

/cc @Ipstenu @dd32

#27 @Ipstenu
21 months ago

I think it's fine as-is.

Not being able to change tags at this point will stop some of them from being really silly.

#28 @obenland
21 months ago

In 2792:

Plugin Directory: Prevent Committers from accessing certain admin pages.

This can be extended as needed.

See #1571.

#29 @obenland
21 months ago

In 2793:

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

See #1570, #1571.

#30 @obenland
21 months 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.

#31 @obenland
21 months ago

In 2829:

Plugin Directory: Don't use context outside the admin.

Since there is no title in edit.php, we need a context to let users know
plugin they're currently editing. In the toolbar that context is not available
however.

See #1571.

#32 @obenland
21 months 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.

#33 @obenland
21 months 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.

#34 @dmchale
21 months ago

+1 for a better way for plugin authors to know they NEED to subscribe to their support forums. After playing with the "WP Dev Dashboard" plugin today, I only just found out that one of my plugins had 2 support forum posts from 3 months ago. I never fathomed I would have to "opt in" to receive those notifications, as the plugin author. If it's to remain an opt-in feature that's still fine, I understand otto's concerns mentioned above - as long as it's much more prominently displayed.

#35 @Ipstenu
21 months ago

Honestly? Plugin developers don't HAVE to support their plugin. Do they don't need to monitor the forums and get alerts (which only work anyway if users post in the right places). It's a convinience for those who do, and should be more obvious, but no, this should not be the default.

Having it as opt-in when, say, you submit the plugin would suffice. It would be part of the submission process and maybe a toggle on the admin dash for later monitoring. "What plugins AM I subscribed to?"

#36 @obenland
21 months ago

In 2860:

Plugin Directory: Display the amount of unresolved support topics.

support_resolutions gets updated from the support forums side.

See #1571.

#37 @obenland
20 months ago

In 2971:

Plugin Directory: Fix typo to avoid undefined variable notice.

See #1571.

#38 @obenland
20 months ago

In 2977:

Plugin Directory: Use html() to display error message.

Actually displays username in code tags now when a new committer could not
be added.

See #1571.

#39 @obenland
20 months 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.

#40 @obenland
20 months 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.

#41 @obenland
20 months ago

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

#42 @obenland
20 months 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.

#43 @obenland
19 months ago

In 3128:

Plugin Directory: Allow plugin authors to edit their own plugin.

Gives authors access to their plugin when they don't have commit to it yet.
Happens between first submitting a plugin and it getting approved.

See #1571.

#44 @obenland
19 months ago

In 3129:

Plugin Directory: Give authors/committers a role on the site.

Disabled until capabilities have been properly reviewed.

See https://wordpress.slack.com/archives/meta/p1463104152001314
See #1571.

#45 @obenland
19 months ago

In 3131:

Plugin Directory: Let committers only see plugins they created and have commit to.

Reverts part of [3093].
See #1571.

#46 @obenland
18 months ago

In 3329:

Plugin Directory: Show Mine view to authors with one unapproved plugin.

See #1571.

#47 @obenland
18 months ago

In 3330:

Plugin Directory: Don't let plugin authors quick edit their plugins.

See #1571.

#48 @obenland
18 months ago

In 3332:

Plugin Directory: Fix a bug where plugin names in count query were escaped.

Introduced in [3329].

See #1571.

#49 @obenland
18 months ago

In 3333:

Plugin Directory: Make it clear to use usernames to add committers.

See #1571.

#50 @obenland
18 months ago

In 3350:

Plugin Directory: Show plugin's permalink in wp-admin.

Gives plugin authors a convenient way to view their plugin on the front-end.

See #1571.

#51 @obenland
18 months ago

In 3383:

Plugin Directory: First pass at a readme validator.

Adds an admin UI and the basic infrastructure to validate readme files.
Needs some more work in the parsing part.

See https://wordpress.slack.com/archives/meta/p1466062950000169.
See #1571.

#52 @ocean90
18 months ago

@obenland Tags like <code>Contributors</code> shouldn't be made available for translation:

/* translators: "Tested up to" */
sprintf( __( '%s is missing.', 'textdomain' ), '<code>Tested up to</code>' );

This ticket was mentioned in Slack in #polyglots by ocean90. View the logs.


18 months ago

#54 @obenland
18 months ago

In 3400:

Plugin Directory: Only show permalink for plugins.

See #1571.

#55 @obenland
18 months ago

In 3413:

Plugin Directory: Don't make readme tags available for i18n.

See #1571.

#56 @obenland
18 months ago

In 3414:

Plugin Directory: Don't verify referer if nothing was submitted.

See #1571.

#57 @obenland
18 months ago

In 3506:

Plugin Directory: Add a metabox to allow committers to change the primary author.

See #1571.

#58 @samuelsidler
9 months ago

  • Milestone Plugin Directory v3 - M1 deleted

Milestone Plugin Directory v3 - M1 deleted

Note: See TracTickets for help on using tickets.