Create a view to display a single extension. Logic by @roland-d, front-ending by @robinpoort

URL /extensions/extension-name

Extension:

• add
• edit
• change categories
• send email to owner
• delete
• publish
• unpublish
• add admin note (by admin only)
• awaiting response (awaiting response codes, by admin)
• pending (by user when new file uploaded to correct issues found)
• approve
• rejected
• update by XML
• JED checker pass
• JED checker fail
• URL pings by cron
• change owner

Reviews:

• add
• publish
• unpublish
• flagged (by admin or the reviewer checker cron)

Tickets:

• add
• change ticket category
• reply by user
• reply by admin
• close
• upload file

Users:

• ban
• change ACL rights
• mark suspicious

Reviews can be left for any distribution type (free, paid, cloud service) providing that the type in question is listed.

User Restrictions:

• User must be logged in to submit a review
• A user can only have one published review for a distribution type of an extension
• When submitting a review, a user must first select which distribution type for which their review is for.
• A review can be submitted in any language, selected from a dropdown. If the person has already chosen to show the JED in a certain language, that language will be preselected for the review.
• Users will be able to submit new reviews which will automatically replace existing reviews, if the original is older than 6 months, regardless of published state.
• They will also be able to unpublish their reviews if they wish.
• The support score / comments is only shown if the developer has stated that support is available, and if the user has selected that they have used support.
• Scores to be entered on a 5 star scale, with half stars. There should also be an option to mark as ‘Not Applicable’ to give a NULL score (exempt from score calculations)

Review Publishing:

• All reviews are unpublished by default.
• All reviews are run through the Review Detector.
• If the result is negative, the review remains unpublished.
• If the result is positive, the review will be published, subject to the Reviewer’s permissions.
• Email notifications of a new review should not be sent unless the review is published.

Display of submitted ticket:

• Subject
• Category
• Status
• Created By
• Assigned To
• Message
• Uploaded file preview (images and zips only)
• Ticket reply history with timestamps
• A quick link to the ticket listing view, filtered by this user and with no filter on the status

A form to add internal notes to the ticket - only visible on the back-end to JED team.

A form to reply to the ticket with a message. Default status of reply is Awaiting User. Other states as detailed below can be selected.

A form to link the ticket to a specific extension. If the ticket is linked to an extension, the ticket should show in the Notes section of the extension.

Ticket Status:

• New
• Awaiting User
• Awaiting JED
• Resolved
• Closed

If a ticket has been marked as Resolved, an email is sent to the submitter informing them of this. If they do not make any further replies to the ticket, or do not close it themselves, the system will then automatically close the ticket after 7 days.

Tickets can be assigned to a specific sub-team: Listing, Reviews, Leadership etc. If a ticket is assigned to a usergroup, it does not prevent Leadership replying to the ticket. Assigning a ticket does not change the state.

Closed tickets cannot be replied to or re-opened.

The category of a ticket can be changed by JED Team so that the correct usergroup can process it.

When submitting a reply to a ticket, the JED Member should select the new status of the ticket: Resolved, Awaiting JED or Awaiting User. The default status is Awaiting User. A ticket can be marked as Resolved at any point.

An email is sent to the submitter for all changes in state of their tickets.

Each day the URLs (download, documentation, support, demo, license, project) of every extension should be checked to see if they still work. If they don’t work, an email should go out to the user to get it working again. After 24 hour grace period, the listing will be unpublished (with a new email sent to the developer). After the user updates the listing (or during the regular daily check) and the URLs work again, the listing should be republished (with a new email to sent to the developer).

On top of the jed4_jed_extensions DB table

@JazParkyn can you please list the columns wanted for the list view in the backend?

====
From the JED 4 specs document:

Columns for list view table:

• Title
• Category (can be multiple!)
• Last Updated
• Date Added
• Published State (icon)
• Approved State (icon)
• Developer
• Type
• Extension Type (icon)

Filters - saved into the session:

• Category
• Published State
• Approved State
• Developer
• Download Type
• Extension Type
• Open Search field

All columns are orderable, and ordering is saved into the session. Pagination should not use AJAX.

Default ordering:
Most recent first

Plugin to be created in private repo.

To include:

• Total counters:
  • Extensions
  • Reviews
  • Reviews per Day
• Reviews Box:
  • List 5 most recent reviews
• Tickets Box:
  • Pie chart to display ticket status
  • List 5 most recent tickets
• Extensions Box:
  • List 5 most recent extensions

All boxes have a quick search field and a link to the relevant area.

• Replace $query->select('*'); with a query to select only the columns needed for the view.
• Use extensions instead of t for the select (don't forget the getSortFields)
• move default_body, default_foot, default_head into default.php

Needs further discussion and cannot be completed until new component structure has progressed further.

Users, listings and reviews from the current JED need site need to be migrated to the new JED site. Including connections between IDs.

A migration script needs to be developed when the new database structure is in place.

ucm_content data needs to be migrated to com_jed_* tables.

Related joomla/jed#28

List of all email templates and to manage them

Need to decide if the number of categories can be reduced and re-organised so that they become more useful, usable and meaningful for users.

Have a look:

July 28, 2019 - the date when this product was published ar the JED.

My idea is to replace Date Added to Updated.
It will be more correct and show the product was recently updated.

As soon as a listing is open, it must be “checked in” so another user cannot overwrite data. JED Administrators should be able to open the listings, but not save any changes unless they check in.

Toolbar links:

• Back to List View - icon
• Extension Name - static text
• View Frontend - link
• Approved State - switcher, opens in a popup
  • Dropdown: Approved, Pending, Awaiting Response (see Appendix for Awaiting Response Codes), Rejected
  • Notes - textarea
  • Save button
  • Cancel button
• Published State - switcher, opens in a popup
  • Multi-select box to include all Unpublished States (see Appendix for Unpublished Codes)
  • Notes - textarea
  • Save button
  • Cancel button
• Notes - quick link to Email / Notes tab
• Save - action button

Area above tabs:

• Extension Name*
• Developer Name - link
• JED Checker - status indicator, click to run

Info Tab:

• Category* - dropdown multi select (categories from #__categories, so we need relation table)
• Alias* - auto generated from title
• Tags - multi-select
• Community Choice - checkbox, hidden from front-end
• Extension Type - multiple checkboxes (component, module, plugin, extension specific addon)
• Requires registration to Download - checkbox
• Uses Update Servers - checkbox, mandatory for new extensions
• Uses non GPL CSS/JS - checkbox
• Uses third party libraries - checkbox
• Version Number
• Supported Joomla Versions - multi-select (Joomla 3, Joomla 4)
• PHP Compatibility - multi-select (5.6, 7.0, 7.1 etc)
• Developer* - dropdown
• Extension Attachment - link to download extension file from JED
• Parent Extension - dropdown, optional
• Project homepage Website - link
• Download - link
• Demo - link
• Documentation - link
• Support - link
• License - link, mandatory if paid extension
• Logo - image
• Images - multiple images
• Video - link to Vimeo?

Content Tab:

• Description - editor
• Button to add description in other languages

Pricing Tab:

• Download Type - dropdown (Free or Paid)
• Related Free / Paid Extension - dropdown with search, restricted to extensions by the same developer
• Download Type - dropdown (None, Free Direct Download Link, Free but Registration Required, Paid Purchase Required), used for Install From Web Component
• Download URL - link, used for Install From Web Component, only enabled if ‘None’ is not selected in previous field

Reviews Tab:

• Recalculate Score - button, runs review calculation cron for this extension on demand
• List view of all reviews, ordered by most recent first, with each showing:
  • Title (linked to Edit Review page)
  • Scores and comments for each review subject
  • Author (linked to User Detail page)
  • Date
  • Version Number
  • Weighting
  • Published State
  • Delete Button

Communication Tab:

• Form to send new email or add new note
  • Template - dropdown of template replies
  • Message - editor
  • Type - radio buttons (email or note)
  • Send Button
• History pane, shows all interactions for this extension in a list view with timestamps. To include:
  • User Actions (add, edit etc)
  • JED User Actions (email, note, publish, unpublish etc), click to expand for more detail
  • Tickets linked to this extension (link to ticket)
  • Any other changes made by a JED Team Member

Other Extensions Tab:

• List view of extensions by the same developer - columns to match Extension List view.

Columns:

• Title
• Date
• Extension
• User
• Published State
• IP Address - linked to Review Detective

Filters - saved in session:

• Title
• Extension
• User
• Published State
• IP Address
• Open search field

All columns are orderable, and ordering is saved into the session. Pagination should not use AJAX.

Default ordering:

• Most recent first

We need a proper solution for the filter form fields. A simple select won't work with so many users. So most likely an AJAX-based solution would work.

ATTENTION: If you have a question or you need to contact the JED Team about an Extension, please, contact us via the JED Ticketing System: https://extensions.joomla.org/profile/

Describe the bug
This is a Feature request not a bug!!!

• The request is to add in the submit form a text input for a URL (returning a JSON response)
• The URL (once and if the extension is approved) will be checked daily for updates and kick in any changes automatically (I mean it will request the update workflow to be respected)

WHY?

Devs like me that don't release extensions for profit have to do a lot of work on the JED UI, but with a simple JSON feed from a static/dynamic site, this could be also automated. In short, I'm asking for something that will eventually simplify many devs workflow.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

On the extension edit view we have 2 modal buttons:

• Approved State
• Published State

These buttons get different classes based on their status. This used to work on Joomla 3 but in Joomla 4, all button CSS are overruled and backgrounds are made white. The real color only shows on hover however we want to show this immediately.

Have a look at these 2 toolbar button overrides:
https://github.com/joomla/com_jed4/tree/9f355541411dc22914e063057fad0008bd3a8b97/public_html/administrator/components/com_jed/layouts/joomla/toolbar

We need to create our own CSS to show the colors on the buttons.

My first reaction to this review below was to blame the reviewer for being lazy and not reading.

But honestly, this could be an area we need to improve the JED's usability? That "J3" box is tiny and unclear.

Could we use clearer icons / labels for Joomla 3 and Joomla 4 compatibility?

• Title
• Published Status
• Score and comments for:
  • Functionality
  • Ease of Use
  • Support
  • Documentation
  • Value for Money
• ‘I Used This For’ comments
• Version Number Used
• Created By
• Language
• Review general comments
• IP Address, with link to Review Detective
• Publish state history
• Developer’s reply (if available)

A cronjob will run to process ‘Pending and Published’ extensions through the JED Checker. If the extension passes the JED Checker, it will:

• Mark the extension as ‘JED Checker Passed’ And ‘Approved’ if it has been uploaded by a Trusted Developer - this will result in the extension being published.
• Mark the extension as ‘JED Checker Passed’ if it has not been uploaded by a Trusted Developer - this will result in a JED Listing Specialist needing to perform the rest of the manual checks.

A developer will become a Trusted Developer if they have 5 extensions that have passed the JED Checker without issues on the first run, or if they have been marked as Trusted by a JED Member.

If the extension does not pass the JED Checker, the system will update the Awaiting Response Codes accordingly. An automated email should be sent to inform the developer of the detected issues. This email should be visible in the Email / Notes tab in the Extension Detail view.

The JED Checker should be run each time that a developer uploads a new zip file. If an extension has never been marked as Approved and Published, uploading a new zip file will set the status back to Pending and Published.

All changes in states should always be communicated to the extension’s owner.

The XML will be queried once a day by the JED (and when a listings edit page has been saved). It will update certain editable fields for the listing. The editable fields which can be updated via the XML are:

• Descriptions
• Project Homepage
• Download URL
• Demo URL
• Documentation URL
• Support Forum URL
• License Page on your Site
• Compatibility
• Version

The XML will only be checked and will only update the listing after the listing has been approved and published.

The updater will also need to check the fields for valid values before updating the listing information. If the values (including the descriptions) fail for some reason, the listing will not be updated. This will trigger an alert in the listing edit form that notifies the user that there is an issue with the XML file (and what the issue is).

There has to be the ability to block this feature on the listing and user levels.

JED Users fit into one of the following groups.

• JED Administrators: members of the Core JED team and have all permission rights in the system.
• JED Listing Specialists: check listings when they are submitted or reported to ensure the listings comply with the ToS. They can also check and process tickets in permitted categories.
• JED Review Specialists: check reviews when they are reported and determine if those reviews comply with the ToS. They can also check and process tickets in permitted categories.
• JED Support Specialists: check and process tickets in permitted categories.
• JED Registered End Users (logged in): can add / edit their own extensions, leave reviews, report extensions / reviews, open tickets
• JED Public End Users (not logged in)

The permissions for each area of JED are detailed throughout the specifications document.

Design the "see all reviews" for extension page

On the Downloads tab when editing an extension, the alternative download dropdowns should only show the extensions by that developer of the given type.

Provide a ‘Request Merge’ option for extension developers. Form to require a new name and description to be used the merged extension, instead of combining descriptions from the free and paid versions. Request to be reviewed and actioned by Listing Specialist or Team Management.

This needs to be defined in a lot more detail - suggest that it is discussed when the views have progressed further. The SEO team will also need to be consulted on how best to handle the URL redirections.

Feedback:

• Free / Paid / Cloud in header
• Download -> Download extension
• "XX Reviews deleted by the developer" below the Based on xxx reviews.
• Page should support paid & free version, linking directly between them
• Show "more extensions" and counter for cards at bottom

Example case to improve the script: PWT Extensions

The main change from the current system is that a free, paid and cloud service distribution types of the same extension will be submitted, managed and viewed on the same page.

Add extension view to only allow users to add one of each distribution type (free, paid, cloud service) for each extension.

#__jed_extension - contains the information shared between the distribution types
#__jed_extension_detail - contains the information about the specific distribution type

A user must select at least one distribution type, and cannot have more than one of each type.

A file upload will be required for each type selected, and will eventually be run against the JED Checker

The component should check the user’s account for any pending issues. The component should prevent submissions if:

• the user has 3 pending submissions.
• the user has a suspended account.
• the user has any unpublished listings for any reason other than UR5 (per developer request).

Submission checks:

• All tests currently present in JED
• Pass JED Checker against all files uploaded
• Match Listing Name against install name
• Reserved Words should be accepted (eg. Joomla, component, module, plugin, free, paid, etc)
• Check to see if the alias for the extension already exists

Please see the spec document for further clarification on this process - see: Front-End Submission Process

If it passes, continue.
If it doesn’t pass, display issues from checker to user.
If it doesn’t pass, the user has the option (via checkbox) to bypass the check and describe why the submission is valid. In this scenario, the submission will be placed in a manual review queue.

The possibility of auto populating some fields using data from the extension’s XML install file should be reviewed.

1. To make Joomla more interesting for companies a category especially for companies and company solutions would be important and helpful.

2. In addition to the »technical categories« such as modules, plugins, components and custom fields it is recommended to include the very powerful template overrides. There are no installers available yet, but this may come for the corresponding standard template and would be desirable.

Add at least 6 extensions into the new database for testing purposes during the development.

In a discussion I talked about quality indicators for extensions. The background wasn't so much to force developers to adopt something, but to give users an idea about the core integration and which core features the extension supports. The following information could be collected from an extension with the options "Yes", "No" and "Does not apply" and could then be displayed with badges in the listing:

• Is accessible (respects accessibility)
• Supports Smart Search
• Supports Custom Fields
• Uses Bootstrap 5
• Uses vanilla JS instead of jQuery
• Provides SCSS files for CSS
• Allows to disable extension specific JS/CSS
• Uses class-based router
• Supports Joomla Event system
• Supports Tags, versioning, category system, workflow, email templates, update system
• Uses language files and layout files
• Compatible with PHP 7.2-8.0
• Supports both MySQL & Postgresql

The order of the list does not represent a priority of the individual items.

Users have the ability to view their own tickets, add new tickets, and reply to existing tickets.

If a user is submitting a ticket in the Report Extension, New Listing Support, Current Listing Support, and Unpublished Support categories, they must be forced to select the extension.

If a user is submitting a ticket in the Report Review Category, they must be forced to select the extension and the review.

If a user is submitting a ticket in the Site Technical Category, a message should be shown to them asking if they have checked our Issue Tracker on Github for their issue. This will help to avoid duplication and save time.

A user can add a new reply to a ticket at any point throughout the tickets lifetime, except if its status is Closed. A new reply will change the tickets status and email notifications accordingly.

We will extend the Joomla core user edit view with new tabs (create a plugin for this).

Access Tab:

• Banned Status
• Toggle to display ‘Apply a Ban’ form:
  • Reason
  • Length (30 Days, 60 Days, 90 Days, Permanent, Custom End Date)
  • Start Date
  • End Date (Only editable if Other is selected in Length)
• Ban History (if available)
  • Access Options - checkboxes, selected by default:
  • Can add extensions
  • Can edit own extensions
  • Can report extensions or reviews
  • Reviews auto approved
  • Extensions auto approved
  • Update listing via XML files
• Banned review categories - multi-select dropdown
• Banned review developers - multi-select dropdown

Extensions Tab:

• List view of all extensions owned by the user

Tickets Tab:

• List view of all tickets submitted by this user, not filtered by status

Audits Tab:

A log showing all of the user’s actions
- Filters:

• Date Range
• Event
• IP Address
• Location

Let's use the Joomla core action log for that, list the last 25 events from a user in the tab, and a "more" button to the view administrator/index.php?option=com_actionlogs with active filter on the user.

Reviews to be filterable by free / paid / cloud service.

Overall score to be calculated from both all distribution types. Score also available for distribution types separately.

The listings will receive a final score that will be calculated by an algorithm and based on a number of aspects. The result is displayed to the nearest half-star on the five star scale.

This issue is to get a number to create a new branch so they can link together!
Then the code that's posted and be reviewed and hopefully made into a pull request for the main branch.

Need to setup CI from this repo to jed4.stage.extensions.joomla.org

A database file will need to be provided from jed4.stage.extensions.joomla.org so that developers will have an anonymised data set to work with.

Use the current card as base

• Align stars layout with styling zoom page
• Free/Paid (+cloud) more clear position

Create the list view for extensions in the frontend. Logic will be done by @roland-d, front-ending by @robinpoort

Content and extensions outside of com_jed needs to be imported into jed4.stage.extensions.joomla.org

Each to be reviewed as to whether or not it is still required.