This class got broken during what seems to be a
drive-by style-improvement in fbe1215365. That change:
* made it incompatible with frozen strings as error messages
* broke the intended hiding of messages if they came from the
wrong class
All of this went by unnoticed, because there were no specs
for the InternalError class.
Specs have now been added and the previous version of the code
mostly restored. Since there were some callers that always created the
exception with known safe error messages, I added a new class just for these
cases, because they were intended to "just show the message". So we can
keep using the original implementation for rescue_from handling.
I am not quite sure how this failed on a syntactic level,
but the previous definition of the parameters accepted by
our tools:
* skipped/ignored the server_context parameter
* didn't work properly for no args being passed to the tool call
We now properly pass along the server_context, allowing to use the
current user determined by our MCP endpoint, instead of repeating usage
of User.current.
This also fixes calls to tools without parameters
So far this configuration wasn't accessible for users at all.
This UI allows to disable all tools and resources separately,
as well as customizing their textual descriptions.
Adds `GET /api/v3/projects/:id/configuration` endpoint that returns
all global configuration properties plus project-specific settings.
This allows client apps to check both enterprise token features
(availableFeatures) and project settings (enabledInternalComments)
in a single API call.
Not sure why the mcp gem in some cases returns no
response (nil), but those cases caused an HTTP 500 so far.
The new code will lead to "null" being returned from the server
literally, but testing with Langdock as an MCP client indicates,
that this is good enough for the requests causing this.
This is against the schema for definition for links, which
already allow the title to be missing, but don't allow
it to be null. If it's present it must have a string as a value.
Previously there was a separate permissions check for
/api/v3/versions/:id. This check at least looked like it was
inconsistent with the visible-scope.
Using the scope both for /api/v3/versions and /api/v3/versions/:id
ensures that both will return results consistent with each other.
As part of this change, the manage_versions permission was also added into
the Version.visible scope and the Version#visible? method, because it was missing so far
from those places.
Instead of defining the mcp tools as static classes, we are now
using the Mcp::Tool.define flow to build them. This allows us to
change their description on every call and thus define it through
the configuration stored in the database.
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.
Those self-tests are "basic" in the sense that they only validate
their compliance with our documented schema in one representation.
These test cases don't yet cover/validate whether the generated
representation also fulfills the schema under different circumstances,
for example when rendering for a user with fewer privileges, not allowed
to see certain fields.
Where necessary, the schema was changed to reflect the reality, e.g.
when those tests revealed that a "required" field might be missing due to
a lack of permissions.
In a few cases the implementation was adapted to allow for stricter guarantees
of the specified schema, for example links allowed to leave out the title key
already, so its not necessary to emit `title: nil` in cases where a title is
not known.
- hierarachy item now return a weight and a formatted weight in the API
response
- weight is the accurate value
- formatted weight is the value in display representation after standard
formatting
They both use `work_package` and `work_package_id` to render links,
which generates verbose deprecation warnings. They are filling up logs.
Force usage of `entity` and `entity_id` instead in the api representers
to reduce the burden.
They both use `work_package` and `work_package_id` to render links,
which generates verbose deprecation warnings. They are filling up logs.
Force usage of `entity` and `entity_id` instead in the api representers
to reduce the burden.
https://community.openproject.org/work_packages/66307
- Add workspace icon to the project list page
- Display workspace type icon in the projects selector.
- Move the project select program icons after the title, remove project icon.
- Remove unused import
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
- Fix linting warnings
- Display workspace type after the project name in the project list.
- Use safe join and simple labels for the workspace type badge.
- Use correct program icon, change the api endpoint to use workspaces.
This property was inherited from the PrincipalRepresenter where
it's writable. For users this would lead to a server error, since
there is no name attribute on the user model.
We could've just marked the property as `writable: false`, though
then changes to it would just be ignored without any API feedback,
but marking it as read-only through the contract is not possible, since
the contract can only validate attributes that really do exist.
To be able to provide API feedback, I overwrote the setter to raise a proper
validation error.
Jan Sandbrink