+1 on removing it only as part of a larger admin improve/overhaul move.
Is there a place where plans and ideas for such a move are discussed /
aggregated? Is there any current work being done in that direction?
On Mon, 23 May 2011 21:45:23 +0300, Idan Gazit wrote:
I agree that it's redundan
@dmoisset has in my opinion proposed the best solution. Remove the link
(without a setting) and give the ability to add it back if anyone really
need it.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On Tue, May 24, 2011 at 3:48 AM, Anshuman Aggarwal
wrote:
> Luke,
> I completely agree on the need for change and personally +1 this as
> it is a completely confusing historical annoyance.
>
> However, as in all deprecation, I would suggest that we start with a
> global setting that allows these
On Tuesday, May 24, 2011 9:48:43 AM UTC+3, Anshuman Aggarwal wrote:
>
> However, as in all deprecation, I would suggest that we start with a
> global setting that allows these links to be hidden on an installation
> by installation basis and the default made to true for now.
>
-1, if only bec
Luke,
I completely agree on the need for change and personally +1 this as
it is a completely confusing historical annoyance.
However, as in all deprecation, I would suggest that we start with a
global setting that allows these links to be hidden on an installation
by installation basis and the de
On 23/05/11 19:45, Idan Gazit wrote:
> I agree that it's redundant and unnecessary, but absent a particular
> *need* to remove it, I'd say leave it until the admin gets an overall
> refresh.
>
> While having two links may be marginally confusing for new users,
> _removing_ an existing bit of funct
I agree that it's redundant and unnecessary, but absent a particular *need*
to remove it, I'd say leave it until the admin gets an overall refresh.
While having two links may be marginally confusing for new users, _removing_
an existing bit of functionality is akin to a breaking change, IMO. It'
On Mon, May 23, 2011 at 6:52 PM, Luke Plant wrote:
> On 23/05/11 16:18, Mateusz Marzantowicz wrote:
>
> > Is there any reason to keep this column? Can I remove it?
> >
> >
> > Yes, you can. It''s how Open Source works. You get the source code and
> > do with it what you want. Django is very m
On 23/05/11 16:18, Mateusz Marzantowicz wrote:
> Is there any reason to keep this column? Can I remove it?
>
>
> Yes, you can. It''s how Open Source works. You get the source code and
> do with it what you want. Django is very modular and easy to change. You
> can override admin template bas
On Mon, May 23, 2011 at 12:54 PM, Luke Plant wrote:
>
> Is there any reason to keep this column? Can I remove it?
>
>
Yes, you can. It''s how Open Source works. You get the source code and do
with it what you want. Django is very modular and easy to change. You can
override admin template based o
On Mon, May 23, 2011 at 6:54 AM, Luke Plant wrote:
> Is there any reason to keep this column? Can I remove it?
I don't really see the point of removing it. Generally index pages are not
pressed for space. People may be more used to using the Change links than
the links on the left, removing th
On Mon, May 23, 2011 at 1:54 PM, Luke Plant wrote:
> On the admin index page, you've got things like this:
>
> == Auth ==
> Groups | Add | Change
> Users| Add | Change
>
> The 'Change' links are completely redundant - they take you to the same
> places as the links in the first column
On the admin index page, you've got things like this:
== Auth ==
Groups | Add | Change
Users| Add | Change
The 'Change' links are completely redundant - they take you to the same
places as the links in the first column (e.g. Groups/Users). This is bad
because:
1) They're confusing -
13 matches
Mail list logo
