﻿ticket,summary,type,release,owner,status,created,modified,_description,_reporter
13778,Update usernames displayed to show the display name from Chrome.authorinfo,enhancement,,,new,2020-04-13T15:39:14+02:00,2020-04-30T03:51:38+02:00,"Can this plugin be updated to have the username converted to the display name?

",anonymous
7990,Unusual use of trac.mimeview.Context,task,0.12,,new,2010-11-04T13:40:29+01:00,2017-04-15T10:16:31+02:00,"Thanks for writing this plugin! I've been reading through the code to see if we can build on it.

I've found the use of [http://trac.edgewall.org/browser/trunk/trac/mimeview/api.py#L77 `trac.mimeview.Context`]
as a way of passing around the Request and data-dictionary a bit confusing - is there any interest in a patch which switches to a more traditional (IMHO, which may be wrong) Trac-like way of passing the req (and data) object rather than a Context instance? As the Context (when made with `from_request` does keep reference to the Request, maybe it's fine to avoid passing ALSO the Request around separately, but it doesn't feel very common - the `Context` (from the docstrings) is more about rendering. Grepping for `context.req` in discussionplugin causes many hits, but doing the same for other plugins or Trac code shows this is used only rarely.

For example, in [source:discussionplugin/0.11/tracdiscussion/api.py#L85 `IMessageChangeListener`] a context object is needed - but as this object often has extra attributes added, it's not clear what are actually available when implementing this interface. Also, after the call to `message_created`, it might/will have extra attributes on it :-) In fact, from reading now, it seems like no actual `trac.mimeview.Context` attributes are used in this call.

Some other uses of `Context` feel more awkward/unusual:

`trac.mimeview.Context` has no cursor attribute, but source:discussionplugin/0.11/tracdiscussion/api.py#L170 places a cursor there. Later a lot of other things get put here too - source:discussionplugin/0.11/tracdiscussion/api.py#L301. I understand it's handy to pass around some stafeul object, but feel some dictionary or discussionplugin specific object might be better?  Grepping through a lot of plugins and Trac code, I don't see anywhere else that uses a dictionary at context.data when preparing what it's going to give to Genshi for rendering the template.

If we reorganise this a bit, is that interesting to you as a patch?

",pipern
8798,Unhandled exception regarding subscribing,defect,0.12,,new,2011-05-13T23:54:01+02:00,2017-04-15T08:07:27+02:00,"I have a problem subscribing to forums / topics.  (I have tags plugin enabled, if that makes a difference.   Also Ajax.)  When I press the subscribe button, a bad thing happens.

In ""tags.py"", there is a problem in ""forum_changed()"" and ""topic_changed()"" -- the new ""forum"" and ""topic"" objects don't contain and ""id"".  I think the same happens for ""author"".  (For instance, see api.py where ""elif action == 'topic-subscriptions-post-edit':"" -- only ""subscribers"" is created in the new topic.)

I changed the operations in those functions to use ""old_forum"" and ""old_topic"" to (apparently) fix the problem.  I'm not sure if that's actually correct, but it seems so far to do what I need it to do.",trac@…
12185,Selectable columns,enhancement,,,new,2015-02-09T13:48:04+01:00,2015-02-09T13:48:04+01:00,"Hi,

please make columns selectable by configuration, so that the column ID in the forum list can be disabled because not interesting for discussion users.",massimo.b@…
892,RFE: ViewTopic macro should be able to start a topic,enhancement,0.10,,new,2006-11-11T08:28:43+01:00,2017-04-15T08:07:27+02:00,"Currently, the !ViewTopic macro just prints ''""No discussion for this page created.""'' when such a discussion doesn't exist. I'd like it to add a link ''""Start it here.""'' or else to open the ""add discussion"" page with the topic field prefilled (and maybe, readonly?)

Like this, I could use the forum plugin as a comment-addon for the blog functionality.",Christian Aust
7309,RFE: TracCaptchaPlugin support.,enhancement,0.12,,new,2010-06-29T13:18:52+02:00,2017-04-15T08:07:27+02:00,"When I try to create a discussion using the plugin I get the following error:

==== How to Reproduce ====

While doing a POST operation on `/discussion/forum/1`, Trac issued an internal error.

''(please provide additional details here)''

Request parameters:
{{{
{'__FORM_TOKEN': u'2b983556e38e2d3f55c5cc58',
 'author': u'anonymous',
 'body': u'...',
 'discussion_action': u'post-add',
 'forum': u'1',
 'subject': u'',
 'submit': u'Submit',
 'subscribers': u''}
}}}

User agent: `Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.0.19) Gecko/2010031218 Firefox/3.0.19`

==== System Information ====
''System information not available''

==== Enabled Plugins ====
''Plugin information not available''

==== Python Traceback ====
{{{
Traceback (most recent call last):
  File ""/usr/lib/python2.6/site-packages/Trac-0.12-py2.6.egg/trac/web/main.py"", line 513, in _dispatch_request
    dispatcher.dispatch(req)
  File ""/usr/lib/python2.6/site-packages/Trac-0.12-py2.6.egg/trac/web/main.py"", line 235, in dispatch
    resp = chosen_handler.process_request(req)
  File ""/usr/lib/python2.6/site-packages/TracDiscussion-0.7-py2.6.egg/tracdiscussion/core.py"", line 108, in process_request
    template, data = api.process_discussion(context)
  File ""/usr/lib/python2.6/site-packages/TracDiscussion-0.7-py2.6.egg/tracdiscussion/api.py"", line 245, in process_discussion
    self._do_actions(context, actions)
  File ""/usr/lib/python2.6/site-packages/TracDiscussion-0.7-py2.6.egg/tracdiscussion/api.py"", line 950, in _do_actions
    context, topic)
  File ""/usr/lib/python2.6/site-packages/TracDiscussion-0.7-py2.6.egg/tracdiscussion/spamfilter.py"", line 25, in filter_topic
    topic['body'])])
TypeError: test() takes exactly 5 arguments (4 given)
}}}

