Feature Requests


Custom Configuration Profiles

Posted: 17 minutes ago by davidacland

Hopefully this isn't another duplicate!

There's quite a few custom config profiles people are making with mcxtoprofile.py etc. It would be great if some of these commonly used options could be added to the web interface. Main ones that spring to mind are:

  • Control over the menu extras (i.e. whats visible and whats not)
  • Microsoft Office settings
  • Supress iCloud setup assistant
  • etc...

I'm constantly adjusting peoples rights in the JSS. It would be really nice to be able to view the JSS as a certain user in order to see it like what their user would see. This way, I could adjust accessibility, and make sure they have all the rights they need to complete whatever tasks I need them to.

Set Removal Disallowed flag in MDM configuration profiles

Not Planned
Posted: Today at 3:14 PM by Sonic84

Mac OS X 10.10 now honors the Removal Disallowed flag in MDM profiles. Since the JSS defaults all profiles to "yes", this prevents local admins from removing select profiles terminal or System Preferences. it would be great if I could set this to "no" in the JSS to allow local admin to remove select profiles. My primary example for this is user level certificate payloads. If the user deletes their login keychain, whey will never receive a new user cert as long as the MDM payload remains on the system.

Not Planned Responded: 53 minutes ago by erin.miska

This is available for Self Service profiles but not for profiles installed automatically. If we were to allow that and then someone deletes a profile from System Preferences but the computer is still in scope for the profile, the JSS would just re-install it the next time inventory is submitted and the profile is reported missing. The best way for IT to remove an installed profile is to remove the computer from the scope.

It is currently impossible to view which scripts, extension attributes, or other areas like dock items of their last modified dates or even when they were created. It would be great if this was built into the view so that administrators could quickly sort them for troubleshooting purposes. This would be great to have in the JSS and in the JSS.

We are currently trying to figure out why there is a random file being generated throughout our devices but are having to go through each script 1 by 1 to review it for possible changes made.

5

Comments

Show where a smart group is used

Under Review
Posted: 1/28/14 at 2:54 PM by kschlatter

We have been doing some cleanup as we get ready to move from 10.8 to 10.9. Since we are trying to use this time to switch as much as possible to config profiles, we creating new clean smart groups for 10.9 machines. Are old smart groups aren't as organized though and at one point some people were using them for reporting, but not actually scoping them to policies. It would be great to go into a smart group and have a "where used" option. That way we could check the policy that is using it without having to audit everything. We are currently running JSS 9.22.

This goes into the ever growing "Sites need to be as separate from each other as possible" bucket.

In a multi-site environment, please allow each site to deploy the same App Store App without having to alter the display name.

We have multiple sites, each with different admins. The site admins cannot see anything that the other site admins have done, including what apps are being deployed. If one site has already deployed an app, another site wanting to deploy the same app will receive a "Duplicate" error on the display name. The only fix is to alter the display name to something else which is not ideal.

For example:
Site 1 decides to deploy an app, such as Evernote. This is the first site to deploy this app so there are no issues.

Site 2 then decides to also deploy Evernote to their users. When clicking on "save" they receive a "duplicate" error on the display name. This is confusing to the admins since they do not know that another site has already deployed the app. If they alter the display name to something like "Evernote-2" then they can deploy the app.

Although this is an interesting mini-game for sites (who can get the app name first!), it's not ideal.

I discovered you are not able rename a Smart Groups' Display Name if its used (or "nested") within another Smart Group.

It was determined that the back-end query behind a nested Smart Computer Group uses the "Display Name" column, thus if you try to change the Display Name and then save, you will get an error. According to my JAMF TAM, the fix for this is to change the back-end query to use the Smart Groups' "ID" column (not the Display Name). This actually should be a more consistent way to do this as the Smart Group ID value should never change within the database.

I know this is small item, but fixing little quirks like this will allow this tool to become more flexible as people continue to use it in different ways.

Thanks!

9

Comments

Being able to scope Self Service Plug-Ins

Under Review
Posted: 3/20/12 at 9:48 AM by Chris

I have a number of Self Service Plug-Ins that not all computers shall receive.

I'd like to be able to scope them directly in the Computer Management Framework Settings
rather than having to repackage them and distribute them via a policy.

54

Comments

Casper 9 full logs have gone

Planned
Posted: 8/30/13 at 2:23 AM by lkerwin

Hello,

We were very happy to upgrade to version 9 that has some major changes to the user experience, this was all good but I was slightly disappointed when I noticed the all log feature has been removed. Apparently you can only check logs for single computers were as before you could show logs for all.

I would like to request this feature for future updates as this was essential for us when checking, for example if a bunch of machines have been successfully imaged or not.

Regards.

Many thanks.

Regards.

Either allow full CatalogURL to be set for a "Software Update Server", or completely remove the feature so that we are not tempted to rely on it. Hostname and Port alone just doesn't cut it.

Currently those valid variants cannot be set in the JSS:

  • Custom Branch: http://my.swupd/index_testing.sucatalog
  • Usage of HTTPS: https://my.swupd/index.sucatalog


Thanks.