headers
Remy Blank | 1 May 10:00
Picon
Favicon

[Trac-dev] Re: Obtaining environment name from within a Trac genshi template file

>> doesn't "project.name" work?
> Nope, it evaluates to the project short description, not the
> environment name, i.e. value from
>   [project]
>   name = value
> in trac.ini

Then I think I didn't understand what you mean with "project name". Do
you mean the last directory in the path to the environment? For example,
if the environment is under /var/lib/trac/myenv, then the project name
would be "myenv"?

-- Remy
Permalink | Reply | 5 comments |
headers
Emmanuel Blot | 1 May 10:53
Picon
Gravatar

[Trac-dev] Re: Obtaining environment name from within a Trac genshi template file


> Then I think I didn't understand what you mean with "project name". Do
> you mean the last directory in the path to the environment? For example,
> if the environment is under /var/lib/trac/myenv, then the project name
> would be "myenv"?

Yes, that's right the environment name, not the project name.
"myenv" in your example.

Cheers,
Manu

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 4 comments |
headers
Remy Blank | 1 May 11:39
Picon
Favicon

[Trac-dev] Re: Obtaining environment name from within a Trac genshi template file

Emmanuel Blot wrote:
> Yes, that's right the environment name, not the project name.
> "myenv" in your example.

Ok, then no, I don't see how you could do it in the current state. Time
to add:

  project.dir = os.basename(self.env.path)

or possibly:

  project.path = self.env.path

in Chrome!

-- Remy
Permalink | Reply | 3 comments |
headers
osimons | 1 May 20:23
Picon

[Trac-dev] Re: Obtaining environment name from within a Trac genshi template file


On May 1, 11:39 am, Remy Blank <remy.bl...@pobox.com> wrote:
> Emmanuel Blot wrote:
> > Yes, that's right the environment name, not the project name.
> > "myenv" in your example.
>
> Ok, then no, I don't see how you could do it in the current state. Time
> to add:
>
>   project.dir = os.basename(self.env.path)
>
> or possibly:
>
>   project.path = self.env.path
>
> in Chrome!
>

My first question is to ask what you are actually trying to achieve -
ie. what could you need the disk folder name for?

The disk location can be read from req.environ, specifically either
req.environ['trac.env_parent_dir'] or req.environ['trac.env_path']
depending on your setup. If you run a parent setup then the project
folder name should be the last item of req.base_path (depending on how
you have mounted trac in your url).

But, again, why you need the disk folder name is still not clear to
me.... :-) However, I'd be fine with extending project dict with a
project.path - looks harmless, and simplifies the logic of looking it
(Continue reading)

Permalink | Reply | 2 comments |
headers
osimons | 1 May 20:31
Picon

[Trac-dev] Re: Adding stylesheet for mainnav bar


On Apr 29, 6:48 pm, Emmanuel Blot <manu.b...@gmail.com> wrote:
> What would be the cleanest way to add some stylesheet definitions:
>   * from a plugin (here: Bitten)
>   * for CSS definitions that change the appearance of the main navigation bar
>   * even when the request is not related to the plugin (i.e. whatever
> the request, the main navigation bar appearance should be consistent)

For styles needed in a plugin to render its own content, then use
add_stylesheet() in plugin request handling when needed.

For a general styling, implement IRequestFilter and use the
post_process_request method that is guaranteed to execute for all
requests - even error pages are run by here. Just check that it is
actually a template that is about to be rendered (no need to add it to
RSS feed rendering and similar). It is what I do for http://www.coderesort.com
styling.

:::simon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Emmanuel Blot | 1 May 20:47
Picon
Gravatar

[Trac-dev] Re: Obtaining environment name from within a Trac genshi template file


> My first question is to ask what you are actually trying to achieve -
> ie. what could you need the disk folder name for?

I have very several similar projects and I'd like to keep all the
stylesheet files within the same, statically served directory. As all
the projects use the same, inherited templates/site.html file, I'd
like to use something like
"style_${env.name}.css" stylesheet link within this template file.

the req.environ[] seems fine, I'll have a look.

Thanks,
Manu

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
Emmanuel Blot | 1 May 21:37
Picon
Gravatar

[Trac-dev] Re: Obtaining environment name from within a Trac genshi template file


> the req.environ[] seems fine, I'll have a look.
... works as expected !

Thanks a lot,
Manu

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
John Siirola | 3 May 07:21
Picon

[Trac-dev] Separate ticket attachment and comment permissions


Devs,

Is there a "simple" way to separate the permissions for commenting on a
ticket and for attaching files to a ticket?  Right now, TICKET_APPEND
grants both permissions.  What I want to do is to enable comments, but
disable ticket attachments for certain users (actually based on the
presence of a third permission).

I had hoped to do this through the ILegacyAttachmentPolicyDelegate, but
those delegates are not called for any parent realm that matches the
legacy defaults (ticket, wiki, and milestone).

My second shot is to create another IPermissionPolicy, and have the site
admin list it *before* the LegacyAttachmentPolicy in the list of
providers in trac.ini... but this seems rather inelegant.

At least to me, it raises the more general issue that when checking
permissions, the first provider to return true/false "wins": there isn't
an "easy" way to have a plugin that consistently denies a permission
that would otherwise returns "True" in a given context.

Thanks,
john

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
(Continue reading)

Permalink | Reply | 1 comment |
headers
osimons | 3 May 11:15
Picon

[Trac-dev] Re: Separate ticket attachment and comment permissions


On May 3, 7:21 am, John Siirola <jsiir...@gmail.com> wrote:
> My second shot is to create another IPermissionPolicy, and have the site
> admin list it *before* the LegacyAttachmentPolicy in the list of
> providers in trac.ini... but this seems rather inelegant.

That's how you need to do it according to current design - write your
own policy, and have it evaluated before any policies you want to
override.

:::simon

https://www.coderesort.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Remy Blank | 3 May 21:47
Picon
Favicon

[Trac-dev] trac.edgewall.org down?

t.e.o seems to have been down for most of today. svn.edgewall.org seems
to be ok, though.

Was this a planned maintenance, or has there been some breakage? Any
idea when it will be back up?

-- Remy
Permalink | Reply | 3 comments |

Gmane