A plugin idea

[Christopher Nelson]

Am I crazy or would it be useful to be able to embed the tabular
output of a report in a wiki page? I know there's [[TicketQuery()]]
but that lacks the power and flexibility of the SQL you can put in a
report specification. I imagine something like
[[EmbedReport(24,USER=chrisn)]] to embed the equivalent to
"https://trac.sixnetio.com/trac/report/59?USER=chrisn" in a wiki page.
I looked around Trac-Hacks and didn't find anything like it. Maybe I
looked to quickly.

Chris
--
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[Olemis Lang]

Hi !

On 9/27/12, Christopher Nelson <chris.ne...@gmail.com> wrote:
> Am I crazy or would it be useful to be able to embed the tabular
> output of a report in a wiki page?

You are not ... or maybe we both are
:P

> I know there's [[TicketQuery()]]
> but that lacks the power and flexibility of the SQL you can put in a
> report specification. I imagine something like
> [[EmbedReport(24,USER=chrisn)]] to embed the equivalent to
> "https://trac.sixnetio.com/trac/report/59?USER=chrisn" in a wiki page.
> I looked around Trac-Hacks and didn't find anything like it. Maybe I
> looked to quickly.
>

If u were using Bloodhound u could do that by using WidgetMacro [1]_
to render TicketReport widget . It will look something like this

[[Widget(TicketReport, id=6, page=3, user=olemis)]]

Below I paste parameter definitions for that widget . Notice that only
id argument is required .

{{{
#!py

def get_widget_params(self, name):
"""Return a dictionary containing arguments specification for
the widget with specified name.
"""
return {
'id' : {
'desc' : """Report number""",
'required' : True,
'type' : int,
},
'page' : {
'default' : 1,
'desc' : """Retrieve results in given page.""",
'type' : int,
},
'user' : {
'desc' : """Render the report for a given user.""",
},
}

}}}

I'm thinking this is not OT because , in the end , Bloodhound is Trac
1.0 ... and something more ... ;)

.. [1] #138 Widgets wiki macro
(https://issues.apache.org/bloodhound/ticket/138)

PS: BTW , WidgetMacro has not being commited yet onto ASF repository ,
but it will be there in source tarball for 0.2.0 ... hopefully coming
soon . So at the moment patch(es) submitted to that ticket and
screenshot is the best I can show you . Once it will be committed I'll
provide some examples to you if still interested on this subject .
;)

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27.09.2012 22:33, Olemis Lang wrote:
> On 9/27/12, Christopher Nelson <chris.ne...@gmail.com> wrote:
>> > Am I crazy or would it be useful to be able to embed the tabular
>> > output of a report in a wiki page?
> You are not ... or maybe we both are
> :P

No comments to your ability to read in trac-hacks.org hack listings, but
I see at least two likely candidates to check:

SqlQueryMacro

Execute an SQL Query against a configured database displaying a
formatted table of results.

WikiTableMacro

This is a simple macro that enables you to place tables resulting from
SQL queries into a wiki page.

It is similar to, but simpler than, SqlQueryMacro. The main differences
are that it has fewer dependencies and always queries the Trac database,
rather than letting you set up a separate data connection.

Bear with us and improve one of these instead of re-inventing the wheel,
please.

Steffen Hoffmann


[1] http://trac-hacks.org/wiki/SqlQueryMacro
[2] http://trac-hacks.org/wiki/WikiTableMacro

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBl4ZYACgkQ31DJeiZFuHd8swCfTtPYicQ2ZsYZl51skYVGJzKQ
cEIAoKzdt1vkzRXPmKTRBSFCHpc7p71/
=K3lJ
-----END PGP SIGNATURE-----

[Benjamin Lau]

I actually wrote something that does something related while
trac-hacks was down. I wanted to pull some structured content out of
some of my other pages and present them as a table. So I wrote:

https://github.com/netjunki/trac-RecentReleasesMacro

It's kind of targeted to the concept of software releases... but it
ended up being fairly generic in the end. Needs a bit of clean up to
make it easier to use/configure but it does the job I need it to at
the moment.

Ben

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

[Christopher Nelson]

> On 27.09.2012 22:33, Olemis Lang wrote:
>> On 9/27/12, Christopher Nelson <chris.ne...@gmail.com> wrote:
>>> > Am I crazy or would it be useful to be able to embed the tabular
>>> > output of a report in a wiki page?
>> You are not ... or maybe we both are
>> :P
>
> No comments to your ability to read in trac-hacks.org hack listings,

Oh, go ahead and comment. I looked at every line with "report" in it.
I didn't think to look for "SQL".

> but
> I see at least two likely candidates to check:
>
> SqlQueryMacro
>
> Execute an SQL Query against a configured database displaying a
> formatted table of results.
>
> WikiTableMacro
>
> This is a simple macro that enables you to place tables resulting from
> SQL queries into a wiki page.
>
> It is similar to, but simpler than, SqlQueryMacro. The main differences
> are that it has fewer dependencies and always queries the Trac database,
> rather than letting you set up a separate data connection.
>
> Bear with us and improve one of these instead of re-inventing the wheel,
> please.

I would find it most useful to be able to say [[EmbedReport(24)]] than
to copy the SQL from {24} to the macro but duplicating the SQL beats
writing a new plugin!

[Olemis Lang]

On 9/28/12, Steffen Hoffmann <hof...@web.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 27.09.2012 22:33, Olemis Lang wrote:
>> On 9/27/12, Christopher Nelson <chris.ne...@gmail.com> wrote:
>>> > Am I crazy or would it be useful to be able to embed the tabular
>>> > output of a report in a wiki page?
>> You are not ... or maybe we both are
>> :P
>
> No comments to your ability to read in trac-hacks.org hack listings,

