Customizing dynamically the edit_handler depending of the type of user
My app have some models that can be edited with modelAdmin. Is it possible that some fieldpanels are hidden to some types of users?
I can't find in the docs how to modify dynamically the edit_handler depending of the type of user.
wagtail modeladmin
add a comment |
My app have some models that can be edited with modelAdmin. Is it possible that some fieldpanels are hidden to some types of users?
I can't find in the docs how to modify dynamically the edit_handler depending of the type of user.
wagtail modeladmin
add a comment |
My app have some models that can be edited with modelAdmin. Is it possible that some fieldpanels are hidden to some types of users?
I can't find in the docs how to modify dynamically the edit_handler depending of the type of user.
wagtail modeladmin
My app have some models that can be edited with modelAdmin. Is it possible that some fieldpanels are hidden to some types of users?
I can't find in the docs how to modify dynamically the edit_handler depending of the type of user.
wagtail modeladmin
wagtail modeladmin
asked Nov 15 '18 at 15:27
Luis Miguel MorillasLuis Miguel Morillas
407
407
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
You can sub-class FieldPanel
and override the render_as_field
and/or render_as_object
methods. Within those methods you will have access to the request, which is bound to the model in bind_to_instance
(see https://github.com/wagtail/wagtail/blob/master/wagtail/admin/edit_handlers.py#L137).
Here's an example:
from wagtail.admin.edit_handlers import FieldPanel
class CustomFieldPanel(FieldPanel):
def render_as_field(self):
if not self.request.user.is_superuser:
return ''
return super().render_as_field()
add a comment |
There is an another way which I found recently (also faced with this problem).
If you don't need to hide panel but only make it read-only, you can just create let's say NewFieldPanel
inherited from base FieldPanel
and override bind_to_instance
method (originally found the tip here).
The example of implementation:
class NewFieldPanel(FieldPanel):
def bind_to_instance(self, instance=None, form=None, request=None):
# form.fields['managers'].widget = HiddenInput()
form.fields['managers'].disabled = True
return super().bind_to_instance(
instance=instance, form=form, request=request
)
add a comment |
... now, if it were me, I would probably opt to set up two entirely different panels, even though they would be maintained together and would look the same. Because, "sooner or sooner," one view will diverge from the other, and this can add complexity very quickly. Therefore, appealing though it may be to approach this problem by "selectively hiding things," you might come to wish that you hadn't done it this way. I think it's better to have two redundant panels, with a clean implementation for each, than to have two pieces of code that become littered with if
-statements ... but that is strictly my opinion.
I'm pretty sure OP is asking how to selectively modify whether or not a FieldPanel is displayed/how a FieldPanel behaves based on some attributes of the user. In this case it doesn't make sense to create different panels, but rather one FieldPanel that responds to attributes of the logged in user (viarequest.user
).
– inostia
Nov 23 '18 at 9:42
add a comment |
In addition to the answer above (can't add comment to it sorry).
Instead of render_as_field
sometimes you should use render_as_object
. It depends.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322697%2fcustomizing-dynamically-the-edit-handler-depending-of-the-type-of-user%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can sub-class FieldPanel
and override the render_as_field
and/or render_as_object
methods. Within those methods you will have access to the request, which is bound to the model in bind_to_instance
(see https://github.com/wagtail/wagtail/blob/master/wagtail/admin/edit_handlers.py#L137).
Here's an example:
from wagtail.admin.edit_handlers import FieldPanel
class CustomFieldPanel(FieldPanel):
def render_as_field(self):
if not self.request.user.is_superuser:
return ''
return super().render_as_field()
add a comment |
You can sub-class FieldPanel
and override the render_as_field
and/or render_as_object
methods. Within those methods you will have access to the request, which is bound to the model in bind_to_instance
(see https://github.com/wagtail/wagtail/blob/master/wagtail/admin/edit_handlers.py#L137).
Here's an example:
from wagtail.admin.edit_handlers import FieldPanel
class CustomFieldPanel(FieldPanel):
def render_as_field(self):
if not self.request.user.is_superuser:
return ''
return super().render_as_field()
add a comment |
You can sub-class FieldPanel
and override the render_as_field
and/or render_as_object
methods. Within those methods you will have access to the request, which is bound to the model in bind_to_instance
(see https://github.com/wagtail/wagtail/blob/master/wagtail/admin/edit_handlers.py#L137).
Here's an example:
from wagtail.admin.edit_handlers import FieldPanel
class CustomFieldPanel(FieldPanel):
def render_as_field(self):
if not self.request.user.is_superuser:
return ''
return super().render_as_field()
You can sub-class FieldPanel
and override the render_as_field
and/or render_as_object
methods. Within those methods you will have access to the request, which is bound to the model in bind_to_instance
(see https://github.com/wagtail/wagtail/blob/master/wagtail/admin/edit_handlers.py#L137).
Here's an example:
from wagtail.admin.edit_handlers import FieldPanel
class CustomFieldPanel(FieldPanel):
def render_as_field(self):
if not self.request.user.is_superuser:
return ''
return super().render_as_field()
edited Nov 20 '18 at 19:34
answered Nov 19 '18 at 18:21
inostiainostia
2,91111522
2,91111522
add a comment |
add a comment |
There is an another way which I found recently (also faced with this problem).
If you don't need to hide panel but only make it read-only, you can just create let's say NewFieldPanel
inherited from base FieldPanel
and override bind_to_instance
method (originally found the tip here).
The example of implementation:
class NewFieldPanel(FieldPanel):
def bind_to_instance(self, instance=None, form=None, request=None):
# form.fields['managers'].widget = HiddenInput()
form.fields['managers'].disabled = True
return super().bind_to_instance(
instance=instance, form=form, request=request
)
add a comment |
There is an another way which I found recently (also faced with this problem).
If you don't need to hide panel but only make it read-only, you can just create let's say NewFieldPanel
inherited from base FieldPanel
and override bind_to_instance
method (originally found the tip here).
The example of implementation:
class NewFieldPanel(FieldPanel):
def bind_to_instance(self, instance=None, form=None, request=None):
# form.fields['managers'].widget = HiddenInput()
form.fields['managers'].disabled = True
return super().bind_to_instance(
instance=instance, form=form, request=request
)
add a comment |
There is an another way which I found recently (also faced with this problem).
If you don't need to hide panel but only make it read-only, you can just create let's say NewFieldPanel
inherited from base FieldPanel
and override bind_to_instance
method (originally found the tip here).
The example of implementation:
class NewFieldPanel(FieldPanel):
def bind_to_instance(self, instance=None, form=None, request=None):
# form.fields['managers'].widget = HiddenInput()
form.fields['managers'].disabled = True
return super().bind_to_instance(
instance=instance, form=form, request=request
)
There is an another way which I found recently (also faced with this problem).
If you don't need to hide panel but only make it read-only, you can just create let's say NewFieldPanel
inherited from base FieldPanel
and override bind_to_instance
method (originally found the tip here).
The example of implementation:
class NewFieldPanel(FieldPanel):
def bind_to_instance(self, instance=None, form=None, request=None):
# form.fields['managers'].widget = HiddenInput()
form.fields['managers'].disabled = True
return super().bind_to_instance(
instance=instance, form=form, request=request
)
answered Nov 21 '18 at 23:07
Dzmitry MakhrachouDzmitry Makhrachou
1
1
add a comment |
add a comment |
... now, if it were me, I would probably opt to set up two entirely different panels, even though they would be maintained together and would look the same. Because, "sooner or sooner," one view will diverge from the other, and this can add complexity very quickly. Therefore, appealing though it may be to approach this problem by "selectively hiding things," you might come to wish that you hadn't done it this way. I think it's better to have two redundant panels, with a clean implementation for each, than to have two pieces of code that become littered with if
-statements ... but that is strictly my opinion.
I'm pretty sure OP is asking how to selectively modify whether or not a FieldPanel is displayed/how a FieldPanel behaves based on some attributes of the user. In this case it doesn't make sense to create different panels, but rather one FieldPanel that responds to attributes of the logged in user (viarequest.user
).
– inostia
Nov 23 '18 at 9:42
add a comment |
... now, if it were me, I would probably opt to set up two entirely different panels, even though they would be maintained together and would look the same. Because, "sooner or sooner," one view will diverge from the other, and this can add complexity very quickly. Therefore, appealing though it may be to approach this problem by "selectively hiding things," you might come to wish that you hadn't done it this way. I think it's better to have two redundant panels, with a clean implementation for each, than to have two pieces of code that become littered with if
-statements ... but that is strictly my opinion.
I'm pretty sure OP is asking how to selectively modify whether or not a FieldPanel is displayed/how a FieldPanel behaves based on some attributes of the user. In this case it doesn't make sense to create different panels, but rather one FieldPanel that responds to attributes of the logged in user (viarequest.user
).
– inostia
Nov 23 '18 at 9:42
add a comment |
... now, if it were me, I would probably opt to set up two entirely different panels, even though they would be maintained together and would look the same. Because, "sooner or sooner," one view will diverge from the other, and this can add complexity very quickly. Therefore, appealing though it may be to approach this problem by "selectively hiding things," you might come to wish that you hadn't done it this way. I think it's better to have two redundant panels, with a clean implementation for each, than to have two pieces of code that become littered with if
-statements ... but that is strictly my opinion.
... now, if it were me, I would probably opt to set up two entirely different panels, even though they would be maintained together and would look the same. Because, "sooner or sooner," one view will diverge from the other, and this can add complexity very quickly. Therefore, appealing though it may be to approach this problem by "selectively hiding things," you might come to wish that you hadn't done it this way. I think it's better to have two redundant panels, with a clean implementation for each, than to have two pieces of code that become littered with if
-statements ... but that is strictly my opinion.
answered Nov 22 '18 at 16:19
Mike RobinsonMike Robinson
4,03021021
4,03021021
I'm pretty sure OP is asking how to selectively modify whether or not a FieldPanel is displayed/how a FieldPanel behaves based on some attributes of the user. In this case it doesn't make sense to create different panels, but rather one FieldPanel that responds to attributes of the logged in user (viarequest.user
).
– inostia
Nov 23 '18 at 9:42
add a comment |
I'm pretty sure OP is asking how to selectively modify whether or not a FieldPanel is displayed/how a FieldPanel behaves based on some attributes of the user. In this case it doesn't make sense to create different panels, but rather one FieldPanel that responds to attributes of the logged in user (viarequest.user
).
– inostia
Nov 23 '18 at 9:42
I'm pretty sure OP is asking how to selectively modify whether or not a FieldPanel is displayed/how a FieldPanel behaves based on some attributes of the user. In this case it doesn't make sense to create different panels, but rather one FieldPanel that responds to attributes of the logged in user (via
request.user
).– inostia
Nov 23 '18 at 9:42
I'm pretty sure OP is asking how to selectively modify whether or not a FieldPanel is displayed/how a FieldPanel behaves based on some attributes of the user. In this case it doesn't make sense to create different panels, but rather one FieldPanel that responds to attributes of the logged in user (via
request.user
).– inostia
Nov 23 '18 at 9:42
add a comment |
In addition to the answer above (can't add comment to it sorry).
Instead of render_as_field
sometimes you should use render_as_object
. It depends.
add a comment |
In addition to the answer above (can't add comment to it sorry).
Instead of render_as_field
sometimes you should use render_as_object
. It depends.
add a comment |
In addition to the answer above (can't add comment to it sorry).
Instead of render_as_field
sometimes you should use render_as_object
. It depends.
In addition to the answer above (can't add comment to it sorry).
Instead of render_as_field
sometimes you should use render_as_object
. It depends.
answered Nov 24 '18 at 15:18
Dzmitry MakhrachouDzmitry Makhrachou
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322697%2fcustomizing-dynamically-the-edit-handler-depending-of-the-type-of-user%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown