So that the input and modification of the values required for variables in the scripts are restricted to the normal user level of this screen only, and to prevent it from accessing and modifying the scripts or changing the content “if using Webfig”. The basic editing of scripts is restricted to the administrator, And minimize the exploitation of comments , And far from using [/system script environment]
Do I find support for it?
I want a big business , I have a lot of micro-routers, and requests from customers
This is very important in case of customization WebFig
Example script 1 :
:local DynDnsUser [/system nots-list get DynUser]
:local DynDnsPassword [/system nots-list get DynPassword]
:local DynDnsInterface [/system nots-list get DynInterface]
:local DynDnsHost [/system nots-list get DynHost]
Example script 2 :
:local SmsUser [/system nots-list get SmsUser]
:local SmsPassword [/system nots-list get SmsPassword]
:local SmsSender [/system nots-list get SmsSender]
:local SmsMessage [/system nots-list get SmsMessage]
I’m not sure about all OP’s goals, but some kind of name=value storage sounds like interesting idea for scripting. Or how does one store some persistent data now? Just in files? Such storage could be easier to use. GUI where you could see and edit values would also help. Access control (admin could create some items that would be read-only for less privileges users) would be nice too.
I meant something like existing “/system script environment”, but:
Fully editable from WinBox. Currently you can’t add new variables.
With ability to survive across reboots. Unless I missed something, currently the only way to store persistent data is to write them to file. This could be easier to use.
Possibly with different access permissions. But I’m not sure about exact details, because I’m not familiar enough with current user permissions system. I know it’s there, but I never really did much with it.
Have a script initializing the needed variables on startup is not enough?
This would give you a solution to your problem and leave Ros uncluttered for users not needing that.
Yes, you are right. Maybe that should be changed
e.g. to have the ability to place some $GLOBAL_VARIABLE_NAME as command parameters.
It works in CLI as a one time substitution, but it would be nice to have it dynamic. Unfortunately this seems IMHO to need a radical core redesign…
I think OP’s goal is to have configurable parameters outside of script itself, i.e. if there are several devices, they can have exactly the same script (for easy maintenance) and read device-specific parameters from somewhere else. I’m not scripting guy, so I may be wrong, but I belive that currently the only way to do this is to use files on disk, and I don’t know if there’s anything between all or nothing for access control.
@Docmarius… IMHO it shouldn’t be so hard … I know, Iknow … it is easy to write this but … if there is already implemented mechanism which lets change eg. interface name in Winbox which leads to change this name in all rules at once then it have to be already implemented as a list of pointers of all occurances of this name. I know that many things are represented as internal “*n” entity which could have pointer to “human readable” name but it means that it is also already implemented. Therefore implementing “macros” or variables outside CLI should not be REVOLUTION but EVOLUTION.
The reason i said that is doe to the fact that, at the moment, any stored configuration is static, with a few exceptions in the address lists. That means that variables names are resolved to their values when set (and not on use).
e.g. for a route using a dns name for its gateway, that will be resolved to an IP and will go that way into the working config. No re-resolving is done later on.
Having a symbolic name there, it needs to be able to be resolved on change, which needs some kind of check and trigger mechanism, which does not exist (yet?). And also a new storage paradigm for the configuration needs to be established, so that symbols get stored instead of parameter values. In my view this is a radical change, and it does not resemble list handling (unless everything becomes a list, or even better, a generic object which could be also a list).
For the record, I’d say that we now have two completely different topics in this thread. I can’t speak for OP, but what I was describing as my interpretation of the request, didn’t have anything to do with macros.
Instead of using larger fonts or different colors, you need to explain what you want in more detail and in a way
that other people can understand. As it is now, it looks like nobody understands what your requirements are.
Yep, I also don’t understand the purpose of this request. You can already do this stuff in other ways. If you mean something else, I don’t see the purpose yet.
1/ I want to make special settings and configuration in routers , too create special scripts
2/ I want to create a limited user
3/ I want to create a Design Skin custom and limited by WebFig
4/ make user limited allow access to this Skin by WebFig
5/ I want to block limited user access to (system scripts) in WebFig
But this programming script needs to change some value in variables
The only solution to prevent the limited user’s support to programming and give it the power to change the value of some variables…
As shown in previous pictures also by way of calling the value from that window
:local DynDnsUser [/system nots-list get DynUser]
:local DynDnsPassword [/system nots-list get DynPassword]
:local DynDnsInterface [/system nots-list get DynInterface]
:local DynDnsHost [/system nots-list get DynHost]
