Re: [GSoC] Revamping validation framework and merging django-secure once again

[Christopher Medrela]

I've written four more tests. I've moved some of checks out of `__init__`
methods. I've changed `tag` to `register`. I've rebased against master. I've
improved documentation (added sections about filtering and silencing system
checks), but I'm still polishing it. Code is ready for final review except 
for
the issues I will mention in this post.

We probably cannot move checks of `primary_key` and `unique` living in
`FileField.__init__`. We test if one of these two parameters was passed; we
don't check their values. Consider that an user passes unique=False. This is
the default value, but nevertheless, this should result in an error. We
cannot check if the attributes where passed while performing system checks. 
I'm
not sure if I make myself clear.

We must reject fk/m2m to neither a model nor model name in `__init__`. Some
pieces of code (i.e. `RelatedField.contibute_to_class`) assume that
`self.to` is a Model or a string.

4. More important changes in code:
>> - Introduced RAW_SETTINGS_MODULE [1]. I use it in compatibility checks to 
>> test
>>   if `TEST_RUNNER` setting was overriden [2].
>
>  

Have a look at the internals of the diffsettings management command -- I'm 
> not sure RAW_SETTINGS_MODULE is needed.


The problem is that when a test is decorated by `override_settings`, we need
to test `settings._wrapped._wrapped`, otherwise we need to check
`settings._wrapped`.

2. I'm afraid that there is too little time to merge django-secure. 
>> September 16 is
>> suggested 'pencils down' date, so there are only less than two weeks (12 
>> days) +
>> one buffer week, because firm 'pencils down' date is September 23. Merging
>> django-secure in such little time is actually impossible -- we must 
>> through out
>> this task from schedule. I really apologize for that.
>
>  

This is obviously disappointing, but it's better to deliver something 
> complete than a half-attempt. If we can get the core framework into a good 
> state, merging django-secure is a self-contained task that we can address 
> as a follow-up commit.
>
 

Also -- the GSoC will come to an end, but that doesn't mean your 
> contributions to Django have to… :-)


Sure. However, after merging I would like to focus on other kinds of
contributing like reviewing tickets, replying on mailing list and so on) --
it's easy to get bored if you do the same job all the time.

- Introduced `BaseAppCache.get_models_from_apps` method [3]. This method 
>> returns
>>   all models of given set of apps (or of all apps if None is passed) and 
>> is used
>>   in `default_checks.py` [4].
>
>  

I'm not sure I follow why this is needed -- or why it isn't just 
> duplicating functionality from loading.get_models()?
>
 
`get_models(app=someapp)` let you get all models from *one* app. I notice 
that I
sometimes need to get all models from a *set* of apps.

I've just noticed that we need to implement `__str__` method for ModelAdmin
*class* (not its instances) so errors involving ModelAdmins are printed
correctly. I will work at that.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6 release timeline

[Aymeric Augustin]

2013/9/11 

> Do you have an update on the schedule for the the Final? I guess it would
> be any week now, but I have some internal factors that require me to ask
> for your updated forecast.
>

Hi Tony,

Since we released 1.6 beta 3 yesterday, the next step is to release 1.6 RC
1. We haven't chosen a date yet, but I would guess next week.

At that point, we'll have to wait two weeks for the translators to take
into account new translated strings. Hopefully, after three betas, we won't
have a RC 2. This puts 1.6 final in the first days of October.

As usual, take this estimate with a grain of salt. To my great
embarrassment, we're very bad at following a release schedule, and security
issues can get in the way.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6 release timeline

[tony]

Tim,

Do you have an update on the schedule for the the Final? I guess it would 
be any week now, but I have some internal factors that require me to ask 
for your updated forecast.

Thanks,

Tony