yes I have seen those ... but ...

> but
> I see at least two likely candidates to check:
>
> SqlQueryMacro
>
> Execute an SQL Query against a configured database displaying a
> formatted table of results.
>

with all respect ... afaics I'd not use this because it seems to me
that they do not respect Trac permissions and other access control
mechanisms . Saved reports are the way to go because they are under
the umbrella of some permission checks afaicr REPORT_CREATE ,
REPORT_SQL_EDIT . Hence only privileged users decide what will be
repots contents and what not .

> WikiTableMacro
>
> This is a simple macro that enables you to place tables resulting from
> SQL queries into a wiki page.
>
> It is similar to, but simpler than, SqlQueryMacro. The main differences
> are that it has fewer dependencies and always queries the Trac database,
> rather than letting you set up a separate data connection.
>

IDEM ... cmiiw
nonetheless if the OP still wants to use those , no objections afaict

> Bear with us and improve one of these instead of re-inventing the wheel,
> please.
>

jftr ...

<OT>
we didn't reinvent the wheel , we just reuse TracReports code under
the hood and make it ready-to-use in another environment . In the end
, Bloodhound widgets are kind of macros with more meta-data . Hence
they can be reused in many more ways not seen in Trac at the moment
e.g. embedded in Genshi templates using custom markup ...
</OT>

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28.09.2012 20:08, Christopher Nelson wrote:
> I would find it most useful to be able to say [[EmbedReport(24)]] than
> to copy the SQL from {24} to the macro but duplicating the SQL beats
> writing a new plugin!

I see. OTOH, others might prefer an hard-coded query over a rather weak
reference. The report is not guaranteed to even exist, and you need to
take precautions against undesired changes too (i.e. hint about it being
used somewhere in the wiki). But it's never self-contained.

And with ReportModule you'll not be able to query arbitrary databases
like you can with SqlQueryMacro.

I agree, that there's room for improvement, but would prefer to see a
plugin, that has all the capabilities combined.

Steffen Hoffmann

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBmKpwACgkQ31DJeiZFuHdddwCeNj2h11Ut8BCDIDqiIyZxI8Lc
AhoAoKZyL2WhJ8VMiQy0Rb5AhfUI0mur
=nr+0
-----END PGP SIGNATURE-----

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28.09.2012 23:11, Olemis Lang wrote:
> with all respect ... afaics I'd not use this because it seems to me
> that they do not respect Trac permissions and other access control
> mechanisms . Saved reports are the way to go because they are under
> the umbrella of some permission checks afaicr REPORT_CREATE ,
> REPORT_SQL_EDIT . Hence only privileged users decide what will be
> repots contents and what not .

You're right, I've just checked that now.

For Trac db tables you have a point. In general ReportModule is an
interesting, valid approach. OTOH it might still be too limited for some
folks, as I already told in my last reply. And the missing
permission/access control could be added rather easily, even reusing
existing permission.
Note that we have
trac.wiki.api.IWikiPageManipulator - Allows plugins to validate wiki
pages prior to that they get stored in the database.

So we could reject a wiki page with an embedded SQL macro done by the
"wrong" person.

In general contributions are welcome, but it seems to me like we've
already gone the fork-n-add way a bit too long. While it's easy to throw
out a new hack, maintaining and improving it over the years is a major
quality criteria from my point of view.
These days a couple of developers struggle hard to consolidate existing
hacks list, and anyone building on-top of existing code, maybe
integrating different related solutions into a more feature-rice one
helps to ease the pain of going over dozens of likely unmaintained heaps
of code.

Steffen Hoffmann

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBmLt4ACgkQ31DJeiZFuHeIwwCfbalQMsRGnlAQT/HYz1uMrXdT
DD8AoMi/GHPAke38r32nRCr0m3ZIv2Jv
=s4gB
-----END PGP SIGNATURE-----

[Olemis Lang]

On 9/28/12, Steffen Hoffmann <hof...@web.de> wrote:

> On 28.09.2012 23:11, Olemis Lang wrote:
>> with all respect ... afaics I'd not use this because it seems to me
>> that they do not respect Trac permissions and other access control
>> mechanisms . Saved reports are the way to go because they are under
>> the umbrella of some permission checks afaicr REPORT_CREATE ,
>> REPORT_SQL_EDIT . Hence only privileged users decide what will be
>> repots contents and what not .
>
> You're right, I've just checked that now.
>
> For Trac db tables you have a point. In general ReportModule is an
> interesting, valid approach.
>

[...]

> Note that we have
> trac.wiki.api.IWikiPageManipulator - Allows plugins to validate wiki
> pages prior to that they get stored in the database.
>
> So we could reject a wiki page with an embedded SQL macro done by the
> "wrong" person.
>

Note that the scope of WikiMacros spans beyond wiki pages themselves
as they will be expanded anywhere WikiFormatting is supported (e.g.
many places in tickets , roadmap , repository log messages ...
everywhere! ) . Limiting these concerns to a particular validation
entry point leads to a partial solution to the problem requiring many
other patches to cover other holes . IMO a more generic solution is
needed . ReportModule should be fine most of the time .

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.09.2012 04:08, Olemis Lang wrote:
> Note that the scope of WikiMacros spans beyond wiki pages themselves
> as they will be expanded anywhere WikiFormatting is supported

Agree, good point.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBmqAwACgkQ31DJeiZFuHcqCwCfc/KgyF8/T2Gg0wLLQjn7jOKc
wpEAniK4ieyzLUtBXeizEF9SFIT7fO3V
=SsNM
-----END PGP SIGNATURE-----