You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@bloodhound.apache.org by Shaun Murphy <sh...@outlook.com> on 2014/01/08 22:09:44 UTC
Wiki pages not stored as multiproduct
I have a strange environment/configuration problem I am having no luck debugging or finding relevant issues.
My install is bloodhound .7 on an Ubuntu 12.04 apache/mysql machine using the apache WSGI to serve the trac.wsgi.
I have two products:
1.) @ - default2.) lp - I created this one
When the users access the base_url (/bloodhound and not /bloodhound/products/%40) , they are adding wiki pages to some location outside of the products as they don't show up in the search or the regular trac timeline (/bloodhound/timeline.) The product pages (bloodhound/products/%40 and bloodhound/products/lp) both have a different set of wiki entries so even though I have 2 products defined, I have 3 disparate wikis.
When the users access the timeline (/bloodhound/timeline) it is showing only the changes to @ but not the base_url wiki entries.
I attempted to enable the bhsearch component but I get a trac error that the database needs to be upgraded and trac-admin upgrade says it is up to date.
Any thoughts on things to look for?
Re: AttributeError: 'Ticket' object has no attribute 'duplicate'
Posted by Ryan Ollos <ry...@wandisco.com>.
On Wed, Jan 15, 2014 at 8:22 AM, Ryan Ollos <ry...@wandisco.com> wrote:
> On Wed, Jan 15, 2014 at 6:57 AM, Ryan Ollos <ry...@wandisco.com>wrote:
>
>> On Wed, Jan 15, 2014 at 6:40 AM, Gary Martin <ga...@wandisco.com>wrote:
>>
>>> Hi,
>>>
>>> That is interesting. I wonder if this has already been 'fixed' in
>>> https://issues.apache.org/bloodhound/ticket/710
>>>
>>> If that is so, are we ignoring the setting of the duplicate now?
>>>
>>> Cheers,
>>> Gary
>>>
>>
>> #710 pertains only to batch modify, and the issue there hasn't really
>> been fixed yet. The issue with Batch modification is that
>> ITicketManipulator is not called. I'm still looking into how to best fix
>> that one.
>>
>> The "duplicate" field should get added by the ITicketManipulator
>> implementation in bhrelations.api:TicketRelationsSpecifics. I think this
>> issue is due to Dominik's custom workflow and the hard-code action
>> "resolve" in TicketRelationsSpecifics. I'll see about proposing a patch.
>>
>
> On testing, I found that one of the consequences of the temporary
> workaround in #710 is that we don't get a traceback, but the duplicate ID
> is not set. Gary may have already spotted this.
>
> We'll get this issue fixed in Release 8 in #742. Release 8 should be
> available in 2-2.5 weeks.
>
> https://issues.apache.org/bloodhound/ticket/742
>
The issue should be fixed on the trunk now.
Re: AttributeError: 'Ticket' object has no attribute 'duplicate'
Posted by Ryan Ollos <ry...@wandisco.com>.
On Wed, Jan 15, 2014 at 6:57 AM, Ryan Ollos <ry...@wandisco.com> wrote:
> On Wed, Jan 15, 2014 at 6:40 AM, Gary Martin <ga...@wandisco.com>wrote:
>
>> Hi,
>>
>> That is interesting. I wonder if this has already been 'fixed' in
>> https://issues.apache.org/bloodhound/ticket/710
>>
>> If that is so, are we ignoring the setting of the duplicate now?
>>
>> Cheers,
>> Gary
>>
>
> #710 pertains only to batch modify, and the issue there hasn't really been
> fixed yet. The issue with Batch modification is that ITicketManipulator is
> not called. I'm still looking into how to best fix that one.
>
> The "duplicate" field should get added by the ITicketManipulator
> implementation in bhrelations.api:TicketRelationsSpecifics. I think this
> issue is due to Dominik's custom workflow and the hard-code action
> "resolve" in TicketRelationsSpecifics. I'll see about proposing a patch.
>
On testing, I found that one of the consequences of the temporary
workaround in #710 is that we don't get a traceback, but the duplicate ID
is not set. Gary may have already spotted this.
We'll get this issue fixed in Release 8 in #742. Release 8 should be
available in 2-2.5 weeks.
https://issues.apache.org/bloodhound/ticket/742
Re: AttributeError: 'Ticket' object has no attribute 'duplicate'
Posted by Ryan Ollos <ry...@wandisco.com>.
On Wed, Jan 15, 2014 at 6:40 AM, Gary Martin <ga...@wandisco.com>wrote:
> Hi,
>
> That is interesting. I wonder if this has already been 'fixed' in
> https://issues.apache.org/bloodhound/ticket/710
>
> If that is so, are we ignoring the setting of the duplicate now?
>
> Cheers,
> Gary
>
#710 pertains only to batch modify, and the issue there hasn't really been
fixed yet. The issue with Batch modification is that ITicketManipulator is
not called. I'm still looking into how to best fix that one.
The "duplicate" field should get added by the ITicketManipulator
implementation in bhrelations.api:TicketRelationsSpecifics. I think this
issue is due to Dominik's custom workflow and the hard-code action
"resolve" in TicketRelationsSpecifics. I'll see about proposing a patch.
Re: AttributeError: 'Ticket' object has no attribute 'duplicate'
Posted by Gary Martin <ga...@wandisco.com>.
Hi,
That is interesting. I wonder if this has already been 'fixed' in
https://issues.apache.org/bloodhound/ticket/710
If that is so, are we ignoring the setting of the duplicate now?
Cheers,
Gary
On 15/01/14 08:09, Dominik Enkelmann wrote:
> When i try to "*reject*" a ticket in "assigned" state, setting the
> reason "*duplicate*", i get this error.
> When rejecting with another reason, for example "invalid" everything
> works fine.
>
> Any ideas?
> Dominik
>
>
> I have the following workflow defined:
>
> reassign = new,assigned,accepted,reopened -> assigned
> reassign.operations = set_owner
> reassign.permissions = TICKET_MODIFY
> reject = new,assigned, accepted -> closed
> reject.operations = set_resolution
> reject.permissions = TICKET_MODIFY
>
>
> Request parameters:
> {{{
> {'__FORM_TOKEN': u'94ca7d05eb05732286c165fd',
> 'action': u'reject',
> 'action_reject_resolve_resolution': u'duplicate',
> 'comment': u'',
> 'edit-comment': u'',
> 'field_cc': u'',
> 'field_component': u'component1',
> 'field_description': u'',
> 'field_keywords': u'',
> 'field_milestone': u'',
> 'field_priority': u'major',
> 'field_reporter': u'vpuzio@gmail.com',
> 'field_summary': u'Non funziona il reject con causa: duplicate',
> 'field_type': u'defect',
> 'field_version': u'1.0',
> 'id': u'104',
> 'start_time': u'1389772418764191',
> 'submit': u'Submit changes',
> 'view_time': u'1389772418764191'}
> }}}
>
> User agent: `Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0)
> Gecko/20100101 Firefox/26.0`
>
> ==== System Information ====
> || '''`Trac`''' || `1.0.1` [[br]] `` ||
> || '''`Babel`''' || `0.9.6` ||
> || '''`Bloodhound Trac`''' || `1.0.1` ||
> || '''`Genshi`''' || `0.6.1 (without speedups)` ||
> || '''`Pygments`''' || `1.6` ||
> || '''`pysqlite`''' || `2.4.1` ||
> || '''`Python`''' || `2.6.6 (r266:84292, Nov 22 2013, 12:16:22) `
> [[br]] `[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]` ||
> || '''`pytz`''' || `2013b` ||
> || '''`setuptools`''' || `0.9.8` ||
> || '''`SQLite`''' || `3.6.20` ||
> || '''`Subversion`''' || `1.8.5 (r1542147)` ||
> || '''`jQuery`''' || `1.7.2` ||
>
> ==== Enabled Plugins ====
> || '''`BloodhoundDashboardPlugin`''' || `0.7.0` ||
> || '''`BloodhoundMultiProduct`''' || `0.7.0` ||
> || '''`BloodhoundRelationsPlugin`''' || `0.7.0` ||
> || '''`BloodhoundSearchPlugin`''' || `0.7.0` ||
> || '''`BloodhoundTheme`''' || `0.7.0` ||
> || '''`TracAccountManager`''' || `0.4` ||
> || '''`TracPermRedirect`''' || `3.0` ||
> || '''`TracThemeEngine`''' || `2.2.1` ||
>
> ==== Python Traceback ====
> {{{
> Traceback (most recent call last):
> File
> "/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/web/main.py",
> line 477, in _dispatch_request
> dispatcher.dispatch(req)
> File
> "/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/web/main.py",
> line 214, in dispatch
> resp = chosen_handler.process_request(req)
> File
> "/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/multiproduct/ticket/web_ui.py",
> line 64, in process_request
> return self._process_ticket_request(req)
> File
> "/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/ticket/web_ui.py",
> line 614, in _process_ticket_request
> self._do_save(req, ticket, action)
> File
> "/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/ticket/web_ui.py",
> line 1328, in _do_save
> replyto=req.args.get('replyto'))
> File
> "/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/ticket/model.py",
> line 366, in save_changes
> listener.ticket_changed(self, comment, author, old_values)
> File
> "/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/bhrelations/api.py",
> line 503, in ticket_changed
> self.rls.add(ticket, ticket.duplicate,
> AttributeError: 'Ticket' object has no attribute 'duplicate'
> }}}
AttributeError: 'Ticket' object has no attribute 'duplicate'
Posted by Dominik Enkelmann <do...@infocube.it>.
When i try to "*reject*" a ticket in "assigned" state, setting the
reason "*duplicate*", i get this error.
When rejecting with another reason, for example "invalid" everything
works fine.
Any ideas?
Dominik
I have the following workflow defined:
reassign = new,assigned,accepted,reopened -> assigned
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reject = new,assigned, accepted -> closed
reject.operations = set_resolution
reject.permissions = TICKET_MODIFY
Request parameters:
{{{
{'__FORM_TOKEN': u'94ca7d05eb05732286c165fd',
'action': u'reject',
'action_reject_resolve_resolution': u'duplicate',
'comment': u'',
'edit-comment': u'',
'field_cc': u'',
'field_component': u'component1',
'field_description': u'',
'field_keywords': u'',
'field_milestone': u'',
'field_priority': u'major',
'field_reporter': u'vpuzio@gmail.com',
'field_summary': u'Non funziona il reject con causa: duplicate',
'field_type': u'defect',
'field_version': u'1.0',
'id': u'104',
'start_time': u'1389772418764191',
'submit': u'Submit changes',
'view_time': u'1389772418764191'}
}}}
User agent: `Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0)
Gecko/20100101 Firefox/26.0`
==== System Information ====
|| '''`Trac`''' || `1.0.1` [[br]] `` ||
|| '''`Babel`''' || `0.9.6` ||
|| '''`Bloodhound Trac`''' || `1.0.1` ||
|| '''`Genshi`''' || `0.6.1 (without speedups)` ||
|| '''`Pygments`''' || `1.6` ||
|| '''`pysqlite`''' || `2.4.1` ||
|| '''`Python`''' || `2.6.6 (r266:84292, Nov 22 2013, 12:16:22) ` [[br]]
`[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]` ||
|| '''`pytz`''' || `2013b` ||
|| '''`setuptools`''' || `0.9.8` ||
|| '''`SQLite`''' || `3.6.20` ||
|| '''`Subversion`''' || `1.8.5 (r1542147)` ||
|| '''`jQuery`''' || `1.7.2` ||
==== Enabled Plugins ====
|| '''`BloodhoundDashboardPlugin`''' || `0.7.0` ||
|| '''`BloodhoundMultiProduct`''' || `0.7.0` ||
|| '''`BloodhoundRelationsPlugin`''' || `0.7.0` ||
|| '''`BloodhoundSearchPlugin`''' || `0.7.0` ||
|| '''`BloodhoundTheme`''' || `0.7.0` ||
|| '''`TracAccountManager`''' || `0.4` ||
|| '''`TracPermRedirect`''' || `3.0` ||
|| '''`TracThemeEngine`''' || `2.2.1` ||
==== Python Traceback ====
{{{
Traceback (most recent call last):
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/web/main.py",
line 477, in _dispatch_request
dispatcher.dispatch(req)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/web/main.py",
line 214, in dispatch
resp = chosen_handler.process_request(req)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/multiproduct/ticket/web_ui.py",
line 64, in process_request
return self._process_ticket_request(req)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/ticket/web_ui.py",
line 614, in _process_ticket_request
self._do_save(req, ticket, action)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/ticket/web_ui.py",
line 1328, in _do_save
replyto=req.args.get('replyto'))
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/trac/ticket/model.py",
line 366, in save_changes
listener.ticket_changed(self, comment, author, old_values)
File
"/opt/apache-bloodhound-0.7/installer/bloodhound/lib/python2.6/site-packages/bhrelations/api.py",
line 503, in ticket_changed
self.rls.add(ticket, ticket.duplicate,
AttributeError: 'Ticket' object has no attribute 'duplicate'
}}}
Re: Wiki pages not stored as multiproduct
Posted by Andrej Golcov <an...@digiverse.si>.
Just short note:
There is no need for calling "bhsearch optimize" command after index rebuild.
I changed the wiki to make this clear.
Cheers, Andrej
On 10 January 2014 03:05, Shaun Murphy <sh...@outlook.com> wrote:
>
> Thank you, that did the trick.
>
> I updated the wiki to show that example.
>
>
> ________________________________
> Date: Thu, 9 Jan 2014 14:35:22 -0800
>
> Subject: Re: Wiki pages not stored as multiproduct
> From: ryan.ollos@wandisco.com
> To: user@bloodhound.apache.org
>
>
> On Thu, Jan 9, 2014 at 11:23 AM, Shaun Murphy <sh...@outlook.com>
> wrote:
>
> I was able to upgrade .7 to trunk and search/timeline appear to have been
> fixed.
>
> Follow-on question... search is only picking up new changes to the wiki and
> does not see old data. I'm guessing I have to rebuild a search index of
> some sort but I'm not sure how to use bhsearch, do you have some guidance
> past the wiki:
>
> https://issues.apache.org/bloodhound/wiki/BloodhoundSearchAdmin
>
> thank you
>
>
> Are you asking how to execute those documented "bhsearch" commands? Those
> get prefixed with "trac-admin $env", where $env is the path to the
> environment directory:
> trac-admin $env bhsearch rebuild
> trac-admin $env bhsearch optimize
>
> More general documentation on trac-admin can be found here:
> https://issues.apache.org/bloodhound/wiki/TracAdmin
RE: Wiki pages not stored as multiproduct
Posted by Shaun Murphy <sh...@outlook.com>.
Thank you, that did the trick.
I updated the wiki to show that example.
Date: Thu, 9 Jan 2014 14:35:22 -0800
Subject: Re: Wiki pages not stored as multiproduct
From: ryan.ollos@wandisco.com
To: user@bloodhound.apache.org
On Thu, Jan 9, 2014 at 11:23 AM, Shaun Murphy <sh...@outlook.com> wrote:
I was able to upgrade .7 to trunk and search/timeline appear to have been fixed.
Follow-on question... search is only picking up new changes to the wiki and does not see old data. I'm guessing I have to rebuild a search index of some sort but I'm not sure how to use bhsearch, do you have some guidance past the wiki:
https://issues.apache.org/bloodhound/wiki/BloodhoundSearchAdmin
thank you
Are you asking how to execute those documented "bhsearch" commands? Those get prefixed with "trac-admin $env", where $env is the path to the environment directory:
trac-admin $env bhsearch rebuildtrac-admin $env bhsearch optimize
More general documentation on trac-admin can be found here:https://issues.apache.org/bloodhound/wiki/TracAdmin
Re: Wiki pages not stored as multiproduct
Posted by Ryan Ollos <ry...@wandisco.com>.
On Thu, Jan 9, 2014 at 11:23 AM, Shaun Murphy <sh...@outlook.com>wrote:
> I was able to upgrade .7 to trunk and search/timeline appear to have been
> fixed.
>
> Follow-on question... search is only picking up new changes to the wiki
> and does not see old data. I'm guessing I have to rebuild a search index
> of some sort but I'm not sure how to use bhsearch, do you have some
> guidance past the wiki:
>
> https://issues.apache.org/bloodhound/wiki/BloodhoundSearchAdmin
>
> thank you
>
Are you asking how to execute those documented "bhsearch" commands? Those
get prefixed with "trac-admin $env", where $env is the path to the
environment directory:
trac-admin $env bhsearch rebuild
trac-admin $env bhsearch optimize
More general documentation on trac-admin can be found here:
https://issues.apache.org/bloodhound/wiki/TracAdmin
RE: Wiki pages not stored as multiproduct
Posted by Shaun Murphy <sh...@outlook.com>.
I was able to upgrade .7 to trunk and search/timeline appear to have been fixed.
Follow-on question... search is only picking up new changes to the wiki and does not see old data. I'm guessing I have to rebuild a search index of some sort but I'm not sure how to use bhsearch, do you have some guidance past the wiki:
https://issues.apache.org/bloodhound/wiki/BloodhoundSearchAdmin
thank you
> Date: Thu, 9 Jan 2014 00:53:12 -0500
> Subject: Re: Wiki pages not stored as multiproduct
> From: olemis@gmail.com
> To: user@bloodhound.apache.org
>
> On 1/8/14, Michael Jinks <mi...@gmail.com> wrote:
> > Speaking of upgrading... Maybe this is a naive question, but I haven't
> > been able to find any documentation describing how to upgrade
> > Bloodhound. The "Upgrade" link in my copy of the built-in
> > documentation appears to apply to Trac, which of course versions
> > separately.
> >
>
> In principle it's the same procedure . Of course , upgrade steps are
> different under the hood . But that's all encapsulated by a single
> invocation of
>
> $ trac-admin /path/to/bh/env upgrade
>
> Bloodhound is yet another (set of) Trac plugin(s) out there
> ;)
>
> > Am I making things more complicated than they need to be? Is it as
> > simple as installing the new version and directing it to use a copy of
> > my existing database?
> >
>
> All other recommendations mentioned in TracUpgrade are still valid .
> These would be my additions :
>
> - There's no need to remove the previous copy if the code is
> pulled from BH svn repository
> * ... but it's highly recommended to remove all *.pyc files
>
> TBH , I could not find anything else ... In any case should you find
> any upgrade issues please let us know and/or document solutions in
> bh:wiki:TracUpgrade [1]_ .
>
> p.s. ... and , yes , maybe we should add some sections of the kind
> «Steps specific to a given Bloodhound version» , but more likely these
> should be handled by the installer script .
>
> .. [1] http://issues.apache.org/bloodhound/wiki/TracUpgrade
>
> [...]
>
> --
> Regards,
>
> Olemis - @olemislc
Re: Wiki pages not stored as multiproduct
Posted by Olemis Lang <ol...@gmail.com>.
On 1/8/14, Michael Jinks <mi...@gmail.com> wrote:
> Speaking of upgrading... Maybe this is a naive question, but I haven't
> been able to find any documentation describing how to upgrade
> Bloodhound. The "Upgrade" link in my copy of the built-in
> documentation appears to apply to Trac, which of course versions
> separately.
>
In principle it's the same procedure . Of course , upgrade steps are
different under the hood . But that's all encapsulated by a single
invocation of
$ trac-admin /path/to/bh/env upgrade
Bloodhound is yet another (set of) Trac plugin(s) out there
;)
> Am I making things more complicated than they need to be? Is it as
> simple as installing the new version and directing it to use a copy of
> my existing database?
>
All other recommendations mentioned in TracUpgrade are still valid .
These would be my additions :
- There's no need to remove the previous copy if the code is
pulled from BH svn repository
* ... but it's highly recommended to remove all *.pyc files
TBH , I could not find anything else ... In any case should you find
any upgrade issues please let us know and/or document solutions in
bh:wiki:TracUpgrade [1]_ .
p.s. ... and , yes , maybe we should add some sections of the kind
«Steps specific to a given Bloodhound version» , but more likely these
should be handled by the installer script .
.. [1] http://issues.apache.org/bloodhound/wiki/TracUpgrade
[...]
--
Regards,
Olemis - @olemislc
Re: Wiki pages not stored as multiproduct
Posted by Michael Jinks <mi...@gmail.com>.
Speaking of upgrading... Maybe this is a naive question, but I haven't
been able to find any documentation describing how to upgrade
Bloodhound. The "Upgrade" link in my copy of the built-in
documentation appears to apply to Trac, which of course versions
separately.
Am I making things more complicated than they need to be? Is it as
simple as installing the new version and directing it to use a copy of
my existing database?
On Wed, Jan 8, 2014 at 4:25 PM, Olemis Lang <ol...@gmail.com> wrote:
> On 1/8/14, Shaun Murphy <sh...@outlook.com> wrote:
>>
> [...]
>>
>> Any thoughts on things to look for?
>
> If I recall correctly this is ths kind of confusion caused by the
> former approach of serving *some global* requests to render default
> product resources i.e. for wikis there are :
>
> - global /wiki
> - /products/%40/wiki
> - /products/lp/wiki
>
> ... whereas the global /ticket path displays default product tickets
> as well as /products/%40/ticket ... o_O . This is confusing , yesy ,
> but is expected in 0.7 .
>
> FWIW , redirections to default product have been removed in /trunk
> (0.8-dev) which is worth trying if you can deal with the upgrade .
>
> --
> Regards,
>
> Olemis - @olemislc
Re: Wiki pages not stored as multiproduct
Posted by Olemis Lang <ol...@gmail.com>.
On 1/8/14, Shaun Murphy <sh...@outlook.com> wrote:
>
[...]
>
> Any thoughts on things to look for?
If I recall correctly this is ths kind of confusion caused by the
former approach of serving *some global* requests to render default
product resources i.e. for wikis there are :
- global /wiki
- /products/%40/wiki
- /products/lp/wiki
... whereas the global /ticket path displays default product tickets
as well as /products/%40/ticket ... o_O . This is confusing , yesy ,
but is expected in 0.7 .
FWIW , redirections to default product have been removed in /trunk
(0.8-dev) which is worth trying if you can deal with the upgrade .
--
Regards,
Olemis - @olemislc