I can go to the tag browser in the same designer and rename the tag.
If I attempt to do this from Find/Replace, I get a message saying that it failed:
"Insufficient Tag Provider Edit Permissions"
This is because your user doesn't have sufficient permissions under the Tag providers Tag Edit Permissions
You can verify this by checking the Tag Providers settings (assuming you have gateway access) and your own Security Levels / Roles.
I'm logged in as an Administrator.
Tag provider edit permissions have the Administrator role checked.
And I can change the tag in the tag browser in the same designer logged in with the same account.
The Tag Write Permissions are not the same as Tag Edit Permissions. There are 3 settings (read, write, edit). Once those are good and you're still having issues, verify the radio buttons underneath the Permissions box.
Sorry, I did mean edit. If it was an actual permissions issue shouldn't that stop me from making the change in the designers tag browser? Running designer circumvents some aspect of the security?
Sanity check: Can you make the changes from the designer tag browser?
No. But depending on your gateway configuration things may behave differently. You haven't shared much, not even the Ignition Version, so we can only assume so much.
Does your Designer use the same IdP as your project? or is it using the Classic strategy, etc.
Yes.
"I can go to the tag browser in the same designer and rename the tag.
If I attempt to do this from Find/Replace, I get a message saying that it failed:"
I'm in designer, using Find/Replace. I'm not giving the Find/Replace tool different credentials?
Strictly speaking, and as noted all over the forum, a designer can do anything. All controls that affect the designer are guardrails, not hard limits, since the designer can always make a new library script and make it run in the gateway. Those familiar with the SDK can literally do anything in the platform.
It's common practice to detail your revision (down to minor), and expect to be asked to verify things you're taking for granted, as the folks here attempt to wrap their head around your problem. The following guide may be helpful for getting more out of your forum experience.
Yeah, I don't do the best job describing things and it takes me extra effort. But I do put in the effort, however completely unacceptable the outcome may seem to others. This particular instance, I believe to be a fairly simple issue. I posted the error message, I posted a picture, I described what was going on I selected the Category and version tags that I always try to do.
It's not a big deal if it doesn't work but I still don't understand why the particular issue would be happening. If anybody needs any extra information all they have to do is ask but I already provided the version. If somebody's aware of some issue in an extremely specific version why hide it?
I've not seen anywhere near all the threads on the forum but I don't think I've seen anybody ever do that.
The basic question remains. Should I be able to click on a tag in the tag browser, in designer and rename it, while not being able to rename the same tag in the same instance of designer but with Find/Replace? If so, what might be the cause?
I just checked with 8.3.8 (Edge though it shouldn't matter) and I can hit F2 rename it to something and then do edit find/replace and use that to rename it back to the original no problem.
I'd do some basic troubleshooting. Create a new tag provider, create a tag, then re-try it on your system. See if its related to the tag provider settings or a bug in your designer.
I'm 99% sure this is just a bug in the find & replace implementation.
Normally operations in the Designer, as Phil mentioned, effectively shortcut permissions (because there's not much point), and go through a specially trusted "system" security role internally. (This isn't quite accurate, we do still use the logged in user's permissions against the tag provider for regular designer ops, nobody panic).
However, find & replace tag operations are "bounced" to the gateway for actual processing, and in the process split up. Regular property edits go down one code path, renames specifically go down another. Regular prop writes get the special "system" context, but renames get the inverse - a special "empty" access. That then gets denied (correctly) by the system and you get an error reported.
I'll get a ticket filed.