Closed Bug 203709 Opened 21 years ago Closed 15 years ago

Display most important bugs on start page, depending on user login

Categories

(Bugzilla :: Query/Bug List, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 130835

People

(Reporter: nn4l, Assigned: jonathan)

References

(Blocks 1 open bug)

Details

Attachments

(8 files, 7 obsolete files)

4.62 KB, application/octet-stream
Details
4.46 KB, application/octet-stream
Details
34.58 KB, image/gif
Details
141 bytes, patch
Details | Diff | Splinter Review
5.64 KB, text/plain
Details
30.00 KB, application/octet-stream
Details
4.69 KB, application/octet-stream
Details
15.88 KB, patch
guy.pyrzak
: review-
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: 

If a user is logged in, he should see his most important bugs on the start page
instead of the useless ant image.

The typical developer is interested in a list of bugs that have been assigned to
him. 

The tester / QA person on the other hand wants to see bugs that he once reported
and are now in the "RESOLVED" state. In addition, he is interested in bugs he
reported but which are still in the "NEW" state, meaning that nobody feels
responsible for those.

By putting these bug lists right on the start page every developer or tester is
constantly reminded to his open issues. It has an amazing effect on focusing on
fixing and retesting the bugs.

I have written a new frontpage.cgi script and its corresponding template. It is
actually meant as a replacement for index.cgi. I have also attached a screenshot
of a bugzilla installation already using this new template.

Reproducible: Always

Steps to Reproduce:
Attached image screenshot of new frontpage (obsolete) —
Attached file frontpage.cgi (2.17.4) (obsolete) —
Attachment #121932 - Attachment description: frontpage.cgi and corresponding template → frontpage.cgi (2.17.4)
Bug #51100 is related to this one, but doesn't have a solution.
Attached file frontpage.cgi (2.16.2) (obsolete) —
See also bug 130835.
The new index.cgi described in bug #130835 is designed for mozilla.org's needs.
It is probably useful for many other open source projects too, which have many
more visitors of the bug tracking system than active developers.

However many bugzilla installations are used in-house and not visible to the
general public. These installations typically have a small number of projects
and components, and all visitors of the bugzilla website are either developers,
testers, project managers or in some other way closely related to the
development efforts.

The simple "to-do-list" frontpage turned out to be extremely effective in our
team. Whenever a developer or a tester opens the bugzilla website, he is calmly
reminded to his unfinished work. It is much more effective than the whine email.
The number of bugs in the "NEW" and "RESOLVED" state have been dropped
significantly since introduction of this frontpage.cgi (renamed to index.cgi) page. 

Next thing I want to work on is a small project manager overview, displaying all
relevant information per project.
I think this bug is an excellent idea. If its implementation in mozilla.org's
bugzilla did not have the same effects mentioned above, I would be very surprised.  

We have two proposed front-pages, the one in bug #130835 and the one described
here.  We don't have to choose.  We can have both.  Bug #130835 can be the
front-page when the user is *not* logged in and this bug when the user is. What
do you think?  

Please note that I am not a CGI programmer but I am willing to create a mockup
on which the final CGI page can be based.
this one looks really nice!
and in principles similar to my version (of coursem this one is visually better)
http://bugzilla.mozilla.org/attachment.cgi?id=118393&action=view

i think a dependency should be made between this bug and bug #130835 (i propose,
that this one depends on the second one)
main reasons for that:
1. Gerv wan't allow to get this through until 130835 is done, anyway
2. For public use this means lots of queries everytime, when hitting 1stpage, so
it is necessarry to think about some cashing or so

personally me - i will right now change the look of lists in my bugzilla to this :)
For Bugzilla 2.17.4 I had to change the SendSQL statement to do a join with the
products table like this

