🇨🇦Canada @ergonlogic

FYI, you may occasionally see an error like:

The 'bin_c50-c53' contents does not match hash 'sha256' specified in the 'snapshot' metadata.

Sometimes this is transitory, and will fix itself in a matter of seconds. Re-running `composer update` will likely succeed. If not, but the 'bin_c50-c53' part changes, wait a minute or two and try again. This is a symptom of temporary inconsistency during metadata updates on the server-side. This is being addressed upstream in rugged/rugged#208: Ensure metadata consistency.

On the other hand, this kind of error can also persist longer. If re-running `composer update` show no change in the 'bin_c50-c53' part of the error message, this likely indicates that the TUF server has "stalled" during a metadata update. This will generally require intervention by a TUF server administrator. This is being addressed upstream in rugged/rugged#204: Add a monitor task to clean up stuck targets.

We expect this to stabilize as we address the upstream issues. However, if you do encounter such an error, it is worthwhile to report it here, in this ticket.

For Rugged, we documented 3 tickets that came out of the OSTIF audit: https://gitlab.com/rugged/rugged/-/issues/?label_name%5B%5D=OSTIF-2023. These were previously confidential, but we have now made them all public.

• #156: This ticket just documents some broken links in the docs. So this is not a security issue at all.
• #157: This ticket listed some secrets in the source code:
• A CI job token that was cruft from when the project itself was non-public. This has been removed.
• A github token to download php-tuf and the composer integration plugin. This is required for CI; ie. won't fix.
• A hard-coded password for one of the services running in the dev env. This does not affect production deployments. We are considering disabling this by default.
• #158: This ticket describes access to keys in the dev/test environments. This does not affect prod environments. This will likely end up "won't fix".

All of these ticket are scheduled for final review (and remediation, if required) in the coming weeks.

Report from a medium-sized application:

Packages: 53
TUF metadata: 3.6M

Tested on a second small side-project:

Packages: 19
TUF metadata: 2.8M

I'm planning to test on a bunch of different projects. To make this more efficient, I put together a couple simple scripts that just run the steps outlined in the issue summary.

Tested on a small personal project. Results:

• Packages: 15
• TUF metadata: 2.9M

The initial idea was to create a docs page with testing instructions, and then ask testers to create issues to document their results. But, upon further reflection, this is overkill. All we need is an issue for the testing itself (see: 📌 Manually test TUF-enabled Composer projects Active ), and ask for feedback in comments.

I've simplified the issue summary accordingly. I'm moving it back to 'active', since we need to promote this testing,

ergonlogic → created an issue.

ergonlogic → created an issue.

ergonlogic → created an issue.

After some further testing, I merged the branch from ✨ Add flowchart graph format Fixed to 1.0.x, and released 1.0.0-alpha3

Merged to 1.0.x.

I tested that providing our own views style plugin doesn't break the existing erDiagram graph plugin. It does add some options in the views settings that aren't currently supported by that plugin (eg. dynamic vertex shape and edge styling). But I think we can deal with that in a separate issue. The simplest solution would be to have the erDiagram plugin go back to using the default GraphAPI views style plugin.

I've released 1.0.0-alpha2

I'll mark this postponed for now, pending further testing of ✨ Add flowchart graph format Fixed . I'll try to get to it ASAP.

Oh, I see there's already an alpha1 tag. I'll release that too, and then proceed with alpha2 and alpha3, per the plan.

I've merged all but the last issue ( ✨ Add flowchart graph format Fixed ). That one is significantly more complex, and may affect existing functionality.

So I plan to tag and release 1.0.0-alpha1 based on the current state of the 1.0.x branch. After a bit more testing of ✨ Add flowchart graph format Fixed , I'll probably tag and release 1.0.0-alpha2. That way, if alpha2 introduces bugs in the erDiagram plugin, sites can freeze at alpha1 until we can resolve said hypothetical bugs.

I updated the issue summary to reflect this plan.

Of course, I'm open to alternatives, if anyone wants to suggest one.

I merged this branch to 1.0.x.

The fix here is a sub-module that shouldn't affect any of the rest of the codebase.

I've merged the related branch to 1.0.x.

The fix is pretty simple, and I've been testing this pretty extensively in developing solutions for the related issues.

Merged to 1.0.x.

Updated summary to list issues to include in the release.

Thank you, @avpaderno.

I can confirm that I have access to edit the project, administer maintainers, etc.

Now that #3468786: Offering to maintain Mermaid Integration → is resolved, I'm planning to merge the branches from the open tickets and cut an alpha release ASAP.

Configuration Read-only mode → now supports a hook (hook_config_readonly_whitelist_patterns()) that would allow us to specify whatever config is set to Level 1 & 2 enforcement. This'd have the effect of locking down Level 3 config (this feature request), as well as any unenforced config (which seems prudent anyway).

