This pull-request allows prioritizing issues.

Each priority level is stored in the database as integer and the conversation int -> label is then saved in the project's settings.

I think something is amiss here. The pull-request title and description talk about pseudo-namespaces, but the code (and the branch) both refer to ticket priorities and don't have anything to do with pseudo-namespaces. Maybe a typo when issuing the PR?

Should not merge this until that gets sorted out.

Oupsy, let me fix that and open the pseudo-namespace one as well :)

This is currently NOT ready to be merged as it needs a little input from @ryanlerch so that we can not only filter by priorities but also sort.

Added a PR to be merged into this branch:

https://pagure.io/pagure/pull-request/874

it adds:

• sorting to priorities for issues
• new styles for the priority editing in repo settings

as mentioned in the PR#874, one thing i noticed while playing around with the stuff in the settings: if you manualy enter in a new prioroty that has the same weight as an existing one, it overwrites the existing one -- we really should check this and warn the user.

Two more thoughts on this one:

It might also be a good idea to not show the Priority column in issues if no priorities are set up, or

Should we have a default set up of priorities, and then add the ability to turn priorities on and off as a whole? This way we can set the prioroitys to default off, but then when turned on, have a default set ready to go?

It might also be a good idea to not show the Priority column in issues if no priorities are set up

:thumbsup: for me

Should we have a default set up of priorities, and then add the ability to turn priorities on and off as a whole? This way we can set the priorities to default off, but then when turned on, have a default set ready to go?

It's an idea but that woulf mean storing an additional flag for priority on/off.
What about having a button in the settings page filling a set of defaults priorities automatically, then people could just do: Add default set and click on Update instead of entering them by hand. Do you see what I mean?

I think we're good on this now, just need to add some unit-tests

It might also be a good idea to not show the Priority column in issues if no priorities are set up

👍 for me

Should we have a default set up of priorities, and then add the ability to turn priorities on and off as a whole? This way we can set the priorities to default off, but then when turned on, have a default set ready to go?

It's an idea but that woulf mean storing an additional flag for priority on/off.
What about having a button in the settings page filling a set of defaults priorities automatically, then people could just do: Add default set and click on Update instead of entering them by hand. Do you see what I mean?

+1 for this idea. But only show the button for filling with defaults if there are no priorities set.

+1 for this idea. But only show the button for filling with defaults if there are no priorities set.

Ok I'll update for this.

+1 for this idea. But only show the button for filling with defaults if there are no priorities set.

Ok I'll update for this.

This is done now :)

So in this case, it's always choices=[]?

Do you need to make sure that this is an integer?

The break between this and count=False could be removed.

This could probably cause a KeyError.

Example:
1. I create a set of priorities with {1: 'high', 2: 'low'}
2. I create an issue with priority 2 ('low')
3. I update the project priorities to {1: 'high'}
4. The issue.priority is no longer a valid key in repo.priorities.

Also, isn't the key to repo.priorities an integer?

As far as I could see you're only setting the keys with weights = [int(w) for w in weights], which would make for integer indexes. So why the "| string" as key into repo.priorities?

You should use "is None" per pep8. But why do you explicitly compare this, since "if issue.priority" should give the same result?

Why do you add the () to string here, whereas you don't for the previous case?

See comments on previous case of priorities[issue.priority | string].

You could write this as $.ready

s/Here below/Below/

Sorry, but I don't really understand what this means. Maybe a simpler way to represent it would be "Priorities are shown from lowest to highest weight"? (or the reverse if that's the case... I really can't parse this).

Yes, the choices are filled just below, in the __init__

So the KeyError: jinja will ignore it so we're fine there

For the string, it's true until the data is retrieved from the DB, then the JSON
converts the int to string.

Right, that's what I figured. I just wondered why you're having such a complex way to return [].

Okay, great that that's checked at least.

And I didn't know before, but it seems like json objects are always stored as string:object yeah... thanks for the lesson!

For some reasons, I've been using this construct for a while, iirc earlier version
didn't work. Maybe something to test again in the future

Should have been done before, but better safe than sorry

I just dropped this since we don't sort issues by priority by default

ack

Thanks, I'll rebase and merge :)