Всем доброго времени суток.
При инсталляции специфичной Community на проекте нужна необходимость полностью закрыть доступ к Standard Detail Pages и List View Pages объектов.
Идея какая, у юзера есть доступ к Accounts объектам но он не может попасть на страницу https://<community-domain>/001/o
Так же не может попасть на https://<community-domain>/<valid-account-id>
Делал ли кто-то такое, реально ли?
Спасибо.
Оверрайд делаешь и все. Ставишь туда свою страницу которая проверяет кому можно показывать а кому нет.
Права то у него должны быть на работу с аккаунтом?
Через UrlRewriter? Не уверен что он предоставляет такую возможность. Хотя я и не пробовал. Что скажете?
Аккаунт был взят для примера, а вообще будет немножко другие объекты открыты на create.
Через UrlRewriter? попробуй и отпишись
через override actions
А разве на закрытые таким образом страницы нельзя будет попасть через nooverride=1 (хотя не все рядовые пользователи про это знают)
Ну тогда сидишь и проверяешь арзитектуру, потому как редаетировать можно а видеть нельзя....это что-то не адекватное, как по мне.
Пользователю будет доступно около 3 объектов на создание, соответственно и на просмотр. Это не образовательно Аккаунты, это чисто для примера. Все остальные объекты системы будут закрыты. Таким образом, человек находясь на community может делать какие-то покупки, таким образом сохраняя записи в базе типа заказов. Но мне надо ограничить доступ: 1- к list view, потому что он спокойно может внести что вроде /001/o и попасть на список объектов. 2 - к object view, введя валидный ID.
Я что-то запутался. Пользователю нельзя видеть записи которые он же сам и создал?
Ему нельзя заходить на стандартные view и list view этого объекта, видеть он если и будет то только с кастомной страницы.
Ему нельзя заходить на стандартные view и list view этого объекта, видеть он если и будет то только с кастомной страницы.
очень странный бизнесс кейс