SendSQL("SELECT bug_id, name, bug_status, short_desc FROM bugs, products WHERE
assigned_to=$userid AND bug_status IN ('NEW','ASSIGNED') AND product_id=id ORDER
BY bug_id DESC");

to make attachment (id=121986) work.
But attachment #121986 [details] is for 2.16.x. For 2.17.4 we already have attachment
#121932 [details], which differs from 2.16.x by the sql statement you described.
Attached file frontpage.cgi (2.17.4) (obsolete) —
Attachment #121932 - Attachment is obsolete: true
Attached file frontpage.cgi (2.16.3) (obsolete) —
Attachment #121986 - Attachment is obsolete: true
New features for the frontpage: 

- the todo lists now contain additional columns "status" and "priority".

- the product name is now clickable and displays the query result of this
product and all bugs which are not closed or verified.

- the queries are improved. I missed states like "ASSIGNED" and "REOPENED" in
the previous release.

- on the left side there is now an additional table which displays the total of
outstanding bugs per project.

Things to do:

- if any query returns 0 rows, the corresponding box should not be displayed at all.

- I would like to display icons instead of the bug state, severity and priority
columns. The current text display is just too wide and a waste of space. I was
thinking of a question mark for a new issue, a person for an assigned issue, a
check mark for a resolved issue, dots in different hues and sizes for severity
and priority. But I'm not an artistic person and can't design reasonable icons.
Please create some and attach them here.

- the queries should really be configurable. A click on the top cell in a column
should trigger sorting by that column, ascending and descending. This would
however add lots of complexity though.
Here's a neat addition (suggested by Bo Rasmussen):

Modify template/en/default/global/useful-links.html.tmpl:

      <td valign="middle" nowrap>
        [% IF user.login %]
        <a href="frontpage.cgi">ToDo</a> |
        [% END %]
        <a href="enter_bug.cgi">New</a> |
        <a href="query.cgi">Query</a> |

Whenever a user is logged in, he now has a link to his to do list in the footer.

To disable displaying of empty to do lists, modify the frontpage.html.tmpl with
an [% IF %] [% END %] statement like this (will include this in the next
frontpage attachment):


[% IF assignedbugs.size > 0 %]
<table bgcolor="#bbbbbb" border="0" cellpadding="0" cellspacing="0" width="100%">
  <tr><td colspan="4">
    <table border="0" cellpadding="3" cellspacing="1" width="100%"
style="font-size: 8pt; font-family: Verdana,Arial,Helvetica,sans-serif">
      <tr bgcolor="#eeeeee">
        <td colspan="5">Open Issues: <b>Assigned to you</b> (the issue has been
assigned to you and it is not resolved or closed yet)</td>

.... 

  </td></tr>
</table> 
<br>
[% END %]

If a developer detects a bug on his own, creates a report and then works on
fixing the bug himself, this will be listed in the "ASSIGNED TO YOU" section as
well as the "IN PROGRESS" section.

I feel this wastes unnecessary space, the listing in "ASSIGNED TO YOU" should be
enough in this case.
I seem to be getting an error related to frontpage (as seen from my error log)

relogin.cgi: Use of uninitialized value in join or string at
/usr/lib/perl5/5.8.0/CGI/Cookie.pm line 162., referer:
http://bugzilla.broadcastsportsinc.com/frontpage.cgi
If a product name has (for example) an ampersand '&' or '+' in it's name, the url
that is generated when it is clicked in 'Active products, open issues:' is invalid

the & is not translated to %26 for example (it remains an & and srews up the GET
string)
Fix for problem in comment #17:

in frontpage.cgi, add this line after all assignments to $bug->{"product"}:

    $bug->{"product"} = shift @row;
    $bug->{"producturl"} = url_quote($bug->{"product"});

in frontpage.html.tmpl, change all [% bug.product %] macros inside the <a> tag
to [% bug.producturl %]:

 <td><a href="buglist.cgi?product=[% bug.producturl %]&bug_status....

Will make a new release when I have some spare time.
Re comment #16: I'm using perl 5.6.1, I do not see this particular problem, but
I have lots of similar "Use of uninitialized value" warnings in other,
unmodified Bugzilla releases. My guess is, since this is merely a warning, it is ok.
Yes, that fix works... thanks!

You need to do it at
    $product->{"product"} = shift @row;
(add)
    $product->{"producturl"} = url_quote($product->{"product"});
as well
  (and [% product.product %] becomes [% product.producturl %] in the template )
for the left hand column.
Changes:

1. changed the order of the colums: the product column now comes after the short
description, which is less error prone
2. if a todo box is empty, it is not displayed
3. the products list is now sorted alphabetically instead of number of issues,
because our developers complained
4. the footer now contains a link to frontpage.cgi named "ToDo"
5. if a developer detects a bug on his own and then assign it to himself, it
will be displayed only once
6. bugfix: products containing "+" and "&" characters now have the proper
product list url
Attachment #123311 - Attachment is obsolete: true
Attachment #123312 - Attachment is obsolete: true
Attached image new screenshot
Attachment #121930 - Attachment is obsolete: true
bug: strings containing HTML sequences, for example <p>, aren't properly displayed.
Assignee: endico → nobody
To ever get this checked into bugzilla, i suggest following:

1. Since there are already several (bug 203709, bug 130835, bug 109692, 
   bug 142101) alternatives to bugzilla frontpage, a configuration parameter 
   should be made:
   Bugzilla_frontpage, with selection alternatives:
    * simple (meaning the ant picture)
    * product list (meaning bug 142101)
    * statistics (meaning bug 130835)
    * bugs, based on user (meaning this bug)
   For now it could only contain simple and this bug

2. Make it easy pluggable, and give it a distinctive name (like 
   bugs_today.html.tmpl)
   Meaning, that the cgi, that is needed to show, should be called from existing 
   index.cgi, and template should be includable in index.html.tmpl

Otherwise i can't see here no solution. This way it could be checked in with no
big pain, and admin should decide, whether use the inexpensive simple page or
more expensive (in means of sql selects) other variants

Added gerv to cc, in hope that he will add some comments to this.
Also - Arne - let us know, that you are still in this, and if so, maybe assign
the bug to yourself. Otherwise i am willing to take this bug, since this variant
of bugzilla frontpage is already implemented in my bugzilla.
I'm not convinced we need a parameter. We already have a way of changing the UI
- it's called templates :-)

I think that we'd have a better chance of all these ideas not colliding if they
gave up their claim to the front page. After all, users can bookmark any page
they like as their main Bugzilla interface. So, if these different sorts of
views were just different available CGIs and templates, people could just pick
the one they liked.

Gerv
depending on way how company is organizing it's work, choice of bugzilla
frontpage can be very important (because of dummy users, who can't find a bug if
it is no more on frontpage (the same applies to documents in 'recent documents'
list))
so i think, that bookmarking a particular url and then using it, instead of
writing in bugzilla.something.com in location bar, would make it my life more
complicated. 

also - bugzilla should look equally for all users, so they can understand
themselves, when they talk and say 'go to bugzilla, and click on the big red
button' aso.

so i think, that this is a choice of administrator, not user (of course, he can
code something to make it work also for user).
and if it is choice of administrator, then changing the frontpage would mean
hacking index.cgi, which is bad. so i offer to use a parameter.

also - this differs from standart customizations - like putting in company logo,
or something, because it changes .cgi files.

so - what you say - how about bugzillafrontpage parameter?
Dave: what do you think?

Gerv
(just throwing out ideas)  I think Myk's new extension hooks mechanism would be
a good thing to port into the home page for this purpose.  We should come up
with a naming convention for the hook templates so you can disable them without
removing them from the directory.  Drop the current home page and a few of these
alternates in with the alternates disabled...  then the installation can mix and
match what they want for it.
i don't know nothing about the hooks mechanism - could you please give some links?
The hooks mechanism's code (and bug discussion) can be found at bug 229658. The
documentation bug is bug 230742.

http://bugzilla.mozilla.org/attachment.cgi?id=139303&action=view is the initial
draft.

The final version of the docs can be found at
http://www.bugzilla.org/docs/html/cust-hooks.html .
I'm not convinced about Dave's "disable naming convention" (unless you mean have
them not end in .tmpl, which would work), but I think this may well be a good
opportunity for hooks. In general, hooks are for customisers and extension
authors, but it'd do no harm to have one example of hook use in the tree, as a
demo, and the front page seems like a good choice.

The issue there, though, is how do the hook templates get the info they need to
display all these alternate funky front pages? Either index.cgi needs to provide
all of it, whichever one they use, or we have to implement a "pull" mechanism
where you can get info by putting SQL in templates. And that seems like a scary
road to go down to me.

Gerv
I don't like the hardcoded SQL in the frontpage cgi too. I tried to understand
how user queries are stored and executed but it was quite difficult, so I just
wrote straight SQL to get my data.

Maybe we can have a checkbox "display the result of this search on the
frontpage" near the "Remember search as ...." field? The frontpage code would
need to run the  named query for each query with this box checked, and display
the data.
Myk: this is the bug I was telling you about that we were discussing hooks on.
Formats work better than hooks for large-scale or wholesale modification of a
template.  Hooks are better for adding chunks of content to existing content in
a template, but the bugs on changing the Bugzilla home page generally propose
rewriting practically the whole page and supplanting content, which is what
formats are for.

Note that what Tom requested in comment 26 to kick off this discussion is what
formats provide along with a mechanism for configuring the default format, which
is bug 149061.  A hook example in the tree is a good idea (in lieu of a stable,
released extension using hooks, which would be even better), but I don't think
this is it.

As for templates pulling data, we've discussed the necessity of doing this for a
long time to improve performance and handle multiple formats with different
requirements.  Doing so doesn't mean raw SQL in the templates, however, but
rather a API for getting the data so the templates contain simple method calls
and the complexities are hidden away in Perl code (perhaps via TT plugins, or
methods hanging off the Bugzilla object).
Listing all products at the front page may include products with group
permissions set. These products should only be seen by logged in group members.
If you use product groups, you may want to apply the patch to exclude products
from the frontpage listing the user isn't allowed to access.
Are there plans to merge this with bug 130835? Its attachment 118851 [details] seems very
advanced to me.
Has anyone made the modifications for this to work on 2.19.1 ?

in index.cgi the line 
ConnectToDatabase();

needs to be removed and 

quietly_check_login('permit_anonymous');

is changed 

# Check whether or not the user is logged in and, if so, set the $::userid
use Bugzilla::Constants;
Bugzilla->login(LOGIN_OPTIONAL);
                                                                               
           
but that doesn't fix everything.  The only table I see is "Active products, open
issues".
OK the way to find the username has changed from
$::COOKIE{"Bugzilla_login"}) to Bugzilla->user->login

