Re: pass list parameter from one class view to another
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django itself, rather
than in your code using it. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/
For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .
Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.
Thanks for your understanding,
Adam
On Tue, 5 Nov 2019 at 00:52, sotiris moustogiannis
wrote:
> I have this listview and the context['datetimelist'] which is a list into
> def get_context_data
>
> class ShopListView(ListView):
> model = Shops
> context_object_name= 'shops'
>
> template_name = 'booking/search.html'
>
> def get_context_data(self, **kwargs):
> context = super(ShopListView, self).get_context_data(**kwargs)
> query = self.request.GET.get('q')
> query1 = self.request.GET.get('q1')
> query2 = self.request.GET.get('q2')
> query3 = self.request.GET.get('q3')
> context['datetimelist'] = [query,query1,query2,query3]
> return context
>
>
> def get_queryset(self):
> query = self.request.GET.get('q')
> query1 = self.request.GET.get('q1')
> query2 = self.request.GET.get('q2')
> query3 = self.request.GET.get('q3')
> result_list = Shops.objects.exclude(Q(appointments__time=query
> ) & Q(appointments__date = query1))
> result_list2 = Shops.objects.filter(Q(city=query2) & Q(
> typesport=query3))
> context = list(chain(result_list & result_list2))
> return context
>
>
>
> And i want to pass this list to ShopDetailView class based view
>
>
> class ShopDetailView(DetailView):
>
> model = Shops
>
> template_name = 'booking/results.html'
>
>
> context_object_name= 'shops'
>
>
>
> Also, here are my urls that calls these classes
>
> path('search/', booking_views.ShopListView.as_view(template_name=
> 'booking/search.html'), name='search'),
> path('results//', booking_views.ShopDetailView.as_view(
> template_name='booking/results.html'), name='results'),
>
>
> How can i pass this list from one class based view to the other
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3268ec4e-accf-49df-8578-aab18c69ce30%40googlegroups.com
>
> .
>
--
Adam
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM2PAi7OhF%3DiyXvXDHn3MKsLEgSgKXjUuoczrUnYit4e3Q%40mail.gmail.com.
Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend
I'd be very interested in this. But it seems like one helluva lot of work,
to enable people to customise their Group model.
I think in general, there are two reasons why one want to use a swappable
model in this case:
- To create nested relationships with e.g. mptt.
- To add a field or two onto the model.
Couldn't these two use cases be better solved by simply updating the
existing Group model:
- Add a `meta` JSONField (now generically included in Django, not just
postgres anymore) so people can hang extra metadata in there if required
- Add mptt right in there so that groups can be added to other groups?
We could carve code out from django-groups-manager to achive this
straightforwardly, but it introduces mptt as a dependency of a contrib app.
What do you think, @John? Is this likely to be accepted into Django?
On Wednesday, April 3, 2019 at 12:31:59 PM UTC+1, John D'Ambrosio wrote:
>
> I believe this change is merited and I would be happy to help if others
> are interested in working this. I have actually monkey-patched it a few
> times now for two reasons:
>
> a) I want more data fields on the group itself, or
> b) I want to implement nested groups
>
> MPTT's docs suggest one approach which is gross (no offense) because it
> creates migrations in a contrib app!
>
>
> https://django-mptt.readthedocs.io/en/latest/models.html?highlight=group#registration-of-existing-models
>
> The nested group concept has the added concern of the PermissionsMixin
> leveraging a few helper functions which are defined outside of the class
> and not easily swappable themselves. Maybe if we proceed on this we tackle
> it in two phases. In the first, we can align all of the pieces to make it
> more easily swappable. In the second, we can introduce the swap. We
> definitely will want to avoid some of the pitfalls of AbstractUser and
> UserManager where one is unable to import varying degrees of scaffolding
> without invoking the concrete pieces we are not using.
>
> I agree with Tim that the swappable model approach is less than ideal and
> not well-documented for transitions, but maybe those of us who've done it
> can submit some detailed guides with some concrete steps of how to swap out
> the table namespaces and retire the old models retroactively, as well as
> the usual (maybe even stronger) encouragement to pull in the models to your
> core app up-front? Could even have startproject do it for you in the
> future... maybe recommend an "accounts" app or something?
>
> Anyway, happy to help. Please let me know if there is interest in
> proceeding.
>
> On Friday, August 31, 2018 at 4:28:30 PM UTC-4, 程SN wrote:
>>
>> Hi everybody,
>>
>> the information is not enough for my company in
>> django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I
>> custom User and Team model.
>>
>> the auth User can be changed in the django settings by AUTH_USER_MODEL.
>> But the Group cannot.
>>
>> Further, There are many group permissions problem presented when I use
>> django permissions.
>>
>> Firstly, I cannot use django.contrib.auth.ModelBackend directly.
>>
>> in django.contrib.auth.ModelBackend, Django currently bind group
>> permissions with django.contrib.auth.models.Group
>>
>> def _get_group_permissions(self, user_obj):
>> user_groups_field = get_user_model()._meta.get_field('groups')
>> user_groups_query = 'group
>> __%s' % user_groups_field.related_query_name()
>> return Permission.objects.filter(**{user_groups_query: user_obj})
>>
>> Why the group cannot be changed in the settings like AUTH_USER_MODEL ?
>> Can Djano support AUTH_GROUP_MODEL in the further release?
>>
>> So I have to custom backend that extend django.contrib.auth.ModelBackend
>> and modify group to my team.
>>
>> But I find the other problem in my further developing. The bad design
>> limit the other app design.
>>
>> Many app about django permission , only support group permission based
>> on django.contrib.auth.models.Group, like django-guardian
>>
>> It's too bad. Please support AUTH_GROUP_MODEL
>>
>> --
>> Regards,
>>
>> damoncheng
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f308b198-28a5-423c-a7ae-cf6da87b9c74%40googlegroups.com.
New to Open Source Contribution Need Help With Setting Up Environment For Channels to Reproduce Issues After Cloning From Git
I have cloned channels repo in my local. I was going through the bugs but was unable to set-up the environment to reproduce the bugs. I have the following understanding: 1. Rather than `pip install channels` clone the channels from git 2. Execute the channels parallel to your application and make them talk and see the errors in application and logs in channels. I am unable to build and run the channels and configure it with a dummy Django app to reproduce the bugs. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ddd5f084-7797-471d-889f-456c83df8b28%40googlegroups.com.
Re: GitHub Actions
On Thursday, October 31, 2019 at 2:33:29 PM UTC+1, Florian Apolloner wrote: > > > > On Thursday, October 31, 2019 at 11:08:49 AM UTC+1, Tom Forbes wrote: >> >> 1. How do we support Oracle? >> > > For now we don't > Ui, seems like we can start using our own runners: https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/ -- seems like github actions is becoming more and more a jenkins replacement :D -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/38367308-099c-46a0-8575-d5fff387b26f%40googlegroups.com.
Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend
I also have experience with the limitations of the default permission
system. But I don't think it is necessarily a problem. There are two
options to deal with it:
- Django could add small bits of flexibility, e.g. make the group model
swappable. This adds complexity that needs to be accounted for in all
relevant libraries, e.g. django-guardian.
- Django could make it easier to write custom authentication backends.
This gives complete control to application developers, at the cost of no
longer being compatible with many libraries, e.g. django-guardian.
I personally lean to the second options as I believe it allows to have
cleaner application designs. But it think it is hard to get the right
balance.
tobias
On 05/11/2019 12:03, Tom Clark wrote:
> I'd be very interested in this. But it seems like one helluva lot of work,
> to enable people to customise their Group model.
>
> I think in general, there are two reasons why one want to use a swappable
> model in this case:
>
> - To create nested relationships with e.g. mptt.
> - To add a field or two onto the model.
>
> Couldn't these two use cases be better solved by simply updating the
> existing Group model:
> - Add a `meta` JSONField (now generically included in Django, not just
> postgres anymore) so people can hang extra metadata in there if required
> - Add mptt right in there so that groups can be added to other groups?
>
> We could carve code out from django-groups-manager to achive this
> straightforwardly, but it introduces mptt as a dependency of a contrib app.
>
> What do you think, @John? Is this likely to be accepted into Django?
>
>
>
>
> On Wednesday, April 3, 2019 at 12:31:59 PM UTC+1, John D'Ambrosio wrote:
>>
>> I believe this change is merited and I would be happy to help if others
>> are interested in working this. I have actually monkey-patched it a few
>> times now for two reasons:
>>
>> a) I want more data fields on the group itself, or
>> b) I want to implement nested groups
>>
>> MPTT's docs suggest one approach which is gross (no offense) because it
>> creates migrations in a contrib app!
>>
>>
>> https://django-mptt.readthedocs.io/en/latest/models.html?highlight=group#registration-of-existing-models
>>
>> The nested group concept has the added concern of the PermissionsMixin
>> leveraging a few helper functions which are defined outside of the class
>> and not easily swappable themselves. Maybe if we proceed on this we tackle
>> it in two phases. In the first, we can align all of the pieces to make it
>> more easily swappable. In the second, we can introduce the swap. We
>> definitely will want to avoid some of the pitfalls of AbstractUser and
>> UserManager where one is unable to import varying degrees of scaffolding
>> without invoking the concrete pieces we are not using.
>>
>> I agree with Tim that the swappable model approach is less than ideal and
>> not well-documented for transitions, but maybe those of us who've done it
>> can submit some detailed guides with some concrete steps of how to swap out
>> the table namespaces and retire the old models retroactively, as well as
>> the usual (maybe even stronger) encouragement to pull in the models to your
>> core app up-front? Could even have startproject do it for you in the
>> future... maybe recommend an "accounts" app or something?
>>
>> Anyway, happy to help. Please let me know if there is interest in
>> proceeding.
>>
>> On Friday, August 31, 2018 at 4:28:30 PM UTC-4, 程SN wrote:
>>>
>>> Hi everybody,
>>>
>>> the information is not enough for my company in
>>> django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I
>>> custom User and Team model.
>>>
>>> the auth User can be changed in the django settings by AUTH_USER_MODEL.
>>> But the Group cannot.
>>>
>>> Further, There are many group permissions problem presented when I use
>>> django permissions.
>>>
>>> Firstly, I cannot use django.contrib.auth.ModelBackend directly.
>>>
>>> in django.contrib.auth.ModelBackend, Django currently bind group
>>> permissions with django.contrib.auth.models.Group
>>>
>>> def _get_group_permissions(self, user_obj):
>>> user_groups_field = get_user_model()._meta.get_field('groups')
>>> user_groups_query = 'group
>>> __%s' % user_groups_field.related_query_name()
>>> return Permission.objects.filter(**{user_groups_query: user_obj})
>>>
>>> Why the group cannot be changed in the settings like AUTH_USER_MODEL ?
>>> Can Djano support AUTH_GROUP_MODEL in the further release?
>>>
>>> So I have to custom backend that extend django.contrib.auth.ModelBackend
>>> and modify group to my team.
>>>
>>> But I find the other problem in my further developing. The bad design
>>> limit the other app design.
>>>
>>> Many app about django permission , only support group permission based
>>> on django.contrib.auth.models.Group, like django-guardian
>>>
>>> It's too bad. Please support AUTH_GROUP_MODEL
>>>
Re: GitHub Actions
On Tue, 5 Nov 2019 13:35:24 -0800 (PST) Florian Apolloner wrote: > > Ui, seems like we can start using our own runners: > https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/ > > -- seems like github actions is becoming more and more a jenkins > replacement :D > Is there benefit enough in GitHub Actions (over Jenkins) to justify a move from an open-source based solution? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20191106094256.23e027f4.shai%40platonix.com.
