Could you elaborate on this?
Some people are currently working on this. Add Role Based Access Control [RBAC] · Issue #3305 · openhab/openhab-core · GitHub
This is probably currently outside the scope of the above, but perhaps once that’s in, this can be added - depending on the architecture of the above.
The ChaptGPT Agent (OpenHAB Guru) is a great resource! Thanks for sharing!
Right now there is no duplicate option. Even not considering “quick edit” options, the fact that we could duplicate one item would already be amazing.
Awesome. Good to know! 
Indeed there is. Since I’m still in 3.4 I didn’t know that. Anyway, still my suggestion applies to Items. I will definitely have to consider upgrading to 4.x I’m just kind of scared on the amount of time that will take me! 
By most accounts the upgrade between OH 3 and OH 4 was the easiest upgrade process yet. With the development of the upgradeTool, if you are using managed rules many/most of the breaking changes get fixed for you as part of the upgrade. Compared to previous major versions, the number of user facing breaking changes was way lower as well. Many were able to upgrade without changing a thing.
It is possible to create duplicates of both Items and Things.
@rlkoshak posted a screenshot from the Items menu, so what is wrong with that ?
Man this has been a though day!
Since I’ve read Rich saying:
I immediately assumed (without properly looking into the image) that only existed for Things.
My suggestion would be an additional trigger on the rule. I got a few rules that are triggered by one or more items. No issue here, but sometimes the rule is triggered very often and theres no need to run it again. So an extra trigger “but not more than once every X seconds” would be nice.
I’m not sure this is appropriate for the rule triggers. That’s the sort of thing rule conditions are for and can handle right now with a script condition. Triggers define the event that could cause the rule to run but conditions specify the conditions under which the rule is allowed to run when triggered.
It would be nice if there were a built in condition though instead of needing to resort to a script.
In the mean time, in JS such a condition would be something like:
var rval = time.Duration.between(cache.get('lastRunTime', () => time.toZDT(), time.toZDT())
.compareTo(time.Duration.ofSeconds(10)) > 0;
if(rval) cache.put('lastRunTimer', time.toZDT());
rval;
The first line checks a timestamp stored in the cache to see if ten seconds has passed since the timestamp was recorded.
The second line stores a new timestamp if ten seconds or more have passed.
The last line is what gets returned by the rule condition. Only when rval is true will the rule’s actions run.
This could also be implemented using timers.
Another approach would be to apply one of the basic profiles (e.g. Basic Profiles - Transformation Services | openHAB or Basic Profiles - Transformation Services | openHAB) to limit how often the Item changes in the first place.
You’re right that would be a better name for it since it is a ‘limiting’ condition. Although I don’t use it, maybe the “inverted” option could be a trigger. Like “at least once every X seconds”. So the rule will run periodically even if none of the triggering items changes.
Yes, I got some code like yours in the rule right now. You can make a rule do anything but this would make it easier and more visible in de configuration. And make this kind of behavior available for non-programmers.
That’s a cron trigger.
Yeah, but if I configure a CRON trigger and item triggers it will do both independently. So run every 5 minutes and whenever an item changes. So in practice it will run more often than every 5 minutes. But doing this would be the workaround to come close to this behavior. In fact, writing this response I remember I got one rule like this 
Again, you can have a condition just like the above. Just check to see what triggered the rule and if it’s an item trigger return true. If it’s a cron trigger check the timestamp and only return true if it’s been long enough.
if(event.type.includes("Item")) {
cache.private.put("lastRun", time.toZDT());
true;
} else {
time.Duration.between(cache.get('lastRunTime', () => time.toZDT(), time.toZDT())
.compareTo(time.Duration.ofSeconds(10)) > 0
}
With that any time it’s triggered by an item the actions will run. Any other trigger will only run the actions of its been 10 seconds or more since the last item trigger.
JRuby provides a simple way to do this:
only_every 2.seconds do
# do what you want here, or even
rules["some-other-rule-id"].run
end
JRuby also provides a built-in debouncing mechanism:
| Guard | Triggers Immediately | Description |
|---|---|---|
| #debounce_for | No | Waits until there is a minimum interval between triggers. |
| #throttle_for | No | Rate-limits the executions to a minimum interval, regardless of the interval between triggers. Waits until the end of the period before executing, ignores any leading triggers. |
| #only_every | Yes | Rate-limits the executions to a minimum interval. Immediately executes the first trigger, then ignores subsequent triggers for the period. |
Note there are two versions of these, one for convenient use in file-based rules as a special type of rule condition, and another which can be used in a UI based rules, as per the example above.
How about this:
This will be the equivalent of jruby’s only_every.
Implementing debounce_for is trickier because it involves delaying the execution of the rule. I can think of two ways of implementing it, but not ideal, so I’m still thinking about it.
I would expect to keep DSL rules as well.
It is the only rule engine I use since OH2.
I have no idea what to replace it with nor did I find any guide on how to get away from DSL.
Here a note from Rich Koshak for this topic from 2021:
OH2.5 to OH3 - When, and to what, should I convert rules from DSL? - Setup, Configuration and Use / Scripts & Rules - openHAB Community
Since 2021:
You can see some comparison of them here
We can’t make the choice for you. It might be worth experimenting to see what you like. You can’t really go won’t with any of them.
As for a “guide”, there really isn’t one because it’s not really complicated enough to deserve one.
There is no reason to rewrite your old working roles unless that’s something you want to do.