Users

All Posts (4)

avatar

dalbrecht

HTTP PATCH Method is not updating attributes

avatar
avatar
avatar

Thank you, Patrick. We'll try to update and test again soon.

HTTP PATCH Method is not updating attributes

avatar
avatar
avatar

Hello,

We are using Remote Desktop Manager v2025.2.14.0.

I am working with some automations that leverage the API, and it appears as though the PATCH method does not work, despite receiving a HTTP 200 response back from the server.

Specifically, I am trying to change some attributes on an existing entry in our vault. I am sending a PATCH to this endpoint:

https://our-remote-desktop-manager.com/dps/api/v1/vault/{{vaultId}}/entry/{{entryId}}

And, I'm sending the following raw payload with the PATCH request:

{"name":"Test Device Name", "description" : "Test Description via API call"}

I receive an HTTP 200 back from RDM.. but when I go and check the vault, nothing has changed. If I look at the History section of the device entry in the RDM web interface, I do see the change event in the history.

Do you have any idea what the issue could be?

Issues with Syntax Highlighting

avatar
avatar
avatar

Thanks for your response, Carl. Understandable regarding WebView.

I switched the order of my "interface down" and "admin down" rule, and it's working properly now, despite the "admin down" rule coming after the "interface down" rule.

It would be helpful to hear back from the developers to understand the logic about rule ordering and priorities. I was assuming the list was priority-sorted, with higher rules taking priority, but it seems that maybe each rule is executed one after the other (top-down), so rules farther down in the list will essentially take priority over rules that appear earlier near the top of the list.

Issues with Syntax Highlighting

avatar
avatar
avatar

Hello, I'm a new RDM user and I have created a few rules to try out syntax highlighting in RDM.

There are two issues I've come across - one is a UX issue, the other seems to be a bug.

To start with the user experience issue (and this seems to be a fundamental design issue with RDM itself, not just with syntax highlighting), you can't do anything in RDM when the settings dialogue window is open. So, for every change to any setting, I have to:

  1. Open settings

  2. Navigate to the item within settings (usually nested within some sub-tree) (for instance, it takes 8 mouse clicks to get to the syntax highlighting section, every single time, or 5 clicks if you search the settings for "colors")

  3. Make the changes, then save/close out of settings

  4. Test

This wouldn't be a poor user experience if I could keep the settings window open independently of the main UI to quickly make and test changes.

Now, the potential bug with the syntax highlighting is that rules with matching substrings seems to override each other. The UI has up/down arrows to imply order, and even the XML file from an older forum post with syntax highlighting rules suggests there was an order to rules, but in my testing, either the order is not respected, or there's a problem with the logic when it comes to parsing rules with the "Complete word" option checked.

        <SyntaxHighlightingItem>
          <BackColorString>#000000</BackColorString>
          <BackgroundColor>Transparent</BackgroundColor>
          <ForegroundColor>BlackBold</ForegroundColor>
          <ID>b474c0d9-2145-4672-a4dc-cf15258ab7ff</ID>
          <Keyword>administratively down</Keyword>
          <Name>admin down - administratively down</Name>
          <TextColorString>#000000</TextColorString>
        </SyntaxHighlightingItem>
        <SyntaxHighlightingItem>
          <BackColorString>#000000</BackColorString>
          <BackgroundColor>Transparent</BackgroundColor>
          <ForegroundColor>Red</ForegroundColor>
          <ID>21fa4909-63a2-4202-8ef0-1b84bcaf5d5e</ID>
          <Keyword>down</Keyword>
          <Name>interface down</Name>
          <TextColorString>#000000</TextColorString>
        </SyntaxHighlightingItem>

As you can see, there's a separate rule for `down` vs `administratively down`, with the former being defined first. Yet, in my terminal, the specific rule for `down` is taking priority over the earlier defined rule for `administratively down`.

Result in terminal:

I would expect the string "administratively down" to match the rule named "admin down - administratively down" and use the ANSI Black Bold foreground color.

1 - 4 of 4 items