I'm used the google-sheets API to sync data to a sheet periodically. Sheets automatically retains versions which is great for backups in case my code trashes important data, and has the option to "only show named versions".
To make trawling versions easier, is there an API method which will let me set a named version in my code after making changes? I assume there is but cannot find it in the documentation so far.
Related
I work on a google sheet that has several departments looking at and/or adding data to all day long every day. I have been working on making scripts to make my departments life a lot easier.I created an exact duplicate of the sheet so I could make sure it works before executing new scripts.
I have one that sets up an order, sends an email and puts it on the calendar all in one click. It works great.
In the email we need to send a link to a job folder. So we have a script to find that folder and get the link to it.
var folder = DriveApp.getFoldersByName("12345 - Help me")
var in = folder.next()
var link = in.getUrl()
In my testing grounds this works exactly how it should. When I put it into the actual sheet that we work in I get an error
"Error Exception: We're sorry, a server error occurred. Please wait a bit and try again."
I have been trying to figure it out for 4 days so far and am getting nowhere.
I had the "owner" of the sheet transfer it into my ownership incase that was the problem.
I moved it to a shared drive.
Made a copy of the whole spreadsheet to test it; it worked in the copy just fine.
To change over to a new spreadsheet will be a lot of work that would have to take place after work hours when no one should be using it. I am hoping there is a way to refresh the spreadsheet in such a way that we need to reapprove scripts (or something). The spreadsheet in question was created in 2018. I am wondering if its just to old for the script; not that that makes any sense but, I cant think of anything else.
Thoughts?
From the question
The spreadsheet in question was created in 2018. I am wondering if its just to old for the script; not that that makes any sense but, I cant think of anything else.
Nowadays Google Apps Scripts supports two runtimes, the old (Rhino) and the new (V8). There are posts sharing that changing the runtime to the one or the other fixed an issue. Considering this, the first thing to check if what runtime are being used on each Google Apps Script that are being used as "testing grounds" and in production as sometimes one of the source of "confusions" is to use different runtime.
Another thing to try is to create a standard Google Cloud Platform Project (GCP) to replace the default GCP project. On this project enable the Google Drive API.
Resources
https://developers.google.com/apps-script/guides/v8-runtime
https://developers.google.com/apps-script/guides/support/troubleshooting
Looking at https://docs.geoserver.org/ it seems odd that under the older versions the links stop at v2.13.2. Did the community stop publishing the interactive HTML document at some point such that we now have to find a way to the page where it has to be downloaded?
We are actually going to stop providing anything other than main, stable and maintenance due to lack of resources to keep documents online: the company that provided the old doc server is no more, the project has no budget, so we'll move the docs to GitHub pages, which has a space limitation allowing only 3 versions of the doc to be published.
However, each release comes with a zip file with documentation. Go to the http://geoserver.org/download/, move to the archived tab, pick the one you want, e.g., http://geoserver.org/release/2.12.4/, follow the "user guide HTML", save and unpack the zip. You now have the docs you need.
It looks like something changed in the release process some time ago (2.13.x was quite a while ago). To be honest I didn't know we had ever provided hosted copies of any version of the manual except for Development, Stable and Maintenance. In principal you should never need a manual that is older than Maintenance as that means you are running an unsupported version.
If you desperately need a specific version (to complete a collection maybe) then you can find a zipped copy of the HTML manual under the Archived tab of the Download page.
I'll probably raise a ticket about that documentation page as it has broken links too, so expect all the old links to go soon.
When browsing resources in ckeditor in Liferay 6.2, files appear unordered, making difficult to fetch one of them. That was not the behaviour in Liferay 6.1, where files where ordered by name.
Any way to fix this? Is it possible to sort them other way, as for instance by descending date?
I know this is an older question however I came across this problem the last week and I did not find any solution either on the internet.
So I implemented a hook to enable sorting by the name of the file.
To enable sorting by date you have to create an ext-plugin to provide the dates (created, modified) to the file browser and after that you can modify the display with a hook (eventually the same ordering hook as above).
You can find a detailed description how I achieved it here: http://hahamo.wordpress.com/2015/02/10/ordering-files-in-the-ckeditor-file-browser-with-liferay/
Some time ago, we distributed a toolbox to our users via the MATLAB App Packager, to make it easier to provide future updates, without users having to handle search paths. Now, we wish to distribute an updated version. Usually, re-packaging the toolbox should make a new .mlappinstall file, which asks the user to upgrade. Instead, MATLAB now considers the new version of the app as a unique new app, and installs it again rather than upgrading. Thus, the user will then have the app twice in the Apps pane, one in an outdated version, and one in the new version.
We have been unable to find an explanation for this in the MATLAB documentation nor online. When we install the updated app (so that both versions are present in the Apps pane), further changing it will upgrade it as expected, so unfortunately, we cannot provide a minimal working example, as we cannot reproduce the issue.
The question is this: How does MATLAB establish app uniqueness? The app name and author fields are identical to the original values, and the version number is incremented, so why might MATLAB not recognize that the app is already installed?
When you had that discontinuity, were you re-packaging using the original .prj file by clicking on it in the file browser in Matlab, or did you run "Package App" again and fill in the same properties?
I think the thing that determines the unique identity of the app is a GUID that is generated behind the scenes by the "Package App" wizard. If you open an existing .prj in the Matlab GUI, it re-uses that GUID. If you run "Package App" again you'll get a fresh GUID regardless of what you put in for the various developer-visible app properties.
You can dig around in the .prj and .mlappinstall files to see this yourself. (I couldn't find it documented anywhere either; I just poked around the files and did some trial and error.) The .prj is just XML, and the .mlappinstall file is a zip file with an "Open Packaging Convention" layout. In the .prj, there's a param.guid element containing the GUID. In the .mlappinstall, its in metadata/appProperties.xml in a GUID element.
If you end up with the same problem again, make sure to re-package using the existing .prj file. Or if you don't have it, once you create your new .prj file, dig the old GUID out of the metadata/appProperties.xml from the old .mlappinstall file and copy it in to your new .prj file and I think it'll behave as the "same" app. This will even let you change the name and contact info for your app, and it'll still install on top of older versions.
We're having a spirited discussion about this at my workplace. We're talking about user uploaded images for a bunch of products, not images needed to display the basic site. I say "no way" but I'm curious what others think.
Update: Just to clarify. These are customer supplied images for products that they are entering/modifying.
I agree with 'no way'.
Anything that may change on the site through day-to-day use, or is editable by whoever administers the website I consider to be 'content'. This includes uploaded files and database content, both of which are backed up separately. Nothing on the website that is in version control changes once it's been deployed. Easier that way.
Other ways of asking if something should be in version control:
Do the images change?
Are the changes related to anything else?
Can mistakes be made?
Is traceability wanted/needed?
If the rest of the site is version controlled, version control the images.
If the images are generated, version control the generator.
Presumably, what you are talking about is content that would be classified as user data, as opposed to project files. That stuff, while important, does not need versioning - that needs a plain old backup mechanism.
I recently added a new project into a fresh SVN repository, and every time I look at the 'uploads' folder I realise how stupid I was to include that in the initial commit.
It seems like what you're talking about is content that is in (or perhaps will be) in a database. If a customer is supplying you a list of products as well as the pictures of those products, then that should all come from a database. In this case, I wouldn't because your database should be backed up, but not in the VCS.
If it is not, and your web site is static, then I would only because it is "part of the site."
If you feel you must revision it, put these resources out of the path of the main repository somehow, and then give it a dedicated repository just for that content.
You don't want everyone who has to check out code getting a copy of every image when they checkout or update, its slow, and pointless, and having them in your primary tree will just have more headaches than you can Imagine.
/common_ancestor
/project_code/ # repository a
/resources_dir/ # repository b
If you have to use symlinks or web-server magic to make this happen, then do that, but whatever you do, DON'T put content like that in your main repository.
As far as backups vs revisioning go, revisioning it like this does give you a slight ease if you're using SVN as your distribution method as well, that way if a developer needs a copy of the images for testing purposes, its relatively easy to get a relatively up-to-date set of them.
If you aren't going to expose the versioning to the customers, then what would be the point?
The customers are already free to use version control on their own end, before they submit the files. You may want to encourage them to do so.