I'm using Trac 0.12, TracDiscussion 0.7 and TracSpamFilter 0.3.2dev-r9922.",royger@…
756,RFE: Forum Based Permission,enhancement,0.12,,new,2006-10-02T21:13:42+02:00,2016-12-02T23:51:54+01:00,"It would be great if you could expand the permission system so that we can set permissions based on the Forum.  For example, I may want to have a developers forum that is seperate from the users ... we may not want users reading the developers forum.  

One possible way of doing this is to append the forum permission with a number that corresponds to the forum number.  Forum# 0 could be a blanket ""all forums"".  All Forum specific permissions would overwrite Forum# 0 permissions.

Just a thought, other than that .. GREAT PLUGIN!",anonymous
8441,RFE: Fold/collapse/hide parts of the discussion tree,enhancement,0.11,,new,2011-01-26T11:30:43+01:00,2017-04-15T10:50:03+02:00,"In the tree view discussion topic it would be very useful to allow ""folding and unfolding"" of a sub tree. Each reply would have a ""[-]"" or ""Fold"" link button. When clicked the reply and all relevant replies collapse (""folded"", become hidden). Only a ""[+]"" or ""Unfold"" link button remains, and maybe a single line (fragment) of the reply remains.

This would be very useful in larger discussions.

Personally, I would prefer hiding on the client using javascript / CSS, so no server roundtrip is needed to fold or unfold a sub tree.",lucid
13116,Permissions for user created posts,enhancement,1.2,,new,2017-03-16T13:04:34+01:00,2017-03-16T13:04:34+01:00,Please add a separate permission to allow users to edit and delete their own posts without having the DISCUSSION_MODERATE permission.,Massimo
13246,Notification emails are not sending,defect,1.0,,new,2017-07-26T14:46:32+02:00,2017-09-15T16:17:51+02:00,"Recently, our 1.0 Trac installation doesn't not send messages for new posts on our different forums.

I have tracked the events on Trac for the latest messages posted in the forums and found the same errors on the log file
{{{#!logtalk
2017-07-24 16:13:26,096 Trac[api] WARNING: AttributeError: 'NoneType' object has no attribute 'resource'
2017-07-24 16:13:26,098 Trac[api] WARNING: PermissionError: Insufficient privileges to perform this operation.
}}}

