A way to hide tasks so only relevant Client Jobs are displayed

[greg_zielinski]

I'm reach out to see how people are addressing this.

For example, I have a Client job called "Visual Studio 2012" but it is a list of tasks including the Quick Depoy task "Install Visual Studio 2012".  The thing is, our technicians locate the jobs and are never sure which to run.  I'd like to say "the icon that looks like a clipboard" so they only run the Client Job but not EVERY piece of software we deploy is nested inside a Client Job.  I don't want to create a client job for everything either.

 

I've tried created a folder "ZZZ - Called Tasks - Do not run" in hopes that placing all my called tasks inside this folder, when you search they would appear at the bottom  of the list and inside a folder labled "do not run".  Hasn't helped :(

I don't want to rename the "install visual studio 2012" task to something like "install software #001" so it doesn't appear in searched. 

In a perfect world, I would have a "hide from searches" toggle for the task.

 

Has anyone tried to address this in any creative ways I'm not thinking of?

 

 

 

[SK]

OK, have a folder for your jobs and a folder for the tasks that are used by those jobs.

Allow your techies read access to the jobs folder only.

[HighTower]

We struggled with this and have submitted Ideas and Product Enhancements to allow for Tasks to be hidden but it's not implemented.  If you change the security on a Task to remove its visibility from users then it also breaks their ability to run it inside of a Job.

For those tasks that we never want run outside of a job we've prefixed them as "zInternal_Task -" so they all sort together (at the bottom of the list) and hopefully they see the deployment job up higher.  I suppose you prefix all of your job tasks with something that's meaningful for your environment.

[greg_zielinski]

I'll give that a shot.  I was concerned that might prevent them from being able to run it.  But I gather you are talking about the "Read" permission and not the "Run Task" permission.

[SK]

That is correct.

[andykn101]

I almost exclusively use Policies with a 00:00 No repeat schedule so the run ASAP with a Filter for the app as a target. Techs only have access to the Filters not the Policies and can only see Filters for software released to the business.

Pre reqs and updates are all in the Policy using the appropriate Dependencies.

[greg_zielinski]

So to install an application for someone, the tech just adds them to the filter for that software release?

Meaning you need to wait for the target to refresh it's contents from the filter and then for the agent to check in?  Or do you have standard operating procedures in place for accelleration of the job?  Meaning, a forced delta update and then a forced config update on the agent?

 

 

[HighTower]

We tried this and jobs failed.  In our implementation if the executing user couldn't "read" the job then it wouldn't run.  I guess we'll have to revisit this.

[SK]

OK, I have just tried this and can confirm that without read permissions to the tasks, the job will not load its contents for the role.

[andykn101]

Yes, just add the computer to the filter. Our users don't expect instant delivery, 24 hours is the SLA but we have a one hour config update, 30 mins resource update interval and no hierarchy.

The techs know they can ring me if there is a genuine need to speed it up and I can use the RAAD tool.

[HighTower]

I've brought this up repeated with the PM team.  Along with the option of not creating clones of tasks when cloning a job.

 

[m.taylor]

For this issue I decided to take a page out of Symantec's book, change the folder's Attribute. I've been playing with this for a while now, it works very well and is very easy to setup and maintain.

Create a new folder in Jobs and Tasks and allow all the normal read, execute, etc for the roles who will be running the jobs. In this example the folder's name is "ZZZ Hidden".

Create a new task of type "Run SQL Query on Server" and in the first enter the SQL update command of "Update Item Set [Attributes] = '1' where [Name] = 'ZZZ Hidden'" and name it Hide Helper Tasks.

Create a second of the same type and enter: "Update Item Set [Attributes] = '0' where [Name] = 'ZZZ Hidden'" and name it Show Helper Tasks.

Put these 2 tasks in an area that only your Quick Delivery task creators can access and not other support groups.

Move your Quick Delivery tasks into ZZZ Hidden, run Hide Helper Tasks and refresh the Jobs and Tasks page. Folder's gone. If permissions for the folder are correct your Support team can still see the tasks within the job's list and execute the job but can't directly load/execute the task without taking the extra effort to do a search in the global search in the top right of the web console (does anyone use that search?).

This has been tested on Symantec Management Console 7.1 SP2, not 7.5.

Attribute List from fnGetItemAttributes in the database:

Attribute = 0
'Normal' - 'The item has no special requirements or constraints.'

Attribute = 1
'Hidden' - 'The item is hidden. It should not appear in the UI and is used internally by the NS.'

Attribute = 2
'NoModify' - 'The item is readonly. It cannot be Modified. This overrides any permissions on the object.'

Attribute = 4
'NoReplication' - 'The item will not be replicated to other servers in the hierarchy.'

Attribute = 8
'RunTimeLocalized' - 'No longer used.'

Attribute = 16
'NoDelete' - 'The item can not be deleted.'

Attribute = 32
'NoClone' - 'The Item can not be cloned.'

Attribute = 64
'HiddenOnEmpty' - 'This attribute only applies to Folder items. The folder item is hidden if the folder is empty.'

Attribute = 128
'NoExport' - 'This item can not be exported.'

Attribute = 18
'Readonly' - 'NoModify + NoDelete'

Attribute = 256
'System' - 'The item was created as part of a product installation (as opposed to being created by the user)'

[SK]

Nicely done.  I was going to offer that method by using direct sql access, as I had forgotten about the "Run SQL Query on Server" task type.

Its a shame that this issue is being caused by the way the security framework has been designed, which is to automatically provide non-assigned read access to parent objects.  This change was made to make implementing your required security model much easier, and the only way I could see this scenario to be achievable is to include the ability to stop this feature when needed.

[greg_zielinski]

I like this alot!  I already have my called tasks in a folder that I named to end up at the bottom of the list.  Hoping that having it at the bottom and inside a folder called "do not run these directly" would be sufficient.

I just tried setting the attribute to "1" for that folder and it works like a charm.

 

I'm even going to use these on my retired tasks folder.