This new index.cgi works for me on 2.19.1
 
frontpage.cgi seems to be broken in v2.22rc
Blocks: 130835
QA Contact: mattyt-bugzilla → default-qa
This is a very popular mod, that is used by quite a few people. Would it be possible for someone to get this working with release v2.22, and post a patch, or a tarball with the code. Thanks.
Attached file frontpage-2.22rc.tar
I was able to modify frontpage.cgi enough to work with the new 2.22 release. So I created a tarball with the new frontpage.cgi
Attached file frontpage-3.0.tgz
Created a version of Frontpage (ToDo List) to work with Bugzilla version 3.0
I still can't figure out how to assign this bug to myself. I must not have the right permissions. 

To install,
Copy the frontpage-3.0.tgz file into you main bugzilla directory (ex: [localhost@bugzilla-3.0/]#)
type
# gunzip -d frontpage-3.0.tgz
then
#tar -xvf frontpage-3.0.tar

This should unpack the files to the proper locations with in the Bugzilla installation.
Andrew, if you want to post that as a patch instead of a tarball, and ask for review according to the Contributor process ( http://wiki.mozilla.org/Bugzilla:Developers ), it's possible it could make it into the actual Bugzilla codebase at some point.
Assignee: nobody → monsterscarry
As I wanted to see what it looked like I took some time to implement it on my current bugzilla test installation (3.4.4).

I had to iron out some minor things in order to get it working (moving url_quote from cgi to the template file using the FILTER url_quote directive as well as tidying up the includes in frontpage.cgi).

I did not modify the conflicts to template/en/default/global/common-links.html.tmpl the original author implemented.
Attachment #419450 - Flags: review?(jonathan)
Don't ask yourself for review, but ask an official reviewer, see http://www.bugzilla.org/docs/reviewer-list.html
Attachment #419450 - Flags: review?(jonathan) → review?
(In reply to comment #49)
> Don't ask yourself for review, but ask an official reviewer, see
> http://www.bugzilla.org/docs/reviewer-list.html

Thank, just noticed I had done something wrong. Sometimes Bugzilla is a bit daunting especially when English is not your mother tongue. I have had a look through the list to see who would be the best fit. My guess would be the CGI reviewers, not sure who to choose as all three are in the CC list. Any suggestions?
Attachment #419450 - Flags: review? → review?(LpSolit)
I have updated the patch to add the required new files (no changes compared to previous patch) and to minimize changes to template/en/default/global/common-links.html.tmpl in order to have the Todo link in the header.

I have taken the liberty of re-arranging the original layout (included in frontpage.tgz) as I think the Home and New item deserve to be in front of the Todo. Therefore I placed the Todo link inbetween New and Search.

I would like it very much if this could be incorporated in future releases f bugzilla as it directs users to tasks they could do without much searching. IMHO this could be the homepage for logged in users, but I leave that to the powers that be. :)
Attachment #419450 - Attachment is obsolete: true
Attachment #419458 - Flags: review?(LpSolit)
Attachment #419450 - Flags: review?(LpSolit)
Sorry, once more. I noticed the link to Todo was also visible when not logged in, since it is of not much use in that state, I added some logic to only display it when logged in.
Attachment #419458 - Attachment is obsolete: true
Attachment #419460 - Flags: review?(LpSolit)
Attachment #419458 - Flags: review?(LpSolit)
Assignee: monsterscarry → jonathan
The work being done here should be consistent with the main plan of bug 130835 (CC'ing pyrzak). Should this one be marked as a dupe of bug 130835, or do they really have different goals?

In all cases, I don't think we want another frontpage.cgi page. frontpage.cgi *is* index.cgi, as I understand it. pyrzak, mkanat?
(In reply to comment #53)
> In all cases, I don't think we want another frontpage.cgi page. frontpage.cgi
> *is* index.cgi, as I understand it. pyrzak, mkanat?

That is fine by me, I could rework this to be a addition to the index.cgi page if that might be the desired goal.
yup, dup of bug 130835
Comment on attachment 419460 [details] [diff] [review]
Patch replacing frontpage.tgz files and updated to v3.4.4

good start on this. a Few comments, the patch should be against the head. And the statuses should not be hard-coded as part of the sql query since they can be dynamic. Also this is a dup, Assigning the other bug to you
Attachment #419460 - Flags: review?(LpSolit) → review-
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
(In reply to comment #57)
> 
> *** This bug has been marked as a duplicate of bug 130835 ***

A pity this is marked as a duplicate as it might be an alternative mockup. Should I make a remark to this in bug 130835 to keep it from being lost?
We don't want an alternate mockup nor another page. We want a single page with a single UI. This means the code must go into index.cgi and template/en/default/index.html.tmpl. Don't forget to base your work on the current 3.5.2+ (a.k.a HEAD) code.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: