Re: Issue tracker not working

Hi Gianluca:

In message <[email protected]>,
Gianluca Ferrazzano writes:
>Yes we have a backup of the original database and tracker.

Good.

>Yes we have a backup of the tracker now.

Good.

>I am a beginner when it comes to python.

Ok.

>The database is postgresql.
>
>I'm not sure which template the tracker is based on, how would I find 
>this out?

Look for a TEMPLATE-INFO.txt file in the tracker home directory.

Are you working on your production tracker or are you testing the
upgrade on a copy?

I have included the rest of the original email below with more
requests below. I think you stopped at the first quoted section that I
was using for context for the rest of my questions.

In message <[email protected]>,
Gianluca Ferrazzano writes:

> I have recently updates the Roundup issue tracker from 1.3.3 to 2.2.0,

 That's a big jump. Did you do all the upgrades in one step, or did you
 do it in multiple steps? For example:

    * upgrade from 1.3.3 to 1.6.1 and verify things were working
    * then do the 1.6.1 to 2.0.0 upgrade and convert to Python3
    * then do the 2.0.0 to 2.2.0 upgrade

 There is no reason I know of that doing it all in one step shouldn't
 work. However, if you used mutiple steps, it would help localize it to
 a particular release/releases.

> I have done all the required steps but I am getting this error when I try
> to access the issue tracker.

 For all url references, '.../tracker/' means everything up to and
 including the tracker designator (if present). For example Roundup
 uses https://issues.roundup-tracker.org/ with no 'tracker' designator,
 so '.../tracker/' would just be 'https://issues.roundup-tracker.org/'.
 If your URL was 'http://tracker.mycompany.com/product/', that would
 replace '.../tracker/'.

 What page are you trying to load?

    * an index page (e.g. .../tracker/issue)
    * an item page (e.g. .../tracker/issue1)
    * a search page (e.g. .../tracker/issue?@template=search)
    * the home page  (e.g. .../tracker/)

 Can you try loading the status index page:

     .../tracker/status

 or load an index page with only the issue titles:

     .../tracker/index?@columns=title

 by editing the URL in your browser. Neither of these pages should have
 date calculations (IIRC). If there is no traceback for these, it will
 tell us that the basic machinery is working.

 Do you get an error if you run:

    roundup-admin -i tracker/home/directory display issue1

 where tracker/home/directory is the home directory for your tracker. (I
 assume issue1 exists in the tracker. If you know an issue number you
 can use it instead.)

> Here is the full traceback, what should I do?

 It looks like there is some date calculation going on and the _value
 is not a Date but a string. I have never seen this before.

  From the traceback this looks like the result of calling reldate. In
 the classic template this only happens for the activity or creation
 date. Check your templates (probably just the issue templates) using
 grep or other tool and see if reldate shows up anywhere else than in:

        tal:content="i/creation/reldate">&nbsp;</td>
        tal:content="i/activity/reldate">&nbsp;</td>

 You may have tripped across some weird edge case here.  Some
 comparisions/operations that were allowed in Python 2 are not allowed
 in Python 3. If your tracker has some string field that it's trying to
 interpret as a date, Python 2 may have ignored the failed subtraction
 but Python 3 won't. I doubt that this is the cause but it's the first
 thought.

 Have a good day.

--
			-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.