I need to customize the Stripe Checkout template in Sylius 1.4.
Things I tried so far but did not work:
1- I added this config to config.yaml:
sylius_payum:
template:
layout: '#SyliusShop/payumlayout.html.twig'
obtain_credit_card: '#SyliusShop/obtainCheckoutToken.html.twig'
2- I tried to override #SyliusPayum/Action/obtainCheckoutToken.html.twig. Interestingly editing this file itself does not change the template!.
The only way that the template changes is to edit #Payum/Stripe/Action/obtainCheckoutToken.html.twig.
How I can override this file in Sylius?
So it turn out to be easy:
To override the file I needed to alter the config field of stripe_checkout record at sylius_gateway_config table of Sylius database as below.
UPDATE sylius_gateway_config SET config='{"publishable_key":"TEST_KEY","secret_key":"SECRET_KEY","payum.template.obtain_token":"SyliusPayumBundle::obtainCheckoutToken.html.twig","payum.template.layout":"SyliusPayumBundle::layout.html.twig"}' WHERE id=2
in my case the record id was 2.
SyliusPayumBundle::obtainCheckoutToken.html.twig and SyliusPayumBundle::layout.html.twig are the new overriding files.
The question is why the keys are not encrypted in the database and I think its not a good practice to have the override config at the database level.
Related
I am testing the azure-devops-migration-tools and have create a project using https://azuredevopsdemogenerator.azurewebsites.net/ (Parts Unlimited). I have generated the configuration.json and changed the Source and Target so I can test a migration, but I'm getting errors while migrating Work Items.
[15:14:41 ERR] Error running query
Microsoft.TeamFoundation.WorkItemTracking.Client.ValidationException: TF51005: The query references a field that does not exist. The error is caused by «ReflectedWorkItemId».
I've tried different options on the "ReflectedWorkItemIDFieldName" field, Scrum, Basic, Agile, Custom, empty but am still unable to migrate the work items.
How can I get the value to put on this field for the specific project?
Thanks,
Bruno
Quick Solution: Most ADO instances use the prefix 'custom' for new fields. Try "Custom.ReflectedWorkItemId" in your configuration.json to see if that resolves the problem.
More details: It's hard to tell without an actual configuration.JSON file to review. One possible problem is that you need to use the actual and full internal 'Name' of the ReflectedWorkItemID field. This doesn't show in ADO, or the Process Template when created. The recommendation is that you create a query referencing your custom field, and export the WIQL file (query file). Once you export the WIQL file, you can then open the file and see the full syntax of the custom field.
Exporting Queries: If you don't know how to do this, it can be done with VisualStudio. If you don't know how to do that, you can install this extension. It's a handy WIQL import/Export and editor. Install, and your ADO Queries with have an Edit in WIQL Editor option. Create a query that exposes your 'ReflectedWorkItemID' as a column, then edit that query in the WIQL editor and see the full names of the Reflected Work Items ID Feild. https://marketplace.visualstudio.com/items?itemName=ottostreifel.wiql-editor
SELECT
[System.Id],
[System.WorkItemType],
[System.Title],
[System.AssignedTo],
[System.ChangedBy],
[Custom.ReflectedWorkItemId]
FROM workitems
WHERE ...
I found a possible solution. I have created a custom process, change the process from the projects to this new one and add a new field. This is the field I'm using on the configuration.json and now I'm able to migrate work items
To make the migration in the "ReflectedWorkItemIDFieldName" you must do:
"Organization Settings" -> Process -> Select the process where you project are (Basic, Scrum, Agil, or CMMI).
then click on the 3 dots and create a new Inherited process.
Then with the inherited process, you are able to create a new field for each work item type. The name that you type (could be "IronMan") that name will be in your configuration file.
Is it possible to disable order editing when some conditions (like order status is shipped, but may be smtl else) are met?
Or disable LineItems editing but allow to edit order info?
Tried to add this lines to my current active order workflow and got nothing:
entity_restrictions:
test:
attribute: entity
field: customer_notes
tried to add this to one of workflow steps but again nothig
entity_acl:
update: false
delete: false
entity_restrictions and entity_acl are not used in any workflow.yml of oro bundles so is that functionality really implemented?
From the built-in features, you can use the workflow engine with the entity restrictions to make some form fields read-only based on conditions: https://doc.oroinc.com/backend/entities-data-management/workflows/configuration-reference/#entity-restrictions-configuration
Or create an access rule to hide the editing button and return 403 code for the editing page when conditions are met: https://doc.oroinc.com/backend/security/access-rules/#backend-security-bundle-access-rules
While I didnt found how to disable order edit via workflow like is was suggested previously here is the working way how to disable that via action configuration:
#MyBundle/Resources/config/oro/actions.yml
operations:
my_oro_order_edit
extends: UPDATE # this is for keeping all other properties same as in default
substitute_operation: UPDATE # replace UPDATE operation with current one
entities: ['Oro\Bundle\OrderBundle\Entity\Order'] # replacement will occur only if this operation will be matched by entity
for_all_entities: false
replace:
- preconditions
preconditions:
'#equal': [$internalStatus.id, 'open']
This substitutes UPDATE operation for order with my_oro_order_edit where conditions to allow UPDATE are changed - so edit button in order view page and orders grid will appear only for 'Open' orders. However this affects only buttons and its still possible to open order edit via direct link which should be prohibited using access rules
I have a metamodel.ecore which I generate its Model Code from the genmodel file (Right click on metamodel.genmodel ==> Select Generate Model Code);
However, some additional files (plugin.xml, plugin.properties and build.properties) are created during code generation. Since I just need the model code for my special purpose (e.g. I don't want my current project to be converted to a plugin project), I want to prevent generating these files.
Any simple way to do that?
With the properties view opened, select the root element in your genmodel. You need to do the following changes in your genmodel:
Set All / Bundle Manifest to false. It will prevent MANIFEST.MF to be generated.
Set Model / Model Plug-in ID to empty string or use the button on the top right of the properties view named "Restore Default Value" to set it to null. It will prevent the generation of the files plugin.xml, plugin.properties and build.properties.
Set Template & Merge / Update Classpath to false. This one is optional but with your use case, you may want EMF to stop messing out with your .classpath file.
I am trying to create a custom footer module for my site, It is my first time to create a module in prestashop 1.6 and I read about this article
http://doc.prestashop.com/display/PS16/Adding+a+configuration+page
my problem is i cannot fully understand if I need to create a custom table for my module or not
Configuration::updateValue('FOOTERCUSTOM_NAME', $footercustom);
as you can see in this code, the Configuration table is already created and Configuration::updateValue is a default prestashop code
if I wanted to create a input 1 , input 2 and input 3 at our configuration page in module backoffice and it automatically output the data in the database at my hookfooter.
what is the proper way of doing this?
Note that I already succeeded in creating a basic module, my main problem in how to insert data on my database using the configuration in my module
You don't have to a create a custom table. With the Configuration::updateValue method you can store/update values in the ps_configuration table and you can retrieve these values with the Configuration::get and Configuration::getMultiple methods. Values can be removed with the Configuration::deleteByName method.
Example:
Configuration::updateValue('FOOTERCUSTOM_INPUT_1', $input1Stored);
$input1Retrieved = Configuration::get('FOOTERCUSTOM_INPUT_1');
You can refer to this guide as well, still valid
http://doc.prestashop.com/display/PS15/Creating+a+PrestaShop+module#CreatingaPrestaShopmodule-ThegetContent()method
I added a custom eav attribute to my Magento application product entity using an installer script (Basically, following the procedure described here: Installing Custom Attributes with Your Module). Now, I want to use an update script to change (populate) the values of this attribute for each product according to some criteria (based on the product category). The script I attempted to use was essentially like this:
$attributeValues = array(...) // Map from $productId to the desired $value
$product = Mage::getModel('catalog/product');
foreach($attributeValues as $productId=>$value){
$product->load($productId)->setMyAttribute($value);
$product->save();
}
My questions would then be: Is it ok to use this level of abstraction (Mage::getModel('catalog/product') and its methods) in update scripts? If it isn't, how would you recommend to change these attribute values using update scripts (without requiring sql)?
The script I used (until now) has not worked and failed with the error:
Call to a member function getStoreIds() on a non-object
in a magento core file.
I don't know if this error is a Magento bug or is a problem with how I'm using the update scripts.
I'm using Magento 1.4.0.1
Data update scripts are the way to go
Simply use a data upgrade script for this. This is a script placed in the data folder instead of the sql folder. Those scripts run later then the database structure updates, and allow access to more functionality.
Example file names:
app/code/local/My/Module/data/your_setup/data-install-0.1.0.php
app/code/local/My/Module/data/your_setup/data-upgrade-0.1.0-0.2.0.php
This is already available in Magento 1.4.
Try adding Mage::app()->setUpdateMode(false) in your sql upgrade script. e.g.
$installer = new Mage_Eav_Model_Entity_Setup('core_setup');;
$installer->startSetup();
Mage::app()->setUpdateMode(false);
Mage::app()->setCurrentStore('your_store_code_here');
If you look in Mage::app()->getStore() you will see the following snippet that returns an incorrect store which is required for saving a product.
if (!Mage::isInstalled() || $this->getUpdateMode()) {
return $this->_getDefaultStore();
}