User has role site filter

[jimsafley]

This will filter out sites where the logged in user has no role (this is on the admin browse page ). There's a "View all" checkbox there that may need styling - maybe in the same way as the .batch-inputs div on the item browse page? To see the checkbox, you'll need to be logged in as a non-admin user.

[erseco]

This PR is extremely valuable for large Omeka S installations! We currently manage over 500 sites in our installation, and this filter would significantly improve both performance and usability.

By limiting the displayed sites to only those where a user has a role, it would:

1. Reduce initial page load times
2. Simplify navigation for non-admin users
3. Create a more focused and relevant admin experience

I'm looking forward to seeing this merged into the main codebase as it addresses a real pain point for large-scale Omeka S deployments.

Regarding the failing tests: there appears to be a minor code style issue in application/src/Api/Adapter/SiteAdapter.php around line 42-43 with parenthesis indentation that's causing the PHP CS Fixer to fail. A small adjustment to the indentation should resolve this.

[zerocrates]

Can we fix the codestyle checker whining here? I think it's asking for that weird indentation because one of the closing parens for the previous line has been accidentally included in the )) line it's asking to move.

[zerocrates]

The "view all" option here just goes always to ?user_has_role=0 (or the "normal" browse if unchecking).

Maybe simpler to just make it a link in that case? I don't think it's necessarily a big deal whether that's just statically to the full set with/without the has_role parameter, or is to the current query with just that param changed.

I guess aproblem with doing it this way is that you need to then come up with wording for what the opposite of "view all" is here. "Your sites" vs "All sites" or something, maybe.

[jimsafley]

Maybe simpler to just make it a link in that case?

That would it the only browse control that's a link and not an input. @kimisgold What are your thoughts on this?

[kimisgold]

In past a11y audits, we've gotten complaints for input elements that unexpectedly trigger a page load, so using a link here makes sense to me. I also think the labeling needs to provide more functional context like @zerocrates. I'm thinking of something like this:

We could also do "Your sites | All sites" styled like filters/subnavigation if we want it to be less wordy.