Not sure I understand, but why not create a global group for these users and give this group the view own permission only?

Sure, I could do that, but every time someone joined the company the administrators would have to remember to add them to that group. Since their permissions to the relevent projects are through default security schemes (everyone has access to a project for Gemini management requests/issues and to a project for general technical support), it would be greatly preferable if they could be restricted to only viewing their own issues if they aren't specifically granted greater privileges.

In fact it has just occurred to me that many of these users will have permissions to other projects ("real", customer project-related ones) in which they need to be able to see all issues, so adding them to such a global group wouldn't work. They should be restricted to only their own issues in just one or two projects out of many.

In that case a project group will work. Assign the "view own.." to that project group and add the users to it for the "view own" projects only.

FYI - In 3.6 you can specify a default global group for new users.

Well, yes, it would solve the issue of users needing greater permissions for other projects but it will still require us to add maybe 400 users through a project group to each of these two projects - not a very maintainable solution.

What would be really useful would be applying "view own..." to a global group and setting that as the projects' security scheme, but then, if a user in that group is specifically granted permissions through a project group that does not have "view own..." applied, then that greater permission level overrides the default.

This is not possible as there is no way to know to which project to apply it.

Maybe I'm not explaining myself very well, but as I said in my last posting, the "View own..." restriction would be applied to a global group that is used to provide the default permissions to a specific project. I don't understand your comment that there is no way to know to which project to apply it.

What I want to achieve is this:

• A Gemini instance with lots of projects
• One or two internal support projects that are accessible to all users (or all members of a global group) with default minimum permissions, including the restriction that they see only those issues they raised themselves
• A subset of users who also have access to some of the other projects - not restricted by "View own..."
• A smaller subset still of users who have greater permissions to the internal support projects (i.e the guys who work on those issues) who can see everyone's issues
  
• BUT - and this is the sticking point - I really don't want the administrators to have to maintain around seven hundred project group assignments to grant the bulk of the users access to the internal support projects

See if this helps:

Create a global group for the restricted visibility, lets call it Restricted.
Now assign the relevant permissions for that group (create issue, view own etc...). in the security scheme for the support project.

Create another group for the internal support and assing it the relevant permissions (say admin issues) in the security scheme for the support project.

With 3.6 you will be able to specify that new users will belong to the restricted group and that should be it.

I think the problem you are having is that you are using 1 security scheme for all projects, is that correct?
If so, please consider creating multiple securtity schemes.

No, I've created a separate security scheme for the internal support project so that I can provide default permissions to that project to anyone with a Gemini user account. That can then be overridden by granting permissions to the same project through a project group. All well and good so far.

However, there's this other "permission" in the list which is "View own..." but, unlike the others, it doesn't get overridden.

I guess the issue is the sense of "View own...". All the others give greater permission, so a user granted basic permissions through a global group may then be granted additional permissions on top through a project group. Once "View own..." is assigned, however, that's it - the user can only see their own issues unless they are removed from the restricted group.

If the sense of "View own..." was reversed, so you grant "View others'..." instead, then the default could be to restrict the user (by not assigning this permission), but that could be overridden for a subset of users through project groups in the same way, say, "Edit issue", etc. works. It even makes sense now to call "View others'..." a permission whereas it doesn't when it's a restriction!

Bottom line is, I can make things work by creating a restricted group and the default facility in 3.6 will help (though I have exactly that functionality now through a database trigger I added). But on the rare occasions that a new user is created who then needs greater permissions in that internal support project, the administrators will have to remember that they have to remove the user from the restricted global group to allow the user to see all issues. We now have over 800 users, of which 20 or so have greater permissions on the internal support project so, even with a significant turnover in staff, that's not going to be a common event so my money is on them forgetting and then wondering why the account doesn't work as expected...

Can you please send an email to support at countersoft dot com? We will arrange a GoTo meeting session to see if we can sort this.