Re: Issue tracker not working

Hello

I took a look and we are using the classic template and I am working on  
a copy at the moment

We did the Python 2-3 changes first to install the 2.2.0 roundup 
version, but I went from 1.3.3 to 2.2.0 as I thought the reason it was 
not working was because it was not fully updated.

I am trying to access the home page, searching for specific issue 
numbers works fine

/tracker/status and /tracker/index?@columns=title both dont work

i dont get an error when running, roundup-admin -i 
tracker/home/directory display issue1

I see so the problem could be with reldate, ok I will take a look and 
see if theres anything I can do

Thanks
Gianluca

On 26/07/2023 18:50, John P. Rouillard wrote:
> 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.
>


_______________________________________________
Roundup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-users