The changelog just keeps your local changes in the local storage, so if you make changes on PC1 and then open the function on the PC2 the changelog on the PC2 will not contain changes from the PC1
In the UIBuilder all codeless logic saves automatically on the server, if you see prev changes it means someone from your team changed it
It was supposed to be selectedWeekMonday not mondayTimestamp .
I’m not sure I understand what you mean, could you please provide more details
There was a variable name changed that none on our team recalls doing. Is it possible to have a log of changes made to a particular container over the past week?
Thank you for the suggestion regarding the BG_20_CS model but this won’t solve our issue with the UI Builder. If I am not mistaken the BG_20_CS model has nothing to do with the UI Builder.
Sorry for the confusion. We are talking about CloudCode. Unfortunately the PC where we did the deploy no longer has the old BG_20_CS model on the changelog. Are you able to quote us a fee to do the restore?
We are generally having issues of code reverting to prior state. This is most probably due to our own behavior and we maybe need to better understand how the system works so that we change our behavior.
From what I understand
On UI builder, any change I make is stored on the server in real time. When we deploy, any changes on the server are deployed from production to live environments. Specifically, when we publish, the code moves from the ui_builder folder to the respective container folder. Any page published, publishes the entire container. If someone else has made changes to another page of that container, those changes are also published to the container folder. Is this correct?
My only question is, how are conflicts handled, for example, I assume that if I am making changes to a certain page, and another PC is looking at that same page, they are not seeing changes in real time. eg. I assume there is no live collaboration capability. If 2 people accidentally are making changes to the same page (which we will never do on purpose), how is this handled?
On CloudCode, we understand that changes to a deploymentmodel are stored on in a PC’s cache until the user deploys the code. If user A made changes to model 1 on day N-1, then user B has not logged out of Backendless on day N-1, user B may have the previous version of model 1 in his cache. Therefore if on day N, user B attempts to make changes to model 1, they first need to pull the latest version from the server, otherwise any changes they make on day N will be based on their outdated cache and will overwrite the changes made by the previous user on day N-1. Is this understanding correct? This is the latest assumption on what has been happening to us.
Upon your confirmation that the above may be our issue with CloudCode, we will instill controls so that each user pulls the latest server model before making changes and no user is on the same model at the same time.
In case, we need help in investigating this issue, do I understand well that you can provide us the latest deployment times, but you cannot provide us the user in our app that made those deployments?
eg. for the below you are not aware of which user made these deployments, we will need to keep track of this manually?
Do you have anything on the roadmap or can we add a feature request to log the user of deployments? This will be useful until Backendless develops team capabilities like Github.
we do not handle these conflicts, the last changes (request from the client) will be applied on the server. That’s why we do not recommend working together on the same page/logic/function/etc. In our plans is adding a system to control who is allowed to modify a particular page/logic/etc at a specific time. When someone is starting work on a page no one will not be able to modify the page until the first developer is finished, but the second one will be able to take control forced.
Yes, that’s correct. Seems like it could be the reason. I’ve created a ticket BKNDLSS-29219 to add a confirmation dialogue before deploying a model. In the confirmation, we are going to show what exactly is being deployed on the server. Theoretically, it should prevent such issue you described above, does it make sense?
Actually, you can do that right now, just open the ChangeLog for the changed logic and then click on the “use server model”, it resets your local changes
we’ve released a new feature “Audit Log” which is available on the new CloudEnterprise billing plan. On the screen you can see who and what changed in the Backendless App