Interestingly, I am thinking on something similar too - having a
report/notifications/actions view that have an auto generated URL. The
idea (on my concept) is that by getting this unique URL via email, a
user can access the report/action without needing to actually login -
the fact that a user accesses the url is authenticaton - it could
optionally require a password, since the userid is effectively part of
the URL
My thoughts :
Either a specific
A Notification/Report Model where one of the fields will be the
unique URL id
An incoming URL with the right path would search for the
notification model with the extracted URL id
My views would search my models for the incoming Id, and
confirm expected users, permissions etc.
I would only have one view that needs this so my specific
solution would be highly specific
Or a generic solution
A model for URLs and that model can have a one to one or one to one
to many relationship with other models; clearly this relationship is
dynamic so - I see this :
In the Model :
from hrefgeneric.models import HRefModel
class Notification(models.Model)
href = models.OneToOne(HRefModel, ...)
...
In the views
from hrefgeneric.views import HRefRequiredMixin
class NotificationView(HRefRequiredMixin, View):
class HREFRequired:
login_url = '/login/'
redirect_field_name='redirect_to'
user_name_field = 'username'
def get(self, HRef):
# HRef is now the HRef instance relevant to the
incoming request (not just any text extracted from the URL
pass
def post(self, HRef):
# HRef is now the HRef instance relevant to the
incoming request (not just any text extracted from the URL
pass
If login_url is set to anything truthy, then the mixin will enforce
some form of authentication form, with 'user_name_field' set to the
expected user name of the HRef (assuming the expected user on the
HRef is not None).
For the generic solution it would be great if there a decorator for
non class based views which does something similar.
The HRef instance needs the following fields
field_name = <field_name> # The name of any URL field that
this HREF should be matched on
field_value = <value> # The value that the above field
should have for this HREF
user = <The expected user> # The user that is allowed to
access this HREF - can be None
group = <permission group> # The permission Group that the
user - can be None
permission = <Permissions> # One or more permissions that
the user - can be None
On creation, field_name & field_value must be set
Example:
a pattern like this :
path('/notification/<id>', my_view)
and a href instance :
HRef(field_name='id', field_value='aabbccddeeff')
would match against an incoming path of
http://host/notification/aabbccddeeff
It might be that we need to match multiple fields on a url - not
sure how we do this.
I would happily contribute to an Django appropriate plugin etc - it
seems like there is a lot of commonality between the use cases.
--
Anthony Flury
email : *anthony.fl...@btinternet.com*
Twitter : *@TonyFlury <https://twitter.com/TonyFlury/>*
On 25/04/18 09:30, guettli wrote:
Thank Adrien for sharing your knowledge.
Our use cases have some parts that are common and some
parts that are distinct.
You want actions, I want static attributes.
You define them on the model.
I use URLs. In my case sometimes there is a 1:1 relationship between
URL and model,
but sometimes not.
In my use case I have reports. I want a report to have a preview html
snippet.
There are N reports (N URLs) for one model.
But I think there are more common things than distinct things.
One URL can have N attributes.
Some are actions, some static ones.
Where these attributes come from is a different topic.
If the URL represents a model, the attributes (in your case
"actions") of the model
can be propagated up to the URL.
I hope you undestand what I wrote. If not, then tell me.
Up to now these are just basic thoughts. I won't do any coding
during the next days. If someone likes this idea and implements it,
please let me know. I am always curious.
Regards,
Thomas
Am Montag, 23. April 2018 12:22:32 UTC+2 schrieb Adrien Cossa:
Hi,
On 04/23/2018 10:59 AM, guettli wrote:
I have a vague idea to use OOP for a hyperlink.
A hyperlink has these attributes for me:
- href
- verbose name
- Permission: Is the current user allowed to follow the link?
- Preview (on-mouse-over tooltip)
We have developed something similar in the company I work for. The
use case is not exactly the same as yours, but we end up with some
"Action" object that are similar to your "Hyperlink".
We have a mechanism based on mixins to define actions on our
models, for example let's say "create child node". Now each action
has some attributes telling what to display (e.g. "Create new
child node") and what should happen when we click on it (e.g. POST
to an URL). Now the interesting part is that we can also define
some restrictions for every action (e.g. "forbid if user is not
part of the manager group, or if a child already exist for the
current object, or ... etc") and we have a serializer mixin that
would automatically embed our actions information when serializing
the model object.
It is then the frontend's job to display whatever you like
(description or restriction) when the mouse is over, and to make
the link clickable or not. If the user tries to trick us with a
manual request, we will not allow the action because the view /
model method execution is protected with the same restriction set.
That is to say, after having defined a list of actions in a model
field, and a list of restriction for each action, we have a fully
working action description and restriction mechanism to manipulate
our objects. It looks a bit like this:
class X(ModelWithActionsMixin, Model):
actions = [ Action(id="create_child", ...,
restrictions=[Restriction(...), ...], ]
@protect(action_id="create")
def add_child(self):
...
or if you want to check the restrictions directly in your view
instead of protecting the method:
class NodeCreateView(...):
def post(self, ...):
obj = self.get_object()
try:
protect_action(obj, "add_child")
except ProtectedActionError as e:
raise Error400(...)
else:
obj.add_child()
Maybe you can use some similar mechanism for your implementation?
PS: we are willing to make a proper package for our stuff and the
idea behind would be to release it as free module, but I can't
tell if that will really happen or when... but to see that you
need something similar will probably push us :-)
I like Django because it handles the "href" part very smart (via
reverse()).
My current use case is the preview tooltip.
The app I develop has roughly ten different report types.
I can't remember the name, but I can remember how the report
looked like.
I recall the shape and colors of the report.
That's why I would like to have a on-mouse-over tooltip for the
hyperlink.
For example look at these chart types:
https://developers.google.com/chart/interactive/docs/gallery
<https://developers.google.com/chart/interactive/docs/gallery>
The tooltip should show a small version of the report/chart if I
move the mouse over the hyperlink.
I don't want to automate the creation of the preview images. It
is enough if I am able to attach a small HTML snippet to
each Django-URL. This HTML snippet should be used for the preview
tooltip.
What do you think?
Regards,
Thomas
--
You received this message because you are subscribed to the
Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to django-users...@googlegroups.com <javascript:>.
To post to this group, send email to django...@googlegroups.com
<javascript:>.
Visit this group at https://groups.google.com/group/django-users
<https://groups.google.com/group/django-users>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/c1df4a33-d077-42c4-8fd0-94902b4fad69%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/c1df4a33-d077-42c4-8fd0-94902b4fad69%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/082da970-b691-45ae-b546-50a3515bbd76%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/082da970-b691-45ae-b546-50a3515bbd76%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
--
Anthony Flury
email : *anthony.fl...@btinternet.com*
Twitter : *@TonyFlury <https://twitter.com/TonyFlury/>*
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/4e7e2872-96c7-463f-4513-1cd2abf5fbcb%40btinternet.com.
For more options, visit https://groups.google.com/d/optout.
