"Deploying Obsidian: How to restrict features for employees"

This title was summarized by AI from the post below.

We're considering ways that IT departments can more confidently deploy Obsidian to employees and students. What do you think about this approach? 1. New policy.json file with options for disabling community plugins, themes, Sync, Publish 2. Command line options for --policy-file "path/to/policy.json" 3. Command line options for --policy-json "{json contents}" 4. Environment variable for OBSIDIAN_POLICY_FILE and OBSIDIAN_POLICY_JSON same as the command line options

  • 1. New policy.json file with options for disabling community plugins, themes, Sync, Publish
2. Command line options for --policy-file "path/to/policy.json"
3. Command line options for --policy-json "{json contents}"
4. Environment variable for OBSIDIAN_POLICY_FILE and OBSIDIAN_POLICY_JSON same as the command line options
Michalis Efstratiadis

Technical Operations Manager at One Net Group

2mo

A json file in a system protected path (where the user cannot change) is perfect. I would like to see different levels (enforce, recommend). Finally, some plugins are really useful for office work, so I would like to have lists of allowed/blocked plugins.

Øystein Baarnes

Senior IT Engineer at One Net Ltd

2mo

How to enforce the policy if it's specified on command line / env. ? Perhaps better if the file is found in a predictable path that cannot be tampered with ?

Considering some plugins could be useful for businesses, how about an option to point to different source for the plugin list, instead of the Obsidian releases GitHub repository? That way businesses could define a subset of the plugin list that they have vetted for use in the business. It would also allow businesses to have internal repositories with plugins, so they can still be used in air-gapped environments.

Like
Reply
Ogechukwu Udoh

I Help Experts & Brands Grow Online Through Content Writing, Strategic Storytelling, SEO Optimization | LinkedIn Ghostwriting & Thought Leadership.

2mo

Having a policy file, plus the choice to use it through command-line or environment variables, gives IT teams flexibility. They can lock down plugins, themes, Sync, or Publish depending on what’s allowed, while still keeping the deployment process straightforward.

Like
Reply
Daniel Sept

Entwicklung neuer Systeme und Datenanalyse, um einen Mehrwert zu schaffen.

2mo

Good Idea, I think the community plugins are some of the greatest reservations against Obsidian in business environments. Thanks for your work, I really appreciate obsidian.

Like
Reply
Joaquim Ley

Building mission-driven products with software.

2mo

It's "OK", although I personally dislike this JS/TS approach of every tools has its own config.json file. Small suggestion tho, I would not name it "--policy-json" as the file can/will be json can lead to confusion. maybe just --policy?

Like
Reply
Dustin Sedlacek, PMP

PMP | Project Manager | 📊 Budgets • 🗂️ Systems • 🗣️ Customers | Delivering Accountability & Results for 20 Years

2mo

Based on what I know this is good. I should remain as simple as possible to keep Obsidian accessible to as many people as possible.

Like
Reply
See more comments

To view or add a comment, sign in

Explore content categories