Have you ever tried to use a feature in Azure DevOps and suddenly hit a wall? You see an error, but it is not clear whether the problem is your license or your permissions. This confusion is common, but the difference is simple once you know what to look for.
Error messages usually tell the truth.
Messages like “Access denied”, “Not authorized”, or “You do not have permission” point to a permission issue. You have the right license, but your account is not allowed to perform that action.
Messages that mention “access level”, “upgrade”, or “this feature requires Basic access” clearly indicate a license issue.
The user interface is another strong signal.
If a feature is completely missing (for example, pipelines or repositories), this is usually a license limitation.
If the feature is visible but blocked when you click it, the problem is most likely permissions.
Some features are locked behind higher access levels. For example, creating pipelines or pushing code requires a full user license, while advanced testing features need an even higher level. If your access level does not include the feature, no permission change will help.
For a final answer, an organization admin should check two things: your access level in user management, and your permissions in project security. Together, these checks always reveal the real cause.
Sometimes one color palette just isn’t enough. Text colors usually need to be dark and readable, while highlight colors should be soft and subtle. By default, TinyMCE uses the same color palette for both—but with a small customization, you can fully separate them.
By replacing the built-in color buttons with custom toolbar buttons, you gain complete control over which colors are available for text and which are used for background highlights. This approach is ideal for platforms that care about accessibility, readability, and consistent visual design.
What this approach enables:
How it works:
You register two custom menu buttons—one for text color and one for background color—and apply styles manually using editor commands.
tinymce.init({
selector: '#editor',
toolbar: 'textcolorpicker highlightpicker',
setup: (editor) => {
editor.ui.registry.addMenuButton('textcolorpicker', {
text: 'Text Color',
fetch: (callback) => {
callback([
{ type: 'choiceitem', text: 'Black', value: '#000000' },
{ type: 'choiceitem', text: 'Blue', value: '#2563EB' },
{ type: 'choiceitem', text: 'Red', value: '#DC2626' }
]);
},
onItemAction: (api, value) => {
editor.execCommand('ForeColor', false, value);
}
});
editor.ui.registry.addMenuButton('highlightpicker', {
text: 'Highlight',
fetch: (callback) => {
callback([
{ type: 'choiceitem', text: 'Yellow', value: '#FEF08A' },
{ type: 'choiceitem', text: 'Light Blue', value: '#DBEAFE' },
{ type: 'choiceitem', text: 'Light Green', value: '#DCFCE7' }
]);
},
onItemAction: (api, value) => {
editor.execCommand('HiliteColor', false, value);
}
});
}
});
When to use this approach:
Why it’s worth it:
Although this requires a bit more setup, it’s currently the only reliable way to enforce different color rules for text and highlights in TinyMCE—without confusing users or sacrificing flexibility.
When you write PowerShell scripts, strings may look simple at first. But sooner or later, you will face a small surprise: the $ character. In PowerShell, $ is special because it starts a variable. If you want to keep $ as plain text, for example inside JSON, you must escape it correctly. This short guide shows clear and safe ways to do that.
$ Needs AttentionIn double-quoted strings, PowerShell tries to replace $name with the value of the variable. This is called variable expansion. If the variable does not exist, the result may be empty or wrong. That is why escaping $ is important when you want the literal text.
Single-quoted strings do not expand variables. This makes them perfect for JSON and other text formats.
$body = '{"name": "$test"}'
This produces exactly:
{"name": "$test"}
$ in Double QuotesIf you must use double quotes, escape $ with the backtick character.
$body = "{""name"": ""`$test""}"
Here-strings are great for larger text blocks. To keep $ literal, use the single-quoted version.
$body = @'
{"name": "$test"}
'@
If you do not need variable replacement, always prefer single quotes. They are cleaner, safer, and easier to read. Double quotes should be used only when variable expansion is required.
iving users unlimited color options can quickly lead to inconsistent or hard-to-read content. TinyMCE allows you to define a custom color palette, so users stay within visual guidelines while still having creative freedom.
This is especially useful for platforms with shared feeds, collaborative writing, or brand-focused content.
Benefits of a custom color palette:
How to define custom colors:
Use color_map to control which colors appear in the picker.
tinymce.init({
selector: '#editor',
plugins: 'lists link code',
toolbar: 'undo redo | bold italic underline | forecolor backcolor | code',
color_map: [
'000000', 'Black',
'FFFFFF', 'White',
'1E293B', 'Dark Blue',
'2563EB', 'Primary Blue',
'16A34A', 'Green',
'F59E0B', 'Orange',
'DC2626', 'Red'
],
color_cols: 4
});
Users will now see only these predefined colors, making content look more cohesive across the platform.
When to use this approach:
Want to give users more visual control over their content without extra complexity? TinyMCE already includes built-in tools for changing text color and background (highlight) color—you just need to enable them.
These tools are ideal for short articles, notes, or mini-blogs where users want to emphasize key ideas or improve readability.
What this enables:
How to enable it:
Add forecolor and backcolor to the toolbar configuration.
tinymce.init({
selector: '#editor',
plugins: 'lists link code',
toolbar: 'undo redo | bold italic underline | forecolor backcolor | code'
});
That’s all. TinyMCE automatically provides a color picker that works well for beginners and advanced users alike.
Why this works well:
Images created with rich-text editors like TinyMCE often include width and height attributes. These values are useful because they describe how the image should appear. However, many layouts use global CSS rules like width: 100%, which silently override those attributes. The result is stretched images or broken proportions.
A better approach is to let both systems work together:
The key idea is simple. CSS should only force full width on images that do not define their own size. At the same time, height should never be fixed. Let the browser calculate it automatically.
This approach is safe, predictable, and works well for content feeds, articles, and mixed image sizes.
width and height keep their intended sizeheight: auto preserves the natural aspect ratioAvoid using object-fit: cover for normal content images, as it may cut off important parts. This solution keeps layouts clean, readable, and friendly for all screen sizes.
When PowerShell receives data from a web request, the real value comes from understanding what the response contains. Most web services return JSON, and PowerShell automatically converts this JSON into objects you can work with directly. This removes the need for manual parsing and allows you to focus on extracting useful information.
Learning how to explore these objects helps you debug faster, avoid mistakes, and confidently build automation that depends on external data.
When you run a web request using Invoke-RestMethod, the JSON response becomes a structured object. You can:
Think of the response as a structured document instead of plain text.
$response = Invoke-RestMethod -Uri "https://api.example.com/resource"
# See all available properties
$response | Get-Member
# Access a few common fields (example names)
$response.id
$response.status
$response.details.name
Sometimes it is easier to understand the structure when you see the data as formatted JSON again. PowerShell can convert the object back into readable JSON.
$response | ConvertTo-Json -Depth 10
This is especially useful when the data contains nested objects.
Large responses can be overwhelming. You can limit the output to only the first few lines for a quick preview.
$response | ConvertTo-Json -Depth 10 |
Out-String |
Select-Object -First 20
PowerShell automatically transforms JSON into usable objects. By exploring properties, viewing formatted JSON, and limiting output for quick previews, you can understand any response quickly and safely reuse the data in your scripts.
Have you ever run a command in PowerShell and wondered if it really worked or silently failed? Exit codes give you a simple way to know what happened. They are small numbers returned by a program when it finishes, and they tell you whether the task succeeded or not.
✔️ Exit Code 0 — Success
An exit code of 0 means everything worked as expected. The command or script completed without errors. This is the standard way most programs say, “All good.”
❌ Exit Code 1 — Error
An exit code of 1 usually means something went wrong. It does not always tell you exactly what failed, but it signals that the command did not complete successfully. Different tools may use this code for different kinds of errors.
How to check the exit code in PowerShell
After running an external command, you can read the last exit code with:
$LASTEXITCODE
How to set your own exit code
In a script, you can control the result:
exit 0 # success
exit 1 # error
Understanding exit codes helps you automate tasks, detect problems early, and build more reliable scripts. Even beginners can use this small feature to make smarter decisions in their workflows.
Good spacing makes a page easier to read and more pleasant to scan. But adding space before every heading can create unwanted gaps — especially when headings follow each other or appear at the top of a section. In this guide, you’ll learn a simple CSS technique to add space before headings only when it actually improves readability.
We want to add top spacing to headings when:
This keeps related headings visually grouped while still separating them from normal content like text, images, or lists.
Use the adjacent sibling selector (+) together with :not() to target only the headings that need spacing:
.app :not(h1, h2, h3) + h1,
.app :not(h1, h2, h3) + h2,
.app :not(h1, h2, h3) + h3 {
margin-top: 20px;
}
:not(h1, h2, h3) selects any element that is not a heading.+ h1, + h2, + h3 selects a heading that comes directly after that element.This means:
You can fine-tune the spacing for each heading level:
This gives you more control over visual hierarchy.
A small CSS rule like this can make a big difference in how professional and readable your pages feel.
Calling web services is common in automation, monitoring, and integration tasks. Many APIs expect extra information in the request, such as authentication tokens, data formats, or custom settings. This information is sent through headers. Once you understand how headers work in PowerShell, you can safely connect to most modern services and build reliable scripts with confidence.
Headers describe how the server should handle your request. They can:
Without the correct headers, a request may fail or return unexpected data.
PowerShell uses a simple key-value structure called a hashtable. Each key is the header name, and the value is the header content. This hashtable is passed to the request using the -Headers parameter.
$headers = @{
"Authorization" = "Bearer YOUR_TOKEN"
}
Invoke-RestMethod -Uri "https://api.example.com/data" -Headers $headers
$headers = @{
"Authorization" = "Bearer YOUR_TOKEN"
"Content-Type" = "application/json"
"Accept" = "application/json"
}
Invoke-RestMethod -Uri "https://api.example.com/data" -Method Get -Headers $headers
$headers = @{
"Content-Type" = "application/json"
}
$body = @{
name = "Sample"
value = 123
} | ConvertTo-Json
Invoke-RestMethod -Uri "https://api.example.com/items" -Method Post -Headers $headers -Body $body
Create a hashtable for headers and attach it using -Headers. This approach works for most APIs and keeps your scripts clean, readable, and easy to maintain.