The notifications for forums used to work before until we got back in the same time with the default notification system for tickets instead of WorkflowNotificationPlugin so I think somehow it should be related.",ntmlod
8447,Minor stylesheet / template suggestions,enhancement,0.11,,new,2011-01-27T14:55:23+01:00,2017-04-15T10:50:22+02:00,"The ""message list"" pages can appear a bit ""cluttered"". It's hard to see the the actual message content among all the meta-information ""noise"". I would suggest:
 * Remove the ""Message #xxx"" at the top of each reply
 * (Optional: Instead add a ""Link"" at the bottom next to ""Reply Quote Edit Delete"" that links to this message and has the #xxx number in its ""title"" property.)
 * Use a less obtrusive text style for the ""username timestamp"" text below each reply
 * Not bold, maybe a lighter shade of gray (#999 or #bbb like Trac's help or footer text)
",lucid
13054,Issue with 'RecentTopics' macro on PostgreSQL DB,defect,1.0,,new,2017-01-25T15:12:58+01:00,2017-07-26T16:28:50+02:00,"Not as an expert in the different SQL implementations but the syntax of `get_recent_topics` seems not to be compliant with `psql`

__Log error__
{{{
2017-01-17 15:24:26,276 Trac[formatter] ERROR: Macro RecentTopics(2) failed: 
Traceback (most recent call last):
  File ""/usr/lib/python2.7/site-packages/trac/wiki/formatter.py"", line 765, in _macro_formatter
    return macro.ensure_inline(macro.process(args))
  File ""/usr/lib/python2.7/site-packages/trac/wiki/formatter.py"", line 356, in process
    text = self.processor(text)
  File ""/usr/lib/python2.7/site-packages/trac/wiki/formatter.py"", line 343, in _macro_processor
    text)
  File ""build/bdist.linux-x86_64/egg/tracdiscussion/wiki.py"", line 102, in expand_macro
    return self._recent_topics(formatter, content)
  File ""build/bdist.linux-x86_64/egg/tracdiscussion/wiki.py"", line 169, in _recent_topics
    entries = self.api.get_recent_topics(context, forum_id, limit)
  File ""build/bdist.linux-x86_64/egg/tracdiscussion/model.py"", line 253, in get_recent_topics
    for row in self.env.db_query(sql, values)]
  File ""/usr/lib/python2.7/site-packages/trac/db/api.py"", line 122, in execute
    return db.execute(query, params)
  File ""/usr/lib/python2.7/site-packages/trac/db/util.py"", line 121, in execute
    cursor.execute(query, params)
  File ""/usr/lib/python2.7/site-packages/trac/db/util.py"", line 65, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
ProgrammingError: subquery in FROM must have an alias
LINE 1: SELECT forum, topic, MAX(time) as max_time  FROM  (SELECT fo...
                                                          ^
HINT:  For example, FROM (SELECT ...) [AS] foo.
}}}

__My 2 cents fix__
{{{#!diff
Index: tracdiscussion/model.py
===================================================================
--- tracdiscussion/model.py	(révision 16179)
+++ tracdiscussion/model.py	(copie de travail)
@@ -231,16 +231,17 @@
 
     def get_recent_topics(self, context, forum_id, limit):
         columns = ('forum', 'topic', 'time')
-        sql = (""SELECT forum, topic, MAX(time) as max_time""
+        sql = (""SELECT forum, topic, max(time)""
                ""  FROM""
                ""  (SELECT forum, topic, time""
                    "" FROM message""
                ""   UNION""
                ""   SELECT forum, id as topic, time""
-                   "" FROM topic)"" +
-               (forum_id and "" WHERE forum=%s"" or '') +
-               "" GROUP BY topic""
-               "" ORDER BY max_time DESC"" +
+                   "" FROM topic)""
+	       ""  AS foo"" +
+               (forum_id and "" WHERE foo.forum=%s"" or '') +
+               "" GROUP BY foo.topic, foo.forum, foo.time""
+               "" ORDER BY time DESC"" +
                (limit and "" LIMIT %s"" or ''))
         values = []
         if forum_id:
}}}",ntmlod
13878,DiscussionPlugin  Basic Flaws Patches,defect,1.4,,new,2020-08-24T02:18:21+02:00,2020-08-25T14:57:55+02:00,"I'm auditioning DiscussionPlugin for some users on our new Trac 1.4.2 system. I'd rather not set up a whole separate forum system without some serious reasons; this plugin could save the effort of learning a whole new PHP software bundle (probably bloatware as most systems become over time).

Anyway, I developed some patches.  I'm not saying they're pretty, but they will help in actually getting a taste for what the plugin can actually do.

1. Can't send notifications, and that code is far out of date.  I updated the notification subsystem for the latest API.  This new code could probably use a lot of work.
2. Forums get lost when editing in the admin panel.  This is due to a bogus group entry, which was simply treated by adding the hidden field that is in the normal forum creation template.
3. Subscription isn't available if you haven't set your preferences.  On our system, Trac can assemble the e-mail address from the login name.  My testers immediately dismissed the plugin because they thought they could not subscribe.  The fix I made may not be generic for all cases, but will allow subscription even without settings the preferences.

See attached file.",anonymous
10153,Create separated i18n domain for plugin messages,enhancement,0.12,,new,2012-07-14T09:01:27+02:00,2017-04-15T08:07:27+02:00,As discussed in http://trac.edgewall.org/wiki/CookBook/PluginL10N,anonymous
9861,Author not validated on message creation,defect,0.11,,new,2012-02-28T04:15:13+01:00,2017-04-15T08:07:27+02:00,"Okay, so:
Almost brand new trac install, added DiscussionPlugin, added `DISCUSSION_APPEND` permission to anonymous as the site itself is not accessible to the public.
However, anyone can set the author when they are not logged in, including setting it to any existing user. Obviously this is undesirable; They should at least not be allowed to select existing users, though it seems to me they should be restricted to anonymous.

Furthermore, logged in users are only restricted through the form; If they decide to edit the form locally or modify the post data they can write anything in the author field as well, and it isn't validated in any way.

Is this all intentional or an oversight??",Radek Bartoň
12971,Adapt to Trac 1.2 notification API,enhancement,,Ryan J Ollos,accepted,2016-11-27T19:45:39+01:00,2019-09-17T06:00:15+02:00,A version compatible with Trac >= 1.2 will be developed on the [browser:discussionplugin/1.2] branch. The plugin will be adapted to use the new Trac notification API.,Ryan J Ollos
