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 : *[email protected] <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 [email protected] <javascript:>.
> >> To post to this group, send email to [email protected]
> >> <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 [email protected] <javascript:>
> > <mailto:[email protected] <javascript:>>.
> > To post to this group, send email to [email protected]
> <javascript:>
> > <mailto:[email protected] <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 : *[email protected] <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 [email protected].
To post to this group, send email to [email protected].
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.
