You can't disable it, but you can make it a really bad choice. Depending on your environment, let's say you have 3 publishers, you could configure 2 out of the 3 machines, to only work on medium and low priority jobs, meaning that all high-priority jobs would be processed by a single server instead of all 3.
You can also configure your publishers to not pickup any high priority jobs, but this may result in end-user revolt and a complaint to SDL that "publishing doesn't work"...
See http://blog.building-blocks.com/technical-tips/filtering-prioritization-of-the-tridion-publish-queue for more details on what you can configure at the publisher level.
Obviously, the place to start is to fix your infrastructure and/or template performance so that publishing is fast and doesn't require your editors to use high priority. Probably worth looking into adding publishers and/or render threads based on your current issues, and a template code review always helps.
If you disable
High - then you essentially making
Normal the new
High; in which case you should perhaps be thinking about removing
low also - or even better re-consider why you want to remove any of the three options from the list.
Perhaps someone is under the impression that High priority publishing will affect anything other than how items are picked from the publish queue and actually published? (e.g. is there a more fundamental issue with Publishing times or simply with editors understanding or prioritisation?)
- Training / Informing
- Review publishing times (perhaps specific templates need work)
Perhaps you want and even keel for all users on a first come - first served basis?
- Training and/or GUI extension to remove the apparently unwanted items
Not really getting to the root requirement?
Perhaps more detail is required before rushing into removing something that has a proven, useful, real-world purpose.
It may be that you can't trust editors to behave as trained (which is a shame - as I've worked with many small and large organisations and found editors to be great at conforming once they understand and agree with the rationale of a way to work).
Get more info:
- Speak to the editors - why are they using
- Speak to the business - what constraints can they really live with? (e.g. not having the ability to escalate one publish over another may be a step too far)
- Speak to the editors - why are they using
- if your analysis deems it necessary to hide priorities - does it need to be hidden for everyone, on specific publications, for specific content types?
- can you use configuration and/or groups to expose to only thise that the business feels should be allowed to select
On a closer re-read, it seems you may even want to only disable high-priority publishing when the specific scenario you quote is encountered
publishing for all publications and all targets
In this case - it certainly sounds more like a GUI Extension (and makes a little more sense). So your logic would seem to be
if (is parent publication) // I'd check this one for sure - what is a 'parent' publication and how do you determine it (naming convention, blueprint query - ouch) and if (publish children is selected) and if (all _available_ targets are selected) // may be tricky to 'define' that this means consistently across all publication THEN remove "High" from the available list // or leave it in the list and catch this (as Dom suggests) in the Event system - though may confuse editors but hey - they ignored the instructions anyway?
On the face of it ... sweet, that's that then.
- What if the user selects High and then goes as fulfills your condition?
- I believe you would want to prudently be certain that you don't want to catch these conditions with an OR
- You need to consider all the different interactions possible in this part of the GUI - and ask yourself lots of test questions such as 'when there is only one target' etc.
You could disable it as follows:
- Create an events system that intercepts all publish actions, and if they are High, modifies the priority to Normal (or even Low - or would that be evil? :-))
- Create a GUI extension that removes the High choice from the user interface.
However... as others have noted, then you've only shifted the problem to the Normal priority. It's a classic Tragedy of the Commons. and the best solution is probably a social one.
So don't start building an events system just yet. Instead, get your end users together and get them to figure out how to use this shared resource. Explain that publishing on High is the moral equivalent of pushing in at the front of the queue. Educate them in how to look at other items in the queue to identify which users will be affected by their pushing in. Also educate people to use Low for those big non-urgent jobs, and just generally be a good citizen.
Finally - explain that it's the System Administrator that has the big guns, but as with all guns, they only really work in destructive mode. If a super-high-emergency-priority job comes in, and the queue is full of High priority items, all it takes is a phone call from the CEO, and the System Administrator will just delete all those blocking jobs from the queue. But then, of course, all the people that had parked in the fast lane will have to figure it all out and publish things again. But if you only ever publish on Normal - this will never need to be done to you.
- Probably create a custom page in notifying the user to use priority Low or Normal and use High until unless if business needs it real quick.
- Make the publication target publishing priority to "LOW" by default(I guess this is already in place).
- Finally a GUI extension as others suggested but this would create a bottle neck again as Normal becomes High priority.
On the whole its better to educate the users on prioritizing the publishing process.