Closed (fixed)
Project:
Project Browser
Version:
1.0.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
2 Jun 2022 at 14:23 UTC
Updated:
7 Jul 2022 at 20:44 UTC
Jump to comment: Most recent, Most recent file
Show commands
changes
Comments
Comment #3
fjgarlin commentedNeed the related issues to be merged first, otherwise, I'll be getting a lot of merge conflicts, etc.
Comment #4
fjgarlin commentedComment #5
fjgarlin commentedCurrently, the mock and the jsonapi plugin curate the data and make sure that projects are compatible with the current version.
I'll wait for the related tickets to be merged to tackle this task.
Comment #6
fjgarlin commentedThis MR forces the Plugins to provide a "is_compatible" attribute that should check whether the module is compatible with the current installed Drupal version.
Each plugin should determine how to do this. For example:
* The Mock plugin filters the modules before adding them to the database, so the logic is as simple as "is_compatible = TRUE".
* The jsonapi plugin (#3240319) actually checks the currently installed version with the semver range values returned by the api endpoint, and determines validity based on that (this plugin also allows querying per version for example).
* The random plugin just randomizes this :-)
The user experience is the same on our Mock and Jsonapi plugins, but this works as a failsafe in case future plugins provide non-compatible modules, AND it opens the door to a new filter in the UI, in case we'll want this.
A test has been added to the MR to check this feature.
To test this issue:
* Trigger drupalpod or your go-to test-environment
* Enabled "Project Browser Devel" module
* Visit the "Browse" page and you should see the new flag in action in the shape of a disabled button. I tried to use existing elements for this.
Comment #7
fjgarlin commentedComment #8
fjgarlin commentedComment #9
fjgarlin commentedComment #10
fjgarlin commentedComment #12
tim.plunkettI'm fine with this from a code perspective, but I'm worried about the color contrast of that text on the button. Will ask someone to help verify whether it is accessible enough.
Comment #13
bnjmnmRe #12 The color contrast does need to be updated to meet the AA standard of 4.5:1 text/bg.
It's worth noting the current solution uses Claro's color palette which has a low contrast ratio and is usually acceptable if the form element is disabled. However, in this case, the disabled button is also the only place that communicates that the module is incompatible. This is important/relevant information, so it's beholden to the contrast requirements. If the button had no consequential information when disabled (other than what the button does), then it could get away with low contrast.
Comment #14
fjgarlin commentedWill rebase and apply a text color of #706969 as mentioned in slack.
Comment #15
fjgarlin commentedCSS change addressing #12 and #13 with the agreed value is now in place. Ready to review again.
Comment #17
tim.plunkettThanks @bnjmnm and @fjgarlin! Merged.