Alternatively, there's already a feature request for #3085001: Config blacklist to only block some configuration while in read only mode →

ergonlogic → created an issue.

16 days have now passed with no response.

I'm not sure if "Needs work" is the appropriate status, but it's my best guess :)

FYI, a summary of the report was published here: https://ostif.org/php-tuf-audit-complete/, which includes a link to the report itself.

Is this still on your radar @ergonlogic?

Not at the moment, no.

Edge labels are now supported.

Linking vertices their entities is now optional.

Flowchart direction is now configurable.

Flowchart edge styles are now configurable.

I'm escalating this, after waiting for the current owner to 2 weeks, per Becoming owner, maintainer, or co-maintainer of a project → .

Oops, wrong patch. Here's the correct one.

The patch (attached) is for Config Enforce. So I've moved this ticket over there.

Let's fix ✨ Improve usability of Config Enforce Devel's UI Postponed !

ergonlogic → created an issue. See original summary → .

Trivial patch attached.

ergonlogic → created an issue.

It will probably be easier to define our own Views style plugin, rather than taking over and altering the default GraphAPI one. We'd still inherit from that one, but I don't like the idea of wrapping a bunch of conditional logic around the Mermaid-specific code.

I've implemented a new views style plugin just for Mermaid graphs. I also overrode the default GraphAPI views style plugin, to remove the Mermaid graphs. I'm not really sure this is the best approach, but I couldn't figure out anything better.

I updated the issue summary with my progress so far, and some planned next steps.

What are the next steps here?

Hands on, it looks like we'd need to:

1. Update the text on this page, and
2. Update the label in the form itself
3. (Optionally) Update the key also, but that's probably overkill.

That all is pretty straight-forward. However, I wonder if there's a policy discussion needed at the DA, since presumably their the ones using this demographic data.

I contacted @ameeuwsen via their contact form on Monday, 19 August 2024.

No news yet.

I've pushed a commit that's mostly the same as in the patch, except in a sub-module, per 📌 Move GraphAPI support to a submodule Needs review , with the change in namespace, etc. Obviously, this branch extends the one from that issue.

This is pretty straight-forward. I re-based from the branch in 📌 Automated Drupal 10 compatibility fixes RTBC .

ergonlogic → made their first commit to this issue’s fork.

I'm going to move to a git-based workflow, so that 📌 Move GraphAPI support to a submodule Needs review can be a separate branch, that we then base the work here (and in ✨ Add flowchart graph format Fixed ) off of.

So as not to inadvertently lost any of the work I've done so far, I'll just attach a patch of my latest iteration on this.

I've made a bunch more progress on this, but let's get 📌 Move GraphAPI support to a submodule Needs review done first, so that this feature can more cleanly be added to the GraphAPI sub-module.

Let's get 📌 Move GraphAPI support to a submodule Needs review done first, so that the text filter stuff can more cleanly be added as a sub-module.

I created 📌 Move GraphAPI support to a submodule Needs review to handle the first part.

ergonlogic → created an issue.

Thanks, @joachim. That all makes sense.

Since there's a patch now, I suppose this should be "Needs review"

Can we add "Neurodivergent" to this list? I am autistic, and I don't identify with any of the existing options.

Also, all the examples for "Learning Differences" are considered neurodivergent. So another option would be to replace LD with ND.

Here's a first pass at implementing the Mermaid Flowchart format.

Note that I also overrode the template to use a <pre> tags, since that appears to be the suggested approach now. This also has the nice benefit of making the Views preview more legible. I can split this into a separate issue, if that's preferable.

This currently hard-codes vertices rendered as circles, and that the flowchart will be left-to-right. It also doesn't implement the 'click' behaviour. I think I'll need to extend GraphAPI's Views style plugin (and use hook_views_plugins_style_alter()) to address that stuff. But I'm certainly open to other suggestions.

The Mermaid module is meant to be used as an extension to GraphAPI.

I agree that's mostly what's currently implemented there, along with adding the Mermaid JS library. But it's called "Mermaid Integration", uses the mermaid namespace, and resides at drupal.org/project/mermaid, not drupal.org/project/graphapi_mermaid.

I'm suggesting adding an input filter that renders Mermaid syntax (using only the Mermaid library). It doesn't really need GraphAPI functionality at all. It's basically just replacing `[mermaid]...[/mermaid]` blocks with `

...

