Reviews are being mysteriously marked as submitted

[Steve]

We're running RB 1.7.6.  I've had several users report their reviews have been marked as submitted, and I've seen it as well. As an experiment, I asked a user without admin or superuser rights to mark one of my reviews as submitted and they were able to do so.  This raises these questions:

1. Should that be possible, or is something wrong with my site?

2. Is it configurable, and if so, how do I configure things so only the owner or admin can close a review?

3. Is can mine the database to see when a review gets changed from pending to submitted, but I can't figure out how to determine who made the change.  Is that possible?

I've searched our cron jobs to see if we had scripts closing  reviews automatically, but we have nothing doing that as far as I can see, and it seems unlikely that someone would mark a review as submitted accidentally, so I'm quite stumped by this.

Thanks

--Steve

[David Trowbridge]

Normal users should not have the ability to close others' review requests.

You say these users are not admin or superuser. Do they have the "can change status" permission enabled?

-David

--Steve

--
Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to reviewboard...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
---
You received this message because you are subscribed to the Google Groups "reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Steve]

The box on their user page entitled 'chosen user permissions' is blank.

--Steve

[Steve]

I'm  I just had another user report this same problem: 

"""

Here’s the issue; after creating a new review and updating and publishing it via the Review Board ‘Outgoing Reviews’, within an hour or two I’m finding  that the review is being marked as submitted without me having done so. I don’t submit a lot of reviews but I’ve noticed this happening on the my last two reviews at least. I’ve talked with other team members and no one has indicated that they submitted the change.

"""

I'm not seeing anything in the rb logs and am completely stumped.  Any ideas on how I can debug this?  It's so bizarre.

--Steve

[David Trowbridge]

This is incredibly strange. Web server logs may let you see if there are any API requests that could be causing this, but it's probably pretty hard to find in the noise.

Do you have any custom modifications or extensions or is it purely the released version?

-David

[Steve]

We have a custom authentication backend we use to authenticate via ldap.  Other than that, it's out-of-the-box.  The server is brand new, so RB 1.7 was newly installed.  However, our database schema has migrated from 1.0 to 1.5 to 1.7.6.  Any chance of an old configuration setting in the database having any impact on this?

--Steve

[Steve]

I'd like to back up and break this down into smaller, simpler questions.

When I go to my 1.6.9 RB server and browse to another user's review, I see these buttons along the top, right portion of the page:

        Download Diff    Review    Ship It!    View Diff

When I go to  both of my 1.7.6 servers and browse to another user's review, I see these buttons along the top, right portion of the page:

        Close    Update    Download Diff    Review    Ship It!    View Diff

I only see the 'Close' button in 1.6.9 when I'm viewing my own requests. 

So, is that an intentional change in RB 1.7, or is my site somehow misconfigured?

Thanks!

--Steve

[Christian Hammond]

Hi Steve,

Are you set up as an admin on both servers? Or do you have the Can Close privilege set?

If so, 1.7.x should behave the same as it did in 1.6.x (and certainly does in our installs).

Christian

[Steve]

I do not have staff or superuser set for this account, nor any special mod permissions.  And everyone here also sees the same 'Close' button on other people's reviews.  So, something is configured.  I wonder if there's an old database setting that we've been pulling along since the 1.0.x, 1.5 days that's causing this.  Do you have some ideas on what db tables I can look in for clues?

--Steve

[Christian Hammond]

Hi Steve,

There's no special flag for this. We implemented this functionality pre-1.0 and it has never changed. The only way you ever see Close or Update is when you have superuser privileges or the Can Edit/Can Close privileges. I'm not aware of this ever regressing or changing throughout the history of Review Board.

Both the UI and the API for handling those commands check these privileges in order to show/allow the operations. There isn't a single point of failure here.

The only other way that this could be set is if somebody modified the code you're running at some point to hard-code these privileges.

Christian

-- 
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org

Beanbag, Inc. - http://www.beanbaginc.com

[Steve]

I just went to a friend's desk and verified he sees the 'Close' button on other people's reviews.  Here are his user settings in the DB:

          id: 7

    username: xxxxxx

  first_name: xxxxxx

   last_name: xxxxxx

       email: xxxxx

    password: xxxxx

    is_staff: 0

   is_active: 1

is_superuser: 0

  last_login: 2013-05-15 06:59:15

 date_joined: 2008-07-25 09:25:54

What table would I look in to see if he has specific "Can Edit/Can Close privileges"?

The only custom code we have on our servers is a customized ldap authenticator.

Thanks!

--Steve

[Christian Hammond]

It's auth_user_user_permissions, which will map user IDs to IDs in auth_permissions.

Alternatively, you can do:

    $ rb-site manage /path/to/site shell

    >>> from django.contrib.auth.models import User

    >>> u = User.objects.get(username='youruser')

    >>> u.is_superuser

    >>> u.is_staff

    >>> u.has_perm('reviewrequest.can_change_status')

    >>> u.has_perm('reviewrequest.can_edit_reviewrequest')

(I believe those are the permission names.)

Christian

-- 
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org

Beanbag, Inc. - http://www.beanbaginc.com

[Steve]

Thanks for the example - I keep forgetting about rb-site shell.  It's nifty.  Here's what I get:

# rb-site manage /var/www/reviewboard shell

Python 2.6.6 (r266:84292, Sep 11 2012, 08:34:23) 

[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2

Type "help", "copyright", "credits" or "license" for more information.

(InteractiveConsole)

>>> from django.contrib.auth.models import User

>>> u = User.objects.get(username="xxxx")

>>> u.is_superuser

False

>>> u.is_staff

False

>>> u.has_perm('reviewrequest.can_change_status')

False

>>> u.has_perm('reviewrequest.can_edit_reviewrequest')

False

[Christian Hammond]

Hi Steve,

I really don't know then. It must either be some weird bug in that install, or something funky and custom going on. Certainly, the behavior of not showing Close/Update is correct.

I'm curious if Close/Update even works on the old install.

Christian

-- 
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com

[Steve]

This is not a question - I'm just adding information to this thread as I continue to work on this in case it's useful down the road.

Quick summary - 

*  All of my 1.7.6 production servers using MySQL databases dragged along from the 1.1 days are exhibiting the problem where a user can close other user's reviews.

* My 1.6 sandbox / dev server using a sqlite DB was not showing that behavior.

* Today I upgraded the 1.6 sandbox server to 1.7.6 and it is NOT exhibiting the broken behavior.

Since all of my 1.7 production servers were installed from scratch on clean CentOS boxes, I have to work from here under the assumption that there's something either in my databases or in my custom authentication module that's causing this.  The custom auth module seems unlikely as it just checks the user name against our ldap server and also checks for certain group memberships, so I'm going to experiment with a clean database to see if I can reproduce the problem.

If I learn anything new, I'll post it.

--Steve