rebased
This PR is not up for review yet :smile:
1 new commit added
This pr is open for review and testing now :smile:
Did you rebase the migration script? (Try running alembic history to see what I mean)
alembic history
I think we dropped this, no? :)
hm, not quite sure to follow what we are filtering here
Isn't this also depending on pagure's configuration?
Could you just refresh my memory, why the second check here (if username is the current user?)
We may want to add a comment here explaining why that is
There is one thing missing, but I'm willing to accept it in a different PR (assuming that work is started at the time this PR is merged), it's: documentation :)
work in progress :stuck_out_tongue_winking_eye:
for the user to view his private and public project if the second check is not there user will not be able to view his private project AFAIR , because I struggled with it and to be more precise it's your commit ;)
we are filtering public and private project of the specific user.
we are filtering: private == false OR private == true, so what's the third option? :)
Ah, I see. It's the other way around in fact, it's to prevent other users from viewing the user's private projects. Otherwise, I'm authenticated, viewing your page and seeing your private repo.
Maybe we should document this in a comment since we seem to easily forget :)
Thanks for pointing out , this slipped my mind !
s/pivate/private
Should this be moved into pagure.lib? It's using a private method from that package.
pagure.lib
The name is a little bit weird since "project" and "repo" seem to be used interchangeably. The database model is Project, I believe, so it would be better to consistently use that. Maybe call the repo parameter "project_name" if that's what it is.
Something like:
Retrieve the project, taking into account user permissions :param session: The SQLAlchemy session to use :type session: sqlalchemy.orm.session.Session :param project_name: The project name :type project_name: str :param user: A Pagure user :type user: str :param namespace: A Pagure namespace :type namespace: str :return: The project object if the repository is public or if the user is authorized to view the private repository, otherwise None is returned. :rtype: pagure.models.Project
I should note that I'm not sure what documentation formatting @pingou prefers. NumPy/Google style doc strings can be handled by the Napoleon sphinx extension and look like:
Args: session (Session): The SQLALchemy :class:`Session` to use project_name (str): ... Returns: pagure.models.Project: The project object if the repository is public or if the user...
Which many consider to be much more legible
Looking through the PR, it seems like all the uses of pagure.lib.get_project have been replaced with this. Would it make more sense to simply make that function aware of private repos?
pagure.lib.get_project
At the beginning it was to make sure we're always checking for private repo so we renamed the original method, making sure it would break for everyone except those who really wanted/needed the old method (and were thus adjusted).
However, now that I think about it, we could just have rename the old method _get_project and create this method as get_project in pagure.lib automatically moving everyone to this method.
_get_project
get_project
This should make the change set much smaller as well since only a few method will have to call the old _get_project.
I remember this was something @puiterwijk discussed, so his input might be nice in case I am mis-remembering.
I like the first style more :)
@pingou that was exactly the case, and I think the main reason it was split out as a separate function was because it should be touching the users' login session, to check if they have access, and you didn't want stuff in pagure.lib accessing that, as they should be framework-independent.
That sounds like something I would say indeed :)
Thanks @puiterwijk, I had forgot that aspect
@pingou @jcline This is up for review :smile:
you don't need to start with a different column. You can simply do nullable=True, then set the value and then do nullable=False.
nullable=True
nullable=False
80 char
80
namespce=namespace
namespace is not specified here
namespace
Too much indentation.
Do you need to end with closing colon or not?
It doesn't need to, because this is a repo object, not a repo name.
How about instead of adding this check to tons of places, just have the notify.log check project.private?
I am ending with a colon
out of the 4 places you have revision id, at least one is wrong
you probably don't need new_column_name
new_column_name
should we mention that these repositories would be visible to site admins?
[Project] ? when?
i don't know if this line actually crosses 80 char limit but, can you check it once? (since, you will need to change a few other things anyway.)
92 new commits added
_getrepo
is_repo_admin
it can return a list?
I wonder if we shouldn't bail if project is None now
Not sure if this is pep8 valid :s
This is likely needed in other places :)
?
same here :)
I don't think this indentation is valid pep8 :)
Don't we want to keep as it is?
I guess we can remove this one
And this one :)
Not sure we want to use get_authorized_project() here
Same here
same here
and here
I'd have put the new line after the opening bracket
here as well (as below)
except errors we normally use 2 spaces indentation in the html
One too many
isn't that already covered ?
We could keep using _get_project() in most of the tests
Basically I think it only make sense for the tests working with a private project.
Not sure what to do here
pretty please pagure-ci rebuild
This is the default hook, so we may want to use _get_project() here.
Also if project is None, is a use-case that is covered in the other hooks, so easy to adjust ;-) (But this could be done in another PR though)
new_column_name needs to be drop otherwise we're trying to rename private into private which will fail :)
private
s/user/users/
The name get_authorized_project is confusing me. It sounds like it will return any project, since it's an authorized call...
Shouldn't all hooks use _get_project anyway, since they're run by the project owner during push? The flask session will probably always be None, so otherwise we'd be breaking all hooks....
And another hook.
93 new commits added
@pingou
Someone just pointed out that Pagure private issues email mentioned people even in private tickets, and I think this might be the same in private projects. We should make sure that that doesn't happen :).
@puiterwijk for tickets this was very much in purpose, the bit that is missing is to allow people that are mentioned to access the ticket.
Ok tests are passing, it has been rebased and @puiterwijk has agreed that we work on namespacing the private repo in a different PR.
So let's merge this one :)
Pull-Request has been merged by pingou
Thanks @pingou