This is an effort to give administrators more control
over the volume of data returned. While we don't want to limit
the actually useful part of the data, we suspect that some MCP
clients might pass both the content and the structured content
to the language model. Thus we allow admins to configure which
one will be generated.
Some clients, such as Claude code require dynamic client registration
for their regular workflow. However, they allow to fallback to
static HTTP headers for authentication.
This approach allows to construct the corresponding header for Basic authentication
and add it to Claude.
So far the MCP server only offers a single tool, but authentication
and integration is already built in a way that's intended to last.
Ideally extensions to this happen by adding additional tools or resources,
but will not require further architectural changes, though realistically we'll
probably identify more potential for reuse, once we added a few more tools.
The exact representation of results is still slightly to-be-discussed. Right
now we are using vanilla APIv3 representation, which might be enough, but possibly
we want to represent linked resources differently, so that they can be recognized
to be fetchable via MCP resources more easily.
Found via `codespell -q 3 -S ./config/locales,./modules/xls_export/config/locales,./modules/job_status/config/locales,./modules/two_factor_authentication/config/locales,./modules/backlogs/config/locales/crowdin,./**/config/locales -L ba,nd,parms,pullrequest,pullrequests,sur,varius`
* breakup wp resource specs into separate files
* introduce and employ typeahead filter on work packages
Co-authored-by: Oliver Günther <mail@oliverguenther.de>
The default BooleanEquals filter treats null same as false. Because of that, notifications that are not meant for ian were displayed. The BooleanEqualsStrict filter only filters for false as expected so that the notifications are not displayed.
* Rewrite members page to output name column
* Remove white-space nowrap for long login names in administration
* Extend member specs
* Allow query instance to be used in table cell
* Fix memberships specs with changed columns
* Add order for email
* Review feedback
* Allow x to close add member form
* WIP sort firstname/lastname
* Make status sortable
* Extract order_by_name into the order class
* Re-add but deprecate order_by_name
It's still in use in combination with some special scopes
(custom actions for example) that I don't want to remove right now
* Rewrite order_by_name into scope
AnyFixture will create once instance of a factory for reuse in a number of specs.
This will work fine until we require a clean slate for a specific example.
As we have numerous tests that test like the database is empty,
we get a number of disadvantages:
- After an example with `with_clean_fixture` metadata, the fixture will only be regenerated
after the next example that uses it. This means the order of execution will change
the number of objects in the DB.
- The more `with_clean_fixture` we have, the smaller the performance advantage of AnyFixture will
result in.
- You cannot use an AnyFixture in a spec that needs a clean slate. This should be obvious but was overlooked
by myself.
Updates the copyright to 2021 for all files that have a copyright. Files in our source code without the copyright header still do not receive one automatically. Additionally, backlisted files are also excluded.
Previously the copyright of chiliproject which references redmine stated a copyright of redmine up to and including 2017 which is not true for the code we have in here. Because of that I changed that to 2013
Uses FactoryBot to keep and maintain specific records in a special transaction that does not get removed after each spec.
They automatically are created whenever first hitting them.
This makes an excellent time saver for items that are commonly used, such as an admin user account
Grape's validation runs after a `before` block so we should avoid using
raw params there and instead using `declared(params)` which returns only
the validated whitelisted params, much like a permitted params hash.
Jan Sandbrink