As previously discussed with @be2n and @clarkepaul we will not be showing themes or recipes in the report

As a CMS user
I want to know what modules are part of my site build
So that I can understand how the feature/ functionality sets of the site are provided

Acceptance criteria

• Module is listed in plain English (for example "Translatable" instead of silverstripe/translatable)
• Module listing has a short description of the functionality
• Meets the SilverStripe commercially supported module standard
• Has unit tests (see above)
• The existing functionality in this module is converted to a "Report", rather than a standalone ModelAdmin
• The list only shows SilverStripe modules
• The module doesn't rely on filesystem commands, but uses Composer packages to gather required data as much as possible

Tasks

• Write this functionality for SilverStripe 3 (see upgrade to 4 at #42)
• Convert from a ModelAdmin into a Report
• Bring up to the SilverStripe commercially supported module standard (incl. unit tests, code style, documentation)
• Implement the Composer PHP SDK and Packagist API as required to use this functionality

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

We should add checks based on https://github.com/stnvh/silverstripe-infoboxes to check for

• newer versions of dependencies
• known security vulnerabilities

Any notification should only be displayed for administrators.

The ComposerPackageVersion DataObject is "a DataObject to allow saving the information in the db to use the information in various ways".

We should move this DataObject into the silverstripe-maintenance module. The silverstripe-composer-versions module purely provides this DataObject, so could comfortably be merged into this main repository.

This would mean that the other modules, e.g. silverstripe-composer-update-checker, would be able to provide additional value via a DataExtension on this object (see bringyourownideas/silverstripe-composer-update-checker#25)

Currently there aren't any tests :( Some phpunit test would be nice.

As a Product Owner
I want to find other modules I can use on my site
So that I can reuse code when possible

Acceptance criteria

• There is a link out to the add-on site

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

As a Product Owner
I want to know the health of each module
So that I a great understand of my sites technical debt.

Acceptance criteria

• Module rating is displayed for most recent release default branch only (from addons site)
• Matches designs (circular image indicator and numeric indicator)

Considerations

• The addons site rating system is currently broken (silverstripe/addons.silverstripe.org#172), and work is nearing completion to replace it with a new system (silverstripe/addons.silverstripe.org#178) done
• The addons site does not have an API to expose the data for this yet so we will need to add one (silverstripe/addons.silverstripe.org#180) done

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

As a Product Owner
I want to be able to refresh the report when necessary
So that I have up-to-date information

Acceptance criteria

• Action to manually trigger a new report (generate report button)
• Displays a loading spinner while processing
• Actual generation should be done in the background via a queued job or similar
• Show a date stamp somewhere for when report was last generated

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

An example of this kind of process is the "external links" module which will do some AJAX polling to check whether the backend process has finished yet.

As a CMS user
I want to access to user support documentation
So that I can learn how to use the features of a module

Acceptance criteria

• A link is available to the module's page on addons.silverstripe.org
• Module provides access to more information (readme/addons link)
• Links to the readme will anchor directly to the top of the readme document

Nice to haves

• Link to developer docs
• Link to user help documentation if available/ applicable

Notes

We don't have structured data for user help documentation yet. This may be able to be achieved by adding some metadata to a module's composer.json file to point at it when it exists - we'd need to check if this data would make its way through Packagist and into this module via API before it's worth pursuing.

Version: CWP 2.2.x-dev, maintenance 2.1.x-dev, SilverStripe 4.3.x-dev

The text and icon are slightly out of alignment.

May also be affecting the "Explore addons" button:

For consistency with naming conventions, the task should be called UpdatePackageInfoTask.

Ideally we'd lose the namespace for it too, since SS3 doesn't have sufficient handling for namespaced build tasks (in SS4 it has the segment config prop to shorten it).

When trying to run the report generation task on the CWP platform we get this error in the failed job output:

[2018-06-25 15:03:04][INFO] Job caused exception The HOME or COMPOSER_HOME environment variable must be set for composer to run correctly in /sites/training-uat/releases/20180625025533/vendor/composer/composer/src/Composer/Factory.php at line 648

@sminnee suggested that he'd fixed the same error on the addons site by defining COMPOSE_HOME as one of your project variables in platform configuration, though for a default CWP site we'd rather define a fallback in code if it's not defined already, e.g.

if (!Environment::getEnv('COMPOSER_HOME')) {
    Environment::setEnv('COMPOSER_HOME', '/tmp');
}

Needs testing too of course

Pull requests

• #114
• silverstripe/cwp#125
• bringyourownideas/silverstripe-composer-update-checker#35
• #115
• silverstripe/cwp#127
• silverstripe/cwp#128

Tested on CWP and SSP

Background

It looks like the same issue was previously resolved for the CWP platform, and while there are notes explaining the fixes were tested on SC, we've had reports of issues

Related issues:

• #113
• #121
• bringyourownideas/silverstripe-composer-update-checker#43

Further information

We've had an internal report of this here: https://silverstripeltd.slack.com/archives/CLXKD9X51/p1583114132100800

CWP 2.4.x-dev

If I run the report as a content author, rather than a CMS admin, I can't see any of the records in the report table. The pagination still shows the number of results but perhaps none of the DataObjects are viewable by the user.

Works fine as an admin.

Presented as an (i) icon in the design, add a link to the module silverstripe-maintenance within Addons for more information about what the module does.

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

Related but not part of this issue:
Update the module to include details about the three columns #62

Background

PHP 7.1 is EOL in Dec 2019. Following this, SilverStripeLtd is planning to provide PHP >=7.2 support for modules compatible with version 3.7.x of the SilverStripe CMS, and 4.x versions based on the support timeline.

Overview

The 1.x release line of the module is limited to PHP ~7.1.0 and below.

After a quick look, I couldn't find a clear reason for the lock in PHP versions, so raising this issue to track.

"More info" in this context is user level, it should point to user docs

Currently there are three main modules with three build tasks and respective queued jobs:

• silverstripe-maintenance: https://github.com/bringyourownideas/silverstripe-maintenance/blob/9700bcb/src/Tasks/UpdatePackageInfo.php
• silverstripe-composer-update-checker: https://github.com/bringyourownideas/silverstripe-composer-update-checker/blob/6c2d94f/src/Tasks/CheckComposerUpdatesTask.php
• silverstripe-composer-security-checker: https://github.com/bringyourownideas/silverstripe-composer-security-checker/blob/812aabb/code/tasks/CheckComposerSecurityTask.php

Ideally we'd have a single queued job that runs a single build task - this would live in the silverstripe-maintenance module. This task should be extensible, allowing the other two modules to hook callbacks into various parts of the run() process (before/after?) to perform their actions, so executing the main build task (or job) would also run the other necessary functions.

Acceptance criteria

• When I generate a report (#38), all the data I need should be compiled and displayed at once
• The composer-update-checker and composer-security-checker modules do not require queuedjobs (note: edited - the security checker module can have its own job still since it performs a different set of tasks)

As a Product Owner
I want to know what version of each module
So that I can have a more informed discussion with my developers about upgrade decisions

Acceptance criteria

• The currently installed version of each module used is listed
• The most current version of the module is listed
• Next 'safe' stable version available is listed

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

Tasks

• Migrate silverstripe-composer-verisons model into silverstripe-maintenance module: #46
• Convert composer-update-checker module's model to an extension: bringyourownideas/silverstripe-composer-update-checker#25
• Replace constraint checking with composer/semver: bringyourownideas/silverstripe-composer-update-checker#23
• Determine next safe version: bringyourownideas/silverstripe-composer-update-checker#24

As a Product Owner
I want to be able to generate a report from the Site Summariser
So that I can do further analysis and share the information with a wider group of people

Acceptance criteria

• .csv export with complete information table is available
• Report data is in human discernable format

Modules like silverstripe-debugbar are not included in the report (but are included by the update-checker) because they're in require-dev

As a Product Owner
I want to a summary of the site
So that I can have an informed discussion with my developer about the effort to upgrade my site

Acceptance criteria

• Shows the total number of modules used on site
• Show the total lines of project PHP code (excluding vendor/*)
• Shows the total number of files (project only)
• Shows the database size
• Metric that indicates the relative size of the site Small, Medium, Large based on the above*

• CWP instance sizing, to be supplied by @be2n as a pre-requisite to development

NOTE: Could be delivered as a separate report but initially aim to have the information listed in the summary section of the report above the table

The print output of the maintenance module needs some tidy up after the fact that we have added a bunch of HTML to the grid items. If we want to keep print functionality we should tidy up the output to resemble otherwise my suggestion is to remove the print action for the time being.

This is a lightweight way to keep track of SilverStripe adoption by version number. While we're planning wider tracking to cover this use case, it's not going to be deployed as quickly into sites as this module. By sending the silverstripe/framework version number, we get a good indication of the adoption rate. silverstripe/recipe-core won't give us that coverage (isn't used everywhere).

Note that by only tracking the version number without a domain or unique identifier attached, we can't get a metric like "X sites are on 4.x". But we can at least say "X percent of calls to this API are made from 4.x sites". This is a compromise to keep tracking anonymous in this context.

Tasks/pull requests

• Gather the silverstripe/framework version when performing the API call to addons.silverstripe.org (see #41) - PR #73
• Include it as a request header in the GET call - PR #73
• Add data model as an audit metric to addons.silverstripe.org, logging each incoming header value - PR silverstripe/addons.silverstripe.org#194

When you click on a report row it will trigger the "module info" popover to open.

Clicking the report row again will not close it.

It either should, or we could add a "X" close button into the popover, top right maybe.

As part of the module stability reporting we would ideally like to be able to identify (in some way) modules that have been forked.

For example, if a dev has forked silverstripe/cms then we expect there to be two indicators for this:

• a VCS repository registered in composer.json
• potentially (not necessarily) a non-standard branch or tag

In some cases modules are supposed to be forked - for example the silverstripe/blog module is a fork.

This issue is to investigate how we can achieve the ability to identify modules that a dev has forked (making it unsafe)

• Raise issue for implementation

Example:

Looks like this when there's a description:

It's a bit pointless to show the latest dev branch as a release, right? That's not what we want people to upgrade to. This is on [email protected], not CWP. Maybe it's different in CWP due to recipe constraints?

With all the changes to the module (silverstripe-maintenance) we should update the Readme to include any UI updates and how to interpret the functionality it provides.

Examples of what needs mentioning:

• What "Installed, Available, Latest" means
• Security alerts—what the alert means, where to get more info, what does the tag mean eg. erg-345-345

Note: this is going to need to be updated again once we have more module work complete so this issue is to do a first shot at removing anything which is misleading or completely wrong.

The fact that Package::requireDefaultRecords runs the full task, in combination with the fact that we're now including the silverstripe-composer-update-checker logic as a callback inside this task, means that it adds a relatively large amount of time to a dev/build run. It can also max out the default PHP memory limit for some users at 128mb.

My suggestion would be NOT to use requireDefaultRecords for this, and rely on users either manually generating the report in the CMS or via build task, or letting a cron do it via queued jobs.

If we're creating a record with this approach I think it should be queuing a job rather than executing it immediately.

Following up from #31, the description is not part of the designs, so should be removed.

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

See #67

• When you click on "Check for updates" it shouldn't reload the GridField immediately
• Make Last Updated date green/prominent after the update has completed

We may need to write some custom AJAX handling for this to replace the GridField action.

As a Product Owner
I want to be able to access the version of SilverStripe CMS and CWP my site uses
So that I can make more informed decisions about product investment

Acceptance criteria

• The version of the SilverStripe CMS is displayed
• (CWP only) The version of the main CWP recipe used is displayed
  • In both CWP versions, the cwp/cwp-core module (only mandatory requirement) can be used to determine this
• Versions are displayed in the summary section of the report

Notes

This information is already available by hovering over the SilverStripe logo in the top left corner (may currently be broken for CWP) - the backend for this can be re-used.

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

This package uses Composer API to get information about packages. When this happens, composer attempts to write caches to the configured cache directory (.composer) using the COMPOSER_HOME or HOME environment variable. This causes errors on CWP where the .composer parent directory is not writable (this comes from HOME).

We have anticipated this in bringyourownideas/silverstripe-composer-update-checker: https://github.com/bringyourownideas/silverstripe-composer-update-checker/blob/1/src/Extensions/ComposerLoaderExtension.php#L100-L112

This code should be migrated to this module.

This causes Greylog to be flooded with errors.

Situation:

• https://github.com/wilr/silverstripe-googlesitemaps/blob/1.6.1/composer.json supports SS 3
• https://github.com/wilr/silverstripe-googlesitemaps/blob/1.8.0/composer.json supports SS 4

When using SilverStripe 3.x and running the report, it says that 1.8.0 is available to be installed. 1.8.0 requires SilverStripe 4, which must not be getting checked when we decide which version is "Available."

See designs on one of the other tickets, buttons need to have some classes added to them to look more like the designs

Requires #46 first

If using dev-master as a constraint, the Version column also contains the hash that is installed.

Ideally this would be in a separate column, e.g. InstalledVersion and InstalledHash for example

As part of the development work for "site summariser" we expect to complete the majority of the functionality and development work against the SilverStripe 3.x compatible version, then upgrade everything to work on 4.x at the end.

Acceptance criteria

• All features of the module work on SilverStripe 4 (PR: #78)
• Designs are updated to match (related: #81)
• When updating the list, there is an indicator that the report is being processed
• Badges are use different colours depending on warning level
• Module info remains under the module name (moving it to a popup will be a separate issue #68)

Sub tasks

• Update the composer update checker module to SS4
• Update the security checker module to SS4

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

As the business owner of a CWP site
I want to know what modules are specific to CWP recipes
So that I can identify what modules are supported by SilverStripe and the modules that are not

Acceptance criteria

• Modules can be sorted by a 'CWP modules' tag, filter, etc, and by non CWP modules
• CWP recipe modules are ID on an unsorted list
• The filter exists in CWP, not in this module (since it's specific to CWP)
• Link out to information on what CWP recipes are (help question mark in SS4)

Notes

• If SilverStripe 3 provides a GridField component to provide the dropdown with filters as in the designs then implement it, but if it doesn't exist already then don't add it. This could be a SilverStripe 4 only feature.

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

So the modules are installed in the vendor folder instead of the project root

Make it easier for decision makers :)

AC

• The report should have a visible date for when the report was last updated.
• When the report is refreshed/updated (when the "Check for updates" button is clicked) the date stamp should be able to attract the users attention to the fact the report update is complete. eg. Turns green or background has visible change.
• The date stamp only need to be implemented for SS4 version of the module (excludes SS3)

Tasks

• Design to be provided by @sachajudd
• Reassess and adjust effort required (story points) based on designs provided
• Implementation for SS4 only
• Time stamp is captured in the generated CSV file
• Design review

Notes

We (designers) are open to see what possibilities we have in regards to a loading state for the "Check for updates" button in the SS4 version—do we use the three dots loading indicator as per main actions in the Pages section or whether a spinning icon is easier to implement in this situation. Do some investigation and get back to us with whats possible before making a PR.

As a user I would like to have more information about the status and health of whats installed on my site.

AC's

• We have the ability to show more information about a module by utilising the popover component.
  The brief description of the module will move to the popover so that eventually more information can accompany the description, it will eventually accommodate:
  • Module support breakdown rating (health status)
  • User help link
  • Link to module on Addons
• There is a clear action to indicate there is more information available about the module (which triggers the popover)

Requirements

The popover can be triggered and navigated via keyboard (can raise issue in CMS core if it doesn't)

Design

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684

Add Transifex localisation support for this module.

We're not able to maintain Transifex easily between two versions, so we should do this for SS4 only.

We need to add target="_blank" attribute to the template for it

Browsers that aren't Chrome seem to deal with this in interesting manners.
The element is currently positioned absolute with a default right property, but no top property seems to see browsers do as they please with the alignment.

Adding a top: 1.2308rem to the a that is .health-indicator sees the issue solved, however this needs to be done appropriately with scss variables - the value here is the padding-top from the parent h3 that is .pacakge-summary__details-header

As a Product Owner, I want to know the definitions of what module versions are available within the CMS, so I can easily understand the support level of modules on my site.

Use case:
A Product Owner can see a module has an installed version of 1.x.x with no "AVAILABLE" version, but there is a 2.x.x "LATEST" version. The Product Owner is unsure on what the "LATEST" version is, or how to get it.

Acceptance Criteria:

• mouse-over text is added for the "INSTALLED", "AVAILABLE", AND "LATEST" headings describing the scope of support.
• mouse-over text is accessible by a screen reader

Notes:

Definitions are available at: https://github.com/bringyourownideas/silverstripe-maintenance/blob/master/docs/en/userguide/index.md#what-do-version-available-latest-mean

As a Product Owner
I want to be alerted about module security issues
So that I can make more timely remedial action

Acceptance criteria

• If there is available security information (e.g. a new security patch) an alert is visible that summarises the information
• Security information available for individual modules is presented at a module level

Designs: https://projects.invisionapp.com/share/ASGU6A7RT8U#/screens/291050684