Wappler 6.6.1.
Are targets saving differently? Seems if we make changes with the Development (local) target selected they are changing when we then switch to Production (remote)... It is driving us mad with a Security Provider / Security Restrict Step! Just wondering has something changed? If we then make changes with the Production Target selected they wipe the Development Target settings? This seems to be occurring with Security Provider only right now...
This has been happening for the past couple of versions. We thought 'oh well we are just forgetting to add the selected Group to the Restrict Step' and added it again. All working fine locally. We then deploy to remote and try to login and are booted back to login. We look at the Restrict and the Group has gone and we have to select it again for all the Actions with the Restrict. Deploy to Remote and access no problem. Switch back to local and get booted! Check the Restrict and the Group has vanished again... ARRGHHHHHH. We have used Security Restrict for years with no issues. Never ever had an issue like this arise.
Will send you a video @George
Well that is the reason why we want to disable editing on different target than development, there are so many things that go wrong when you are on remote target.
So aways edit on development only and then publish only to other targets. We already have disabled a lot of the editing on remote targets but more needs to be done.
See also:
It would be nice to be informed of these changes @George. So what are we to do now until the crossover to the ´rethink active targets´ is being thought about? What is the work-around for this issue? Have not seen anything discussed about these changes being implemented.
Never ever had an issue there personally until now.
Well just as I said - edit in the development target only and then just upload/publish to the remote targets. There is absolutely no reason to do editing on remote targets directly.
We are NOT editing the remote target. We are editing locally then Deploy to remote, we NEVER edit remote targets. When we switch to Remote to Deploy it overwrites the changes made locally as outlined above and in the video.
We make changes locally. We Deploy to remote. When we switch to remote to Deploy the locally made changes are overwritten/not recognised/ignored.
ah ok sorry it wasn't clear exactly as your video was a bit cut of from the bottom 
Well on each target switch the specific targets settings gets copied for that target. So when switching back to development - the right development targets should be just copied back.
Isn't that the case?
If we switch targets, only switch the target, as in the video (I'll redo the video with the bottom half included, we are not editing the remote target) the setting in our local development shows our changes. BUT the remote does not reflect the changes.
Unfortunately not George. The only work-around we have right now is to switch so the remote Target is selected and make the changes again (this then reverts the changes locally to empty once again), its swings and roundabouts hence the elastic band image as am pinging back and fourth. Thankfully my head is shaved otherwise I'd have no hair.
Well this behavior hasn't been changed for a while, so maybe you have some weird differences between the targets? Try to check what the differences in files are.
There are none George. Targets have not been changed since their set-up over a year ago. We have had no issue with this up until recently and only with Security Provider all other Actions are absolutely fine and working correctly. Still I'll go ahead and check but am 99% sure it is not the Project that has an issue with Security Provider. We added a new role to Security Provider and then this issue reared its head. We have added roles hundreds of times to multiple Projects with not one single problem until this.
When was the last change so I can see if it corresponds with changes I can compare it to? I reitterate it is only Security Provider having issues.
UPDATE.
I've just opened another Project and added a new role. Same thing occurs! This is not coincidence.
User and roles are target specific. I can’t think why it would be needed to have per-target roles so this was created ages ago…
Thank you SOOOOOO much Ben!! I'm not going mad...
@Cheese
I've seen the video you sent to George, but we both can't understand what are you trying to do or what is the expected result from your actions on the video.
You have some permissions set on local target.
You have no permissions set on the remote target.
You switch from one target to another and obviously the settings set for this target appear.
If your idea is to change the permissions and set them on the remote target, why don't you deploy after making changes locally?
I DO! But the changes then wipe the local permission, and if I change local it wipes remote. So I can either login locally and work, then have to do the changes to remote to work remotely and it wipes local. What am I supposed to do? SURELY this should be synchronised as Ben suggests. It is crazy and we are experienced Users having this issue I dread to think what a new User would go through trying to figure this out. I just don't get the point of it?
Ok here a bit more explanation on how target settings work, in this example for Security Provider.
Initially, when you create a new security provider, a single set of settings is used for all targets.
However if you go to a specific target and make some changes - then this target retains its own settings and no global settings are used but the ones you specified.
This force you that if you have changed again settings on the development target, you have to reapply manually those settings to the other changed targets.
In your case you probably had initially some security provider settings (like without the permissions), but then saved them on the remote target as well - making them unique there as well.
So now you have added permissions on the development target, which of course doesn't get populated automatically to the remote already saved target. So you have to make the changes there as well manually.
Note this is only because you made target specific changes ones then those changes have to me kept manually in sync.
If you want just to have a single set of settings then make sure you change the settings only in development and not on each target again.
The overwritten settings are saved in:
./wappler/targets/_target_name_/app/modules/SecurityProvider/_name_.json
if just remove the files from the targets that you don't want to overwrite manually any more so that they will receive the default development settings.
This kind of issues will be definitely solved with the new targets manager where you will have clear overview of all targets and their settings. We might even allow some partial overwrites per target.
Thank you for taking the time to explain that concisely George. I don't know how much time I've wasted but I'd guess at least several hours trying to work out what was going on as never had this issue before, and it has been a while (maybe a little longer than I first thought) since we added new roles to Security Provider, so it has caught me totally off-guard and totally confused me as knew I'd done this multiple times with no issues (but then maybe that was in PHP).
The only reason we tried Remote in this circumstance was to debug the issue to try and catch the problem and actually see it on the screen. Otherwise would never do this.
Surely this should be the default and just dump this whole thing. Who would want separate permissions and what purposes would that ever serve?
Then in that case I look forward to having control back!
Really do appreciate you all at Wappler HQ. I apologise for getting frustrated.
