I erroneously deleted the ‘footer.liquid’ file in the Providence theme.
I am unable unable to create a new footer.liquid file in sections as I am getting the error below:
“New schema is incompatible with the current setting value. Invalid type value for block '1523601164583'. Type must be defined in schema. New schema is incompatible with the current setting value. Invalid type value for block '1523858388687'. Type must be defined in schema.New schema is incompatible with the current setting value. Invalid type value for block '1523592394611'. Type must be defined in schema.New schema is incompatible with the current setting value. Invalid type value for block '1523858779593'. Type must be defined in schema”
Any ideas?
I know its been a while but in case anyone ends up on this thread looking for the same thing or the poster of the question did not find a fix (probably not the case) up to this point, I will attempt to answer with how I got around this.
First of all lets examine why this happens, from my understanding, each time we add or modify certain values inside a section schema, the settings_data.json located in the config folder, will have settings generated inside of it upon usage of that section.
So when we go back into the section and change for example the type of a block, it will no longer match the existing settings inside of the settings_data.json and as such you will get an error back.
So how do if fix it? We simply go into the Shopify Store Adimin and remove the blocks that make use of the type we've changed, after we do this we can easily define any new type we want, add the blocks back and we will no longer receive an error.
Related
I have a required custom field on any ticket created (Bug, Tasks, PBI).
I have a pipeline that creates tickets automatically, but the values that are used to create these tickets doesn't have a value for my custom field. I want to set this custom field by adding an entry to the pipeline variables, but I don't know the variable name of the custom field.
How can I find the variable name of the custom field so I can access it?
I found out how to determine your custom variable name.
ADO has a bunch of APIs. The following will give you all the details of a specific work type. For my case I needed the "bug" work type.
/*
Api to display work type fields in JSON format
Replace {} with correct values
*/
https://dev.azure.com/{orginization}/{project}/_apis/wit/workitemtypes/{type}/fields?api-version=6.0
The resulting JSON will give you a whole list of variables. Here is what the System Variable and a Custom Variable look like.
The referenceName is the variable name you would use in your scripts, etc.
TL;DR -
Take your field name and remove all spacing and then put Custom. in front of it.
Custom.FieldNameWithNoSpace
Scenario: to have multiple Kubernetes deployments I have a skeleton.tf file that could create an app as per requirement with minimum variable changes and in different namespaces and I do not want to provide a default name so that I will give the input everytime I do a Terraform plan and apply
like
resource "kubernetes_deployment" "${var.deployment-1}" {
...
...
namespace= var.namespace_1
...
}
how do I achieve this? Is this supported, because I face a syntax interpolation error,
or
Invalid string literal: Template sequences are not allowed in this string. To include a literal "$", double it (as "$$") to escape it.
or
Invalid character: This character is not used within the language.
or
Invalid block definition: Either a quoted string block label or an opening brace ("{") is expected here.
I have read about the terraform workspaces but then, it would be a tedious task to be able to get the resource name as a dynamic input. any help or workarounds to this is appreciated.
The name given in the second label of a resource block is used only within the current Terraform module, so there is no need for it to be dynamically customizable. If you don't have a specific name to use then you can use a generic name like "main".
Because this is a Terraform-only name, Terraform will automatically deal with it appearing in possibly several different instances of your module, because the full address of a resource includes the address of the module that contains it. The whole result is therefore unique with in a Terraform configuration, and the resource's local name is unique within the module that declares it.
I am trying to assign the value of this stucture path to a fieldsymbol, but this path does not work because it has a table in it's path.
But with in the debugger this value of this path is shown correctly.
Is there a way to dynamically assign a component of a table line to a fieldsymbol, by passing one path?
If not then I will just read the table line and then use the path to get the wanted value.
ls_struct (Struct)
- SUPPLYCHAINTRADETRANSACTION (Struct)
- INCL_SUPP_CHAIN_ITEM (Table)
- ASSOCIATEDDOCUMENTLINEDOCUMENT (Element)
i_component_path = |IG_DDIC-SUPPLYCHAINTRADETRANSACTION-INCL_SUPP_CHAIN_ITEM[1]-ASSOCIATEDDOCUMENTLINEDOCUMENT|.
ASSIGN (i_component_path) TO FIELD-SYMBOL(<lg_value>).
IF <lg_value> IS NOT ASSIGNED.
return.
ENDIF.
<lg_value> won't be assigned
Solution by Sandra Rossi
The debugger has its own syntax and own logic, it doesn't apply the ASSIGN algorithm at all. With ABAP source code, you have to use ASSIGN twice, the first one to reach the internal table, then you select the first line, and the second one to reach the component of the line.
The debugger works completely differently, the debugger code works only in debug mode, you can't call the code from the debugger (i.e. if you call it, the kernel code used by the debugger will fail). No, there's no "abappath". There are the XSL transformation objects (xpath), but it's slow for what you ask.
Thank you very much
This seems to be a rather unexpected limitation of the ASSIGN statement. Probably worth a ticket to SAP's ABAP language group to clarify whether it's even a bug.
While this works:
ASSIGN data-some_table[ 1 ]-some_field TO FIELD-SYMBOL(<lv_source>).
the same expressed as a string doesn't:
ASSIGN (`data-some_table[ 1 ]-some_field`) TO FIELD-SYMBOL(<lv_source>).
Alternative 1 for (name) of the ABAP keyword documentation for the ASSIGN statement says that "[t]he name in name is structured in the same way as if specified directly".
However, this declaration is immediately followed by "the content of name must be the name of a data object which may contain offsets and lengths, structure component selectors, and component selectors for assigning structured data objects and attributes in classes or objects", a list that does not include the table expressions we would need here.
Inside a method of some class, I typed a field name that doesn't exist yet. I invoked the Generate > Field command. IDEA generated the field but placed it somewhere far up the class - probably at a position determined by Code Style > Arrangement.
Is there a way to configure IDEA to place newly generated code as close to the cursor as possible? E.g., in the example above I wanted the new field to be placed right above my method.
I am trying to populate the infoobject 0LOGSYS in a DSO when a load from a datasource occurs. The idea being that you could tell what sourcesystem the data was loaded from that is needed for a certain requirement. As of now I have a routine set up on a transformation rule for 0LOGSYS. No syntax errors, everything runs during the load, but no data is populated. Tried to debug but for some reason my BREAKPOINT is not getting picked up.
Here is the code that I have placed in the routine. Also, I am trying to do this without assigning any source field so maybe that is causing an issue. Not sure though.
TYPE-POOLS: RSSM.
Data: G_S_MINFO TYPE RSSM_S_MINFO.
CALL FUNCTION 'RSDG_ID_GET_FROM_LOGSYS'
EXPORTING
i_source_system = G_S_MINFO-LOGSYS
IMPORTING
e_soursysid = RESULT
EXCEPTIONS
id_not_found = 1.
Solved this a different way. There are runtime attributes that can be pulled from any request via the methods of "if_rsbk_request_admintab_view" which is instanciated automatically at the beginning of each transformation routine. Here is the code that I put in the routine.
*declaring a local variable like the result type LOGSYS
Data: lvSource like RESULT.
*runs a method to get the source system from the runtime attributes of
*the request
*"p_r_request" is an instance of "if_rsbk_request_admintab_view" which
*has many different methods for runtime attributes
lvSource = p_r_request->GET_LOGSYS( ).
RESULT = lvSource.
If this is the complete source code, it's not surprising that nothing is returned. You declare a new structured variable named G_S_MINFO, don't assign any value to it and return its contents. Unless you deleted the steps from your code sample that are supposed to fill the variable with values, it would be a grave bug if anything else than an initial value was returned.
EDIT: Even with the updated code, I still doubt this will work. Now you pass G_S_MINFO-LOGSYS to a function module that supposedly looks up some system ID without initializing it. Garbage in, garbage out. Or in this case, initial value in, initial value out.