А rooms у вас на каком урле висят? /frontend/rooms или просто /rooms?

и на таком и на таком

т.е

"get"={
*              "access_control"="is_granted('ROLE_ROOM_LIST')"
*          },
*          "frontendGet"={
*              "normalization_context"={"groups"={"frontend_read", "read", "is_active_read"}},
*              "method"="GET",
*              "path"="/frontend/profile/rooms",
*              "controller"=RoomGetCollectionAction::class,
*              "defaults"={"_api_receive"=false},
*          },

находил тему на стак оверфлоу, но тоже не очень помогает
https://stackoverflow.com/questions/62776366/api-platform-custom-subresource-path-doesnt-work

но как бы я не задавал имя ендпоинту, path просто не меняется

А всю аннотацию покажите плиз

С ApiResource

messages_get_subresource - вот это выглядит как неправильное название операции. APIP же генерит эти названия автоматически, что-то типа "rooms_room_messages_get_subresource" (еще и префикс может добавить). И вам надо указывать именно то название, которое гененрится .Иначе APIP не может отмапить ваш кастомный path на операцию и использует дефолт урл

блин точно пропустил вначале название room. Спасибо.
было изначально так:
- api_rooms_room_messages_get_subresource - не работало
потом по ошибки вписал так:
- messages_get_subresource - не работало
после вашей правки написал:
- room_messages_get_subresource - заработало

Спасибо)

Всегда пожалуйста. Ссылку на кошелек кину в личку)

Добрый день.
Ребят, хочу сделать логгирование изменения нескольких сущностьей.
Есть две сущности:

App:
int $id
status $status

Task:
int $id
status $status

Хотелось бы складывать в таблицу время смены статуса.

Log
int $id
string $type_entity (app or task)
int $id_entity
status $status
date $date

Прогуглил насчет полиморфных связей, но чет все советуют от них уйти, либо же нахожу примеры, которые мне не подходят.
Может кто дать совет как это реализовать на доктрине и вообще стоит ли над этим заморачиваться или есть лучшее решение?

Заранее благодарю за ответы :3

App:
int $id
status $status

Task:
int $id
status $status

Log
int $id
string $type_entity (app or task)
int $id_entity
status $status
date $date

Ну так складівай без связи

Это ж лог

insert into log (fields_here) values(...)
все

Если бы это было просто логгирование, для какой-нибудь аналитики или просто техническая приблуда - да.
Но там завязаны пару бизнес правил насчет перехода на статус, хотелось бы как-нибудь привязать их к сущностям

Точно, в доктрине так и делается)))

а в changeStatus методе делаем просто dispatch(new StatusChangedEvent())

логгер подписывается на этот ивент и делает что хочет с данными