`.

For reference, I've attached a patch (for the mermaid project). Note that it uses the Mermaid JS library provided by the Mermaid Integration module, but otherwise stands alone, using only Drupal core.

It also allows for the selection of a Mermaid theme, which partially duplicates MermaidEntityRelationship::defaultOptionsForm. As I'd mentioned previously, this seems like an opportunity to consolidate Mermaid configuration functionality in a MermaidTrait. I'd argue that such a trait ought to also live in the Mermaid module, and would certainly seem out-of-place in GraphAPI.

For the sake of having the patch work, I've moved this issue back to Mermaid Integration. If you insist, I'll move it back to GraphAPI, and revise the patch accordingly.

I see that we already have a TGF filter plugin in GraphAPI. But since the Mermaid filter plugin will depend on the external library, we'd need to add the library that in GraphAPI too, instead of just re-using the one provided by the Mermaid Integration module.

I'd also like to support various themes, and maybe later other Mermaid config. Code to handle this could probably be extracted into a MermaidTrait, to further reduce duplicated code between both Filter and Graph plugins.

Hi @joaquim. Thanks for taking a look at this.

Could you clarify why you think this feature fits better in GraphAPI than in Mermaid Integration? The Mermaid JS library is already provided in the other module.

ergonlogic → created an issue.

ergonlogic → created an issue.

ergonlogic → created an issue.

ergonlogic → created an issue.

I can confirm this bug, and that it still exists on the current release (8.x-2.1).

Also, the patch in #4 fixes it.

hestenet → credited ergonlogic → .

hestenet → credited ergonlogic → .

hestenet → credited ergonlogic → .

hestenet → credited ergonlogic → .

hestenet → credited ergonlogic → .

hestenet → credited ergonlogic → .

hestenet → credited ergonlogic → .

Done.

I also support Dan joining the maintainers of Aegir3.

To help expedite his work on the tickets that he listed, I'm going to proceed with adding him as a maintainer on the various core projects.

If anyone objects, please do so here, before the ticket closes automatically in a couple weeks.

ergonlogic → created an issue.

Here's a patch.

Marking as postponed until I have a chance to create an MR against 2.0.x

ergonlogic → created an issue.

Also worth noting here: we could not get our extended access plugin to interact properly with the upstream one 📌 Make it easier to extend existing plugins Active .

This should be documented in our plugin's inline docs. Also, to facilitate this use-case, we've made it so that, if you leave the "workflow" select empty (ie. "- Select a value -"), it falls back to acting like the upstream plugin. This avoids having to check all the workflow states.

Also worth noting here: we could not get our extended access plugin to interact properly with the upstream one.

For background, the idea was to use the field access plugin (from eca_access) to forbid access to all fields, then use our plugin (that extends the field access one) to allow access during some workflow steps (in combination with other conditions).

While we could accomplish something similar (minus the workflow bit) with just the upstream plugin, we needed to use our extended one for both parts (forbid then allow), in order for this to work.

We think this might have something to do with the order that the hook_entity_field_access() are being evaluated or how the Symfony EventDispatcher sorted events. But we haven't yet been able to determine the root cause of this.

Right. ECA is becoming a key piece of our Drupal stack, so I'm sure that I'll have a chance (hopefully over the summer) to refactor this against 2.0.x.

Some notes on possible future improvements to this:

• Abstract the underlying implementation to pass the class name as a parameter
• Move that method into a trait (or base class) for easier re-use across the rest of ECA (it currently only applies to eca_access)
• Add some static caching to minimize performance impact.
• Add some docs to show how easy it has become to extend existing plugins.

Third time's a charm.

whitespace fix

Re-rolled the patch, since it included the fix from 🐛 ECA Access: Incorrect field name in "Determining entity field access" plugin Needs work

See 📌 Make it easier to extend existing plugins Active for how I found a way to cleanly extend ECA Access plugins.

As a starting point, branch 3432502-1.1.x-extend-existing-plugins now allows extension of eca_access plugins using the technique described above.

I've also attached a patch to make it simpler to incorporate into a `composer.json` file.

The 2.0.x branch has drifted too far from 1.1.x for me to be able to develop my extension against it without significant refactoring. I need my plugin to work against the current stable release, so I'm going to start a new branch forked from 1.1.x.

ergonlogic → changed the visibility of the branch 3432502-extend-plugins to hidden.

ergonlogic → changed the visibility of the branch 3432502-extend-existing-plugins to hidden.

ergonlogic → created an issue.

Due to project time constraints and needing a stable patch to apply via Composer, I figured to share the patch here, rather than just keep it local to the project.

I'll provide an MR as time permits.

Here's a trivial patch.

ergonlogic → created an issue.

See attached patch.

Here's a patch that accomplished the sorting based on a 3rd-party library.

ergonlogic → created an issue.

ergonlogic → created an issue.

ergonlogic → created an issue.

ergonlogic → created an issue.