Request Changelog / History of changes for a function

Hi there, I would like to request the history of changes to this function over the past week.

https://develop.backendless.com/app/brilliant_grades/ui-builder/CS/pages/cs_calendar

Custom Function: fillCSCalendarNewUI2

We noticed that there were changes reverting to a previous version of the function.

It was supposed to be selectedWeekMonday not mondayTimestamp.

Now, we updated it again, but we need to understand what happened there.

Thank you in advance

Hello @Nicolas_Dafnomilis

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?

1 Like

unfortunately no, only getting it from backup

Hi @vladimir-upirov - we just noticed that we have a missing timer as well.

Backendless

The GradeSubjectChecker timer is empty.
We got this deployed and running and now it’s not there.

We need this to be recovered, can you check, please?

Find attached 2 screenshots. The one is what we get now and the other one is what we should get.


Also, how can we create backups? Is there a guide for this?

Hello @Nicolas_Dafnomilis!

I’m sorry about what happened.
If your app is on a paid plan, we can restore it from a backup, but there is a fee to cover engineer’s time.

In order to backup files you can zip you root folder, download it and in case you need to restore files, upload zip and unzip it afterward.

Regards,
Alexander

Hi @Alexander_Pavelko, yes our app is on a paid plan.
What is the fee for recovering the timer?

(We will need to recover only these as we have deployed changes today to various models of the app and we don’t want to be affected)

Thanks

We can see you deployed the BG_20_CS model with the timer 3 times today

2022-08-03 10:00:35,266
2022-08-03 10:38:30,681
2022-08-03 10:38:31,411

so just open change log on the PC where you did the deploy and restore the timer without any extra fee

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.

We need a changelog for this Request Changelog / History of changes for a function - #2 by vladimir-upirov

and we need this to be recovered:

Thank you

that’s correct, DeploymentModels (CloudCode) and UIBuilder have its own Codeless

Sorry, but I’m a little confused

do you want to restore the Timer or logic in UIBuilder?

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.

yes, that’s correct

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.

1 Like

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

1 Like

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

1 Like

Also, I’ve created two tickets:

  1. BKNDLSS-29217 - to discuss backups for CloudCode
  2. BKNDLSS-29218 - to discuss backups for UIBuilder

The ideal feature would also add on the confirmation dialogue the timestamp of the server Model.

1 Like