On Friday, August 16, 2013 7:14:48 AM UTC-7, Tim Graham wrote:
>
> Obviously, we've missed our target for the release candidate. We're 
> currently targeting the week of August 26 for that, pending no new release 
> blockers.
>
> You can help us make our goal by triaging unreviewed 
> tickets.
>  
> Thanks!
>
> On Thursday, May 2, 2013 9:41:46 AM UTC-4, Jacob Kaplan-Moss wrote:
>>
>> On Thu, May 2, 2013 at 4:42 AM, Aymeric Augustin 
>>  wrote: 
>> > Shouldn't we push the alpha to May 23rd, all the more since we plan to 
>> fork 
>> > the stable/1.6.x branch at the beta? 
>>
>> That sounds reasonable; give us a chance to get any work done at 
>> DjangoCon Europe into the tree before we roll the alpha. 
>>
>> So, revised schedule: 
>>
>> Alpha: May 23 
>> Beta: June 27 
>> RC: Aug 8 
>> Final: as early as Aug 15, or later if more RCs are needed. 
>>
>> (Same as the original, just plus an extra week). 
>>
>> Jacob 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Allowing custom attributes in Meta classes

[Tim Chase]

On 2013-09-10 21:05, Russell Keith-Magee wrote:
> So - I think custom Meta options are something that should be
> *possible*. I don't have any particular ideas for how it should be
> implemented, though.

One of the areas I've considered trying this is annotating "private"
information about models.  The models' Manager class(es) could then
grow methods taking context (such as user information, remote IP,
HTTPS status, etc) and return models that have been sanitized based on
what that context permits ("Joe is a manager on-site, so can see the
full credit-card number and social security number", "Pat is a
non-manager employee visiting from on-site, so can only see the last
4 digits of the credit card number & social", "Ellen is an off-site
user and can only see the last 4 digits of her own credit-card &
social but nobody else's").

For implementation, I'd expect to namespace based on the name of the
app implementing the functionality, so you'd have something like

class MyModel(Model):
  class Meta:
...
class MyApp:
  secure_fields = ["cc_num", "ssn"]

The indentation might get just a little unwieldy, but namespacing
helps prevent clashes and sensibly be accessible just by chaining
properties:

  secure_fields = existing_meta.MyApp.secure_fields

My $0.02

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [contrib][admin]: Grouping actions

[Stan]

On Friday, September 6, 2013 10:11:18 PM UTC+2, German Larrain wrote:
>
> Hi Stan.
>
> I'm currently looking for "admin-related" features that seemed to be kind 
> of accepted by the core developers.
>
> What's the status of your proposal for grouping actions?
>

Hi Germán,

The status is "I should spend some time on it" :-)

Cheers,
 

>
> Best regards,
> Germán Larraín
>
> On Thursday, March 28, 2013 8:51:10 AM UTC-5, Stan wrote:
>>
>>
>>
>> On Thursday, March 28, 2013 1:50:36 PM UTC+1, Aymeric Augustin wrote:
>>>
>>>
>>> On 28 mars 2013, at 12:21, Stan  wrote: 
>>>
>>> > Do you guys think it worth the effort to backport the functionality 
>>> into admin ? 
>>>
>>>
>>> Hi Stan, 
>>>
>>> I like this idea. 
>>>
>>> In terms of API, is there a particular reason why you chose to add an 
>>> attribute to the actions themselves? I'd prefer to support a nested 
>>> structure for ModelAdmin.actions, because it gives control on order of the 
>>> groups and if feels more natural 
>>
>>
>> Agreed. The first implementation was a nested tuple/list:
>>
>> ( 
>>   ('group 1', ['actionA', 'actionB', ...]),
>>   ('group 2', ['actionX', 'actionY', ...]),
>> )
>>  
>> But it wasn't DRY enough because I had to maintain 2 structures of 
>> actions (in the admin and in the front-end logic).
>> So I add that attribute - which is harmless - and process the 
>> ModelAdmin.actions in the front-end.
>>
>> Anyway,
>>
>> The nested structure is certainly better option (with a fallback on the 
>> simple list we are used to.)
>>
>> ---
>> Stanislas
>>
>>
>>
>>
>> — there's less action at a distance. 
>>>
>>> -- 
>>> Aymeric. 
>>>
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.