If I attempt to add a new SQL data model, a popup shows up explaining that the feature is locked and I must contact my administrator (myself). However, there is no further explanation found in the documentation on how to unlock this feature.
This is how AppMaker used to look back when it allowed me to add database connections:
This is how AppMaker looks now when starting a new app:
The App Maker engineers are doing crazy changes now and then. I believe their point of view is to make the platform better but this kind of things really annoys me and makes life harder, honestly.
I ran across this problem and find out that they are forcing admins to set up a default instance in the G Suite Admin console. You can read more about that here. You haven't completed that step and that is why you see what you are seeing. Although, it's crazy! What if I don't wanna do that?! But they are the product owners and they establish the rules so we have to suck it up and do what they want! Unless a bunch of people complain about it, they are not changing the behavior.
Fortunately, I was able to find a work around. So what we (you and me) are trying to do, is set up a custom sql database. Right now, that will only be available if you've already done what I described above. So the work around is to import an app that already has a custom sql database set up and then modify the Google Cloud SQL address. Look at the example below:
Here is the demo workaround app that I use. Download it to your machine, then import it as in the image above. I hope this helps!
Related
I have a Firestore collection that I need to rename.
To do that I'll have to do two things. One, rename the collection, two, update my app (only web right now) to use the new collection name.
My problem is that if I just go ahead and do that, any user that has not refreshed the app won't be able to find the renamed collection.
So, my question is: Is there any best practice to handle this scenario?
I can think of a couple of options:
Somehow forcing a reload of the web apps immediately after renaming the collection.
Set a feature flag so that the web apps enter into maintenance mode while I update everything and then reload the web apps once the change is finished. Unfortunately the currently deployed web app doesn't have a maintenance mode to enable so this doesn't seem to be a valid solution.
However, I'd like to hear about other options. There might be some best practice that I'm missing. Moreover, I'm aware this is a problem that might be more general than just related to Firestore. For example when changing a REST API endpoint, so I guess there must be some tried and tested solutions out there.
I tried searching for best practices regarding this and couldn't find any.
Also, if I was consuming a REST API it would be easier to solve because I could change the DB and keep the DB unchanged. But given that Firestore gets consumed directly from the web app I don't have this benefit.
Locking out outdated clients is a common practice, but leads to a lesser user experience. It also requires that you have a mechanism for the clients to detect that they're outdated, which you don't seem to have.
The most common practice I know of is to perform dual writes to both the old and the new collection while clients are updating.
I'm really keen to use the 2sxc environment on my website for a number of applications.
I'm currently looking at the Mobius forms.
What I'm wanting to do is create a ticket in ConnectWise rather than send an email, using the ConnectWise REST API.
Some of these questions might have obvious answers to someone who has been taught in these technologies, but I'm self-taught. When I went to school I learnt COBOL!
There is c# code in the application, but I can't see how you build and incorporate into the application. I forked the code and it seems to just code with no build.
There are live and staging folders with the same cshtml files. However, it seems a bit random when the live or staging is actually used. For example, I did a quick fix to the _Contact Form.cshtml so to fix the type that meant it always displayed the ReCaptcha warning, and I changed the live version, which didn't do anything, so I had to change the staging version.
I need to update the settings so that configure the ConnectWise API settings, I haven't been able to find where I can do this? I am still looking though.
I also need to store a private key in the settings. Is there a secure way I can do this?
PS. When I get my head around all this I'm happy to be a contributor
welcome to StackOverflow.
I'll try to give you some guidance to help you figure it out
Live and staging are folders meant to let you make changes while the users see the unmodified output. So a host-user sees the files from staging, others see what's in live. When you're done and all is tested, you copy from staging to live. This we call Polymorphism.
Polymorphism applies to both the cshtml as well as the api. So as a host-user, you'll be using staging/api/FormController to save/send.
There is no build process, everything is hot-compiled. That's one of the things that makes 2sxc so amazing. No Visual Studio, DLL or restarting the application ;) You'll love it.
Secure keys: there is no special secure key storage. We usually put it in the App-Settings, just like the MailChimp key you'll see there. We split it into two fields for very technical reasons, because we publish our code on github and that causes trouble when our code has API keys. But you can just use one field, assuming you don't plan on publishing the code on github.
I am setting up a DTAP environment for Google App Maker. Google App Maker enables working in a singe file very well, however there is one use case that I would like to simplify.
For each deployment I need to "know" certain things in the back end script. Things like the ip address of the SQL server, or usernames and passwords. This information needs to be retrieved fast and often, given the stateless nature of google.script.run.
The best solution so far is a settings form, combined with google drive tables and caching. This works, but it is not simple, and things could fail easily. The other approach is hard coded and linked to the deployment url. This is fast and simple, but also means that all the credentials are in the source.
I am looking for a better solution. Apps Script used to have the script properties. Is there a similar option in App Maker, with a UI to maintain the settings.
There is no built-in UI to manage script properties, but App Maker's runtime (Apps Script) provides API to perform CRUD operations on it:
PropertiesService.getScriptProperties().setProperty('testKey', 'testValue');
...and you can 'easily' build the UI on top of this API. In answer for this question are highlighted major steps to achieve this: Google App Maker how to create Data Source from Google Contacts
Here is a feature request for the first party support. You can up-vote it by giving it a star:
https://issuetracker.google.com/issues/73584947
is anyone familiar on how setting translucent overlay for openldap 2.4.40.
I searched the internet without any hope.
what I want to implement is two openldap server so that one server get the search information from the other one, override some information based on its database and then give the final attributes
His question would be "How do you start". I've also read the "documentation"; it's terrible on this subject.
The slapo-translucent man page has no effective information other than "this is the translucent overlay, you can enable it." There's nothing about how you configure it to point to the remote ldap server. There's very little information
on how you can determine what cn/dn/du/o/fu that you desire to add/modify about the remote search results. (I just want to add to a user's group membership and
there isn't an example about something as simple as that.)
Everything regarding OpenLDAP 2.4 says you should be using ldapadd/modify to change the slapd dynamic configuration in /etc/ldap/slapd.d and yet ALL examples/tutorials for translucent overlays reference outdated slapd.conf usage.
Basically, none of the documentation is in any way educational unless you are already a full wizard at administering OpenLDAP.
Add to that the community documentation comes from a wide flavor of unix distributions, none of which conform to each other, and it just maximizes
the confusion.
My interaction with OpenLDAP leaves me with the impression that it has, easily, the most confusing configuration and usage architecture of any service that I have ever seen.
A directory service is something that an admin should be able install and standup in a day with no prior experience. It's clearly going to take weeks of
time trying to untie the configuration knot that this requires.
I'm working on a large Drupal website under two environments -Development and Stage. While I work in Development, my client enters content in Stage.
My work in Development modifies the database. Then, I need to be really careful when taking my work to Stage -otherwise I could affect my client's content.
This is painful and inefficient. Do you know of other options for this particular scenario? Perhaps a database merging tool? Thank you for your advice.
This is an inherent issue with Drupal, the storing of configuration and content in the same database. There are methods to help mitigate the issue, (like the Features module that helps you compartmentalize configuration changes) but they are very dependent on module support.
On our last site we tried using the Features module and the Deployment module but so many of the modules we wanted to use didn't have support for Deployment that we ended up not going that route and just manually duplicate configuration changes by hand.
Depending on what your client is entering you might be able to use some handy mysql to solve the issue, can you tell us a bit more about your scenario?
There are two kinds of data, configuration and user content. For user content, set autoincrement to two and use even and odd for dev / staging. For configuration write update hooks. Easy.
Try looking at these two former thread on the same issue:
Drupal DATABASE deployment strategies?
How to merge Drupal database changes
You could turn it around and keep copying your staging site's information to new instances of your development site's platform. Miguel Jacq has done a nice write up on achieving this set up. After testing things through you can then set up a thoroughly tested production platform at the production address and copy the staging site over.
Miguel's article: http://greenbeedigital.com.au/content/drupal-deployments-workflows-version-control-drushmake-and-aegir
Aegir: http://community.aegirproject.org
#jhuebsch: that sounds like a disturbing experience. Can you add a list of the afflicted modules and were you sure to use UUID & Strongarm?