get_metadata_details: право роли на подчинённый объект показывается под его собственным адресом (#685) - #703
Conversation
…own address (#685) RoleRightsReader named a non-top rights target by its top object's FQN, so a right on Catalog.X.Attribute.Y read as a right on Catalog.X, in the rights matrix and in the RLS table, while modify_metadata accepts (and Rights.rights stores) the full address. The Object cell is now the address that resolves back to the same object through MetadataNodeResolver.resolveExisting, the form rights[].object accepts. The address builder moved from VendorSupportGuard into MetadataNodeResolver as addressOf (same behaviour, the guard delegates) with a strict resolvableAddressOf that answers null when a step is not addressable. Such targets keep the top object's FQN as before, and detached objects keep their fallback. The get_metadata_details guide and its docs page say so; a new e2e reads the attribute row and writes the read address back. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0174zH13nscxbTgBU4YfXcXK
|
@codex review — самое рискованное место: строгий |
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
E2E Test Results (EDT 2026.2) 4 files ±0 4 suites ±0 1h 15m 45s ⏱️ + 3m 16s Results for commit 54951af. ± Comparison against base commit d62c416. This pull request skips 2 tests. |
|
@codex review — самое рискованное место: строгий resolvableAddressOf — есть ли подчинённый вид, для которого напечатанный адрес резолвится в другой объект или не резолвится вовсе (то есть чтение и запись прав снова расходятся). |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Bravo. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
2 participants
Closes #685.
Что было
RoleRightsReader.objectFqnOfдля цели, которая не является top-объектом, брал FQN верхнего объекта (bmGetTopObject().bmGetFqn()). Поэтому право наCatalog.X.Attribute.Yв матрице прав и в таблице RLS выглядело как право наCatalog.X. Запись при этом принимает полный адрес (RoleRightsWriter.resolveObject→MetadataNodeResolver.resolveExisting), а вRights.rightsлежат два разных узла — чтение и запись были несимметричны.Что изменилось
MetadataNodeResolver.resolveExisting, — форма, которую принимаетrights[].objectуmodify_metadata:Catalog.X.Attribute.Y,Document.D.TabularSection.T.Attribute.A,InformationRegister.R.Dimension.D,Catalog.X.Command.Cи т.д. Верхний объект по-прежнему выводится черезbmGetFqn.VendorSupportGuard.objectAddress. Он перенесён вMetadataNodeResolverрядом сkindTokenForFeature:addressOf— побайтовый перенос (гард делегирует, его тесты не менялись) и строгийresolvableAddressOf, который отвечаетnull, если хоть один шаг не адресуем грамматикой резолвера, верхний объект — не тип конфигурации или у уровня нет имени. Третьей копии нет;CommandInterfaceSupport.mdObjectFqnне тронут — его семантика другая.MdObject, подчинённые не-конфигурационных верхних объектов) показываются, как и раньше, под FQN верхнего объекта — об этом было сказано в ишью при взятии. Отсоединённые объекты сохраняют прежний откат.get_metadata_details(раздел ролей) говорит, что колонка Object — это адрес дляrights[].object. Вdocs/tools/get_metadata_details.mdабзаца про роли не было вовсе (дрейф после Развёртка осиротевших прав ролей: отчёт по умолчанию, удаление доказанных сирот по запросу #687, генератор не запускали) — вставлен дословно, на то же место, что в гайде. Описания инструментов,inputSchema, golden и MANIFEST не менялись.Доказательства
RoleRightsReaderTest: воспроизведение ишью на моках с подключённым BM (на master обе строки былиCatalog.OrphProbeB), вид по умолчанию, табличная часть и её реквизит, измерение/ресурс/реквизит регистра, команда, пин проводки таблицы RLS — все красные на master. Стражи: верхний объект черезbmGetFqn; неадресуемый подчинённый (стандартный реквизит табличной части показан под каталогом, а не под табличной частью); отсоединённые откаты.MetadataNodeResolverTest: токены видов на каждом уровне; программноеName, а не синоним;nullдля шага вне грамматики, для не-конфигурационного верхнего объекта и для безымянного уровня; контракт полного кругаresolvableAddressOf→resolveExistingна 25 объектах.target/тестового бандла чистится перед каждым прогоном.test_role_rights_read_attribute_row_carries_its_full_address— сценарий из ишью: права на каталог и на его реквизит дают две разные ячейки Object (сверка ячеек целиком, не подстрок: FQN каталога — префикс адреса реквизита); прочитанный адрес записывается обратно (unset), право на реквизит исчезает, право на каталог остаётся. Локально не запускался — его первый прогон в этом CI на EDT 2026.2.1.MergeRulesToolTest.tearDown DirectoryNotEmptyодин раз, повтор зелёный).🤖 Generated with Claude Code
https://claude.ai/code/session_0174zH13nscxbTgBU4YfXcXK