PUT запрос от имени пользователя возвращает ошибку

Руслан, вообще, довольно странно. Если бы там было ограничено по правам то отдавало бы 403 для пользователя. Можете показать примеры запросов? Точно в обоих случаях одинаковые?

Также проверьте, нет ли ограничений прав на объекте OpportunityFile: на операции, записи, поле Data.

Вот такой код запроса на изменение поля Data:

curl --location --request PUT 'https://my.company.com/0/odata/OpportunityFile(f7cb87e9-dea4-4609-95f6-5ce7ca499544)/Data' \
--header 'BPMCSRF: qR7NHdxnvLVamFiF4QnCsu' \
--header 'Content-Type: application/pdf' \
--header 'Cookie: BPMLOADER=hhv02mucokh1hdvnnrrna43e; UserName=99|97|98|105|110|101|116|68|105|115|116|114|105|98|117|116|111|114; BPMSESSIONID=zxfuxvecmcjbg0vteh1ibpvh; .ASPXAUTH=45F3530449360B52EC8592892D0588D74F78D2F37E2A91893700AB56ED32E3589FE972BF81199EE6EF9DBA8D6F3A0341586187B1D5C03358262C3E0DF181FE5DE68AB65946E18A742A83EAB74BD1A5DDE5BE6A99CEA0F5EC1574FE9A746D193CB161A330A4732121728AA5F43D2F4D252D844867C0CEDD6E9BC507012C6FF202A540A311D80980E6C4290C8426EF0E0E37B73543828236BFC59E8EABB3158132B0BA2566D72649E0942BC708DDA1264793A6302875345757E32AA1F8E8688C1C8DD9A192CA06BF8B3BC077C420F46C6211B3D37BEB674450533514FF33AA21D72B616E22CEDBBC999D5AB7B66F0BF45E10290E814024AB1550A8455978A60BC124CDE2458A99E26613202F55BA2BF2381FC057CAAF0669170605291C61DD6764A25A3694999D88BE8E3ACA371C225B88D02D46F40791CB11B6928C7587231A3E04CED54910D82498580AA62AC2DBF66088F43B35E09B07ABE3F8182A9250501969C958DBC9464682AE07DEF13C7D1D4C910AEAFBD8A6C2CEE558DA3087EB956F8EE24346; BPMCSRF=qR7NHdxnvLVamFiF4QnCsu' \
--data-binary '@/D:/Docs/Pictures/kyoScan-‎4‎.‎23‎.‎2020-‎14‎.‎07‎.‎08.pdf'

Он не меняется, менял только права пользователя (повышал до админа). С админскими правами работает, без - нет. 

Вообще с самого начала все было выполнено от имени администратора (себя), чтобы исключить влияние прав и проверить работоспособность запросов. Когда все заработало от администратора, я стал проверять от имени пользователя (не себя). Запрос на добавление сработал, на изменение - нет.  Повысил права рядового пользователя до админа и запрос сработал. Вернул обратно - не работает.

Ограничения по колонкам не настроены.

У пользователя есть право на системную операцию CanUseODataService? Хотя, выше пишете, что POST у него прошёл...

Зверев Александр,

Да, есть. 

Можно было бы понять если бы были ошибки типа 401, 403 или 406, но никак не 404. Руслан, а если завести демо-сайт в облаке и отправлять такие запросы на него, тоже воспроизводится? 

Спасибо, Александр, за подсказку. Развернул тестовую базу в облаке с версией 7.17, у нас 7.16.4. Боялся что из-за разницы в версиях ошибка не воспроизведется. Но, нет, ошибка такая же. 

Руслан, у меня на демо-сайте 7.17 не воспроизвелось: и под админом, и под пользователем файл успешно обновился. Пробовал не в curl, а в Fiddler, и на тестовом сайте не была включена проверка BPMCSRF. Пользователя в группы не включал, права на чтение и изменение записи о продаже дал вручную. Файл создал в интерфейсе, то есть на момент запроса поле Data уже было со старым содержимым.

Значит, ошибка не в «коробке», а что-то неправильно отправляете к серверу. 

Зверев Александр,

Что не правильно может отправляться на сервер, если от администратора запрос успешно отрабатывает, а от пользователя нет? Повторю - запрос не меняется, значит запрос правильный.

У меня и под администратором, и под пользователем файл обновляется. Без точного описания, как воспроизвести, не могу сказать, что неправильно.

А если, как и в моём примере, файл на момент запуска PUT уже есть, у Вас тоже такая ошибка?

Зверев Александр,

Да, с предварительно загруженным файлом работает так же. К тому же, неверно полагаться на предварительно загруженные данные, откуда им взяться, если мы впервые загружаем файл?

Вот результат запроса от имени администратора (200 Ок):

Вот результат от имени пользователя 404 (Not Found):

Выполнено на тестовой платформе - https://041470-sales-enterprise.terrasoft.ru/

Руслан, попробуйте не в Postman, а в Fiddler, как на моих скриншотах. Сейчас приведенного тестового сайта уже нет, проверить на нём не могу.

Либо же обратитесь в поддержку с более подробным описанием воспроизведения и параметрами подключения.

Ссылка на тестовую платформу устарела, сгенерировал новое тестовое приложение. 

Все таки дело было в правах, но оказалось что права проверялись не на таблицу OpportunityFile, а на Opportunity. Интересно получается, создать запись в таблице OpportunityFile разрешено, а изменить нет. Неожиданно.

Руслан, то есть на нескольких разных тестовых базах было одинаково настроено с правами? А как именно? После выдачи пользователю прав на изменение продажи заработало?

Хороший вопрос, Александр. Проверял на двух площадках: тестовое приложение компании и тестовая, которая дается в рамках тест-драйва от Террасофт. Права, конечно же, были настроены по разному. На тот момент я не думал что дело было в правах, и на тестовой площадке ни чего кроме того что добавил тестового пользователя не делал. Сегодня проверил как было настроено на тестовой платформе - там вообще ни чего не было настроено по правам для тестового пользователя (у создателя тестовой площадки права администратора. Продажа принадлежит администратору). К тому же, самое важное, что я сегодня обнаружил, это то что запрос на изменение данных начинает работать если добавить права на ЧТЕНИЕ продажи, а не на изменение. Т.е. я сначала сразу добавил права на изменение продажи - не работает, добавил на чтение - заработало, убрал права на изменение (запрещающих прав нет) - все равно работает. Как то не логично, если же есть логика, дайте, пожалуйста, объяснение.

Руслан, пожалуйста, дайте точные параметры воспроизведения: под какими пользователями, какую запись, какой запрос. Я выше пробовал на своей тестовой, у меня работает и без прав админа.

Либо напишите всё это в поддержку.