Hm, It worked for me. Could you send your config.json? Is this option (max offline days) enabled or not on your app service device sync?
I sent yout the json via message. As I am not sure if I should post that here (my app is already in production). Offline time is according to the web UI disabled.
You have to set client_max_offline_days to the default value. Otherwise, it won’t work.
Set "client_max_offline_days": 30 in sync\config.json?
Then click “Pause Sync” and then deploy again using realm-cli push.
It should work.
I added
"client_max_offline_days": 30
and it still does not work. It keeps ignoring my config.
You will continue to receive this message “Deployed app is identical to proposed version, nothing to do” if the json settings are the same as the app service settings. Only changing client_max_offline_days is not considered as a change (it will be investigated).
If you change anything else in the config it will be uploaded. If there is no new changes different from the last upload, then the upload will be ignored.
So, I’m wondering whether your changes are not already uploaded. Or, are you sure that you are uploading to the correct App service? Could you try to login with realm-cli again with the app keys of the relevant Atlas project?
You can try to pull your app (realm-cli pull ) to another folder and then to compare the json files, whether they are identical indeed.
I am 99% confident, that I am pushing to the correct project. I also tried enable the automatic deployment from GitHub via the App Services UI and experienced the same issue. I just checked again by changing something in my functions and the function is changed correctly.
I can add my console output:
D:\GitHub\myApp\server\myApp-dev>git diff
diff --git a/server/myApp-dev/functions/onMessage.js b/server/myApp-dev/functions/onMessage.js
index f87b4c3..ec11c54 100644
--- a/server/myApp-dev/functions/onMessage.js
+++ b/server/myApp-dev/functions/onMessage.js
@@ -34,7 +34,7 @@ exports = async function (changeEvent) {
);
await context.functions.execute("sendNotification", receiverId, {
- text: message.senderName+ ": " + message.text,
+ text: message.senderName + ": " + message.text,
type: "MESSAGE",
});
-};
\ No newline at end of file
+};
diff --git a/server/myApp-dev/sync/config.json b/server/myApp-dev/sync/config.json
index 5e43a07..4b6538d 100644
--- a/server/myApp-dev/sync/config.json
+++ b/server/myApp-dev/sync/config.json
@@ -24,6 +24,9 @@
},
"createdAt": {
"write": false
+ },
+ "test": {
+ "write": true
}
}
}
D:\GitHub\myApp\server\myApp-dev>realm-cli push
Determining changes
The following reflects the proposed changes to your Realm app
--- functions/onMessage.js
+++ functions/onMessage.js
@@ -34,7 +34,8 @@
);
await context.functions.execute("sendNotification", receiverId, {
- text: message.senderName+ ": " + message.text,
+ text: message.senderName + ": " + message.text,
type: "MESSAGE",
});
-};
+};
+
? Please confirm the changes shown above (y/N)
As you can see, I changed the config.json and the realm-cli push does not detect the changes. I changed my functions afterwards too, and those are detected correctly. The git diff shows the differences I really made.
I have "client_max_offline_days": 30, in that file.
@Thomas_Anderl we will do some more investigations. Any additional details will be helpful if you have some.
Thanks, for your report.
I can give you any details that you need. What would help you? A “strange” behaviour is: When I change it in the UI it appears correctly. When I then run realm-cli pull, I however get the “old” version again. It seems that that version is stuck somewhere, or it somehow connects to the wrong project (I have prod and dev, but both projects have the same issue).
realm-cli apps list prints the correct project.
1 Like
Hello @Thomas_Anderl,
Thank you so much for your patience. This has been discovered as a bug in the code and the team is investigating. I have escalated this again.
I will keep you updated as and when I have information.
Your patience is appreciated.
Cheers,
Henna
Hello @Thomas_Anderl ,
Could you please let me know if directly making changes from the UI would suffice at this moment? The team is working on releasing a new version of the CLI soon and it may take time to look at the issue in question.
I look forward to your response.
Cheers,
Hello @henna.s ,
changing in the UI only solved the problem until I make any other change again and the redeploy would “reset” it to the old version. Also I would prefer testing the configuration first extensively on dev (where I deploy stuff quite often), before I make such a big change on prod.
1 Like
@henna.s @Desislava_St_Stefanova
I just did some additional testing (because I had to add a new Entity to my sync rules). I figured out that this one was correctly added to the sync. So I investigated a bit more and figured out, that field-level permissions are ignored. Document-level permissions are taken over correctly. Is this a known issue?
That means the max-offline-time and field level permissions are the ones that are (apparently) being ignored. Hope this helps in the investigation. Copying those manually, also works until they are overwritten the next time by my json. I copied my entire json manually into the UI and it was accepted and saved. With the next deployment however, the fields and max-offline-days will be removed.
Hi @Thomas_Anderl,
Due to your report and investigations, we have already two issues created and the App service team is on them. The first issue is about client_max_offline_days and the second one is about the permissions fields.
Thank you about your contribution!
Hey @Thomas_Anderl,
With regards to the issue with flexible sync field-level permissions not being push/pulled via the CLI - the team will be changing how flexible sync permissions are defined in the near future (within the upcoming release or two). More specifically, flexible sync permissions are being integrated into the Rules that are defined on the “Rules” page in the UI. In the App Configuration structure, this corresponds to the data source default rules and collection rules.
For a bit more context, the integration is being performed in order to make those rules be the single source of truth for all app services involving a MongoDB cluster (GraphQL, Flexible Sync, DataAPI, etc.). We’ll be performing a migration to convert everything over, so that shouldn’t require any additional action from your end.
In the meantime, if you need to deploy changes to the existing field-level permissions configuration for flexible sync, I’m afraid the UI is the best way to go about doing that; as you alluded to already, the local sync configuration will have to be manually kept in sync with the one deployed via the UI in order to develop locally off the latest version of the config (assuming there are changes that set field-level permissions). Sorry for the inconvenience.
Jonathan
1 Like
Thank you @Jonathan_Lee for the insight. I was anyways wondering why these are two seperate things with a similar purpose. I am always happy about overall simplifications anf alignments. I assume however that the migration you mentioned will not affect me if my field rules are not manually deployed to the UI when the migration happens.
The migration will not “auto-pull” the app for you, so it should not immediately have an effect on anything locally (unless you pull, but that would be the same behavior as if you were to pull the app right now). To go into a bit more detail, the migration will look at whatever is defined under the “permissions” key in the flexible sync configuration at the time of running, and convert it to an equivalent permissions setup across the relevant data source default_rule.json / rules.json file(s). Thus, after the migration is ran, if you pull the app, you’ll be able to see those new file(s) in which permissions are stored, and should be able to modify the field-level permissions there.
One last thing to note: the “permissions” key in the flexible sync configuration will still exist after the migration (it just won’t be used anywhere); after all apps are migrated, we intend on removing that field completely.
Jonathan
Good to know, so there is more files than that I should sync between dev and prod.
I am deploying automatically to dev whenever my config changed (and prod on demand), but my field level permissions are ignored due to the issue you mentioned. That means when the migration happened I should have my config synced via the UI so the migration happens on them? Or are the field level permissions stored correctly behind the scenes and will migrate correctly?
As I redeploy my config pretty often on dev, it would overwrite it everytime. So currently I work without the field level permissions, so I dont have to update via the UI every time I change something.
Got it. Yeah, if you want your flexible sync field-level permissions configuration to get picked up at the time of migration, you should deploy via the UI.
If you want, if you link the app URLs of your dev / prod apps (they look like https://realm.mongodb.com/groups/${}/apps/${}), we could setup a specific time to run the migration on those apps in order to avoid conflicts arising from deploying changes as the migration is running.
Let me know if that works for you,
Jonathan
That would be amazing. At least for dev, so we can test it there. Promoting to prod is anyway just copying the dev config files over to prod once we are confident that it works. Hopefully the max offline time is also fixed by then.
So for now its time to wait till the change for the rules land and I assume I can manage to have it deployed by the time that your migration happens. On dev, I am flexible anyways.
Thank you very much for your support.
Hey @Thomas_Anderl,
Wanted to give you an update – we just released the new rules system for new apps today. We are targeting migrating over existing apps within the next week or two.
Also, the issue with the client_max_offline_time field and the old QBS permissions being ignored in the CLI should be fixed now.
Jonathan