I would like to keep both things separated:
- Attributes for URLs
- Access without login
What do you think?
Regards,
Thomas
Am Mittwoch, 25. April 2018 14:04:22 UTC+2 schrieb TonyF-UK:
>
> 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 : *anthon...@btinternet.com <javascript:>*
> 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...@googlegroups.com <javascript:>
> > <mailto:django-users+unsubscr...@googlegroups.com <javascript:>>.
> > To post to this group, send email to django...@googlegroups.com
> <javascript:>
> > <mailto:django...@googlegroups.com <javascript:>>.
> > 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 : *anthon...@btinternet.com <javascript:>*
> 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/11ede0d7-3039-4242-9514-dee8d7a197dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
