prestashop / prestashop-specs Goto Github PK

On "Options" tab we can add files to product, we call them "attachments".

It seems I can use checkboxes on these files but I dont see what I can do to them.
So it seems

• I cannot edit a file
• I cannot delete a file
• no bulk actions available
  ... I can just add more files

Do you confirm ? @marionf

Hello guys,
Please to integrate this info into specs the way you see fit.

When a cart rule is created with a "free gift" action, the product selected as gift is gifted only one time. Consequently, the customer can pay/purchase additional quantity for this product. In other words, customer, can add more items from free gift to cart and he will be charged the additional items. The possible wanted quantity has to be:

minimal quantity < possible quantity <= available quantity

This is discussed in issue raised by @ebaurau and managed by @khouloudbelguith .
link: PrestaShop/PrestaShop#18129

@marionf I think I found a missing item 😄it was well hidden

Meet the "next combination" link

See at the top right

And if you click on it, you can navigate in the combinations of the product (and now you have a "previous combination" link too)

The issue ... what is the expected behavior if I

• open 1st combination
• modify settings
• then go to next combination WITHOUT HITTING SAVE
• modify settings of combination number two
• go to next combination, again without hitting save

Should we autosave modifications when switching tab ?

If we dont, user might modify, let's say, 10 combinations then hit "save". So we submit 10 combinations form at once. What happens if there is errors on one ? On two ?

So I suggest we autosave this 😬

Hello.

According to the PrestaShop documentation, there is no guideline that indicates that a Payment Module (PaymentModule object) should register a single payment option (PaymentOption object). On the contrary, the fact that an array must be returned from the hookPaymentOptions supports the tacit idea that multiple payment options are accepted:
https://devdocs.prestashop.com/1.7/modules/payment/

The payment module example in PrestaShop repository returns four paymentOptions in one PaymentModule:
https://github.com/PrestaShop/paymentexample/blob/master/paymentexample.php

For those cases in which multiple payment options are registered by a single payment module, the behavior of PrestaShop is inconsistent, and the possibility of having conflicts with third parties modules, or even with core features, increase.

Consider the following case:

• A payment module (Module X), register two payment options (Payment option A and B).
• After that is possible select any of those payment options in the checkout. Each one with different behaviors, checkout fields, forms, etc.
• However, in BO > Payment > Preferences only payment modules can be configured.
• However, in BO > Orders > Pick any order > Register manually a payment. Only payment modules are listed. Why is possible select payment options in the FO and not in the BE?
• However, in BO > Orders > Add Order > At the moment is required to select a payment method, only payment modules are listed.
• Consider conflicts between third party modules which makes PrestaShop a wild system. For example, most of the fee modules based on payment methods follows the same behavior. Only allows to filter by payment module. But that does not make any sense.

Perhaps I am missing something. Perhaps I am wrong. But I have read and consulted everything possible, from forums, the core code, to the spec repository, several modules, etc and I can't get a clear conclusion about it.

I think this is the right place to ask for guidelines about this. Is that correct?

Could you...

• Clear out the ambiguity behind these two concepts: (payment module, and payment options).
• Provide clear guidelines about the relation between these two objects, and to know if register more than one payment option per module is disallowed.

Then if is possible an is not explicitly disallowed, maybe is the right place to start defining the specifications about how should work at the future.

Thanks in advanced for consider this request - questions.

What happens if I start filling data for a tab then make this tab irrelevant ?

Example:

• I create a new Virtual product
• I start filling the "Virtual product" tab
• then I modify the product type from "virtual" to "standard"

What happens to the data I filled in "Virtual product" tab ?

I would like to suggest an improvement in the following specification; and therefore an improvement in the behavior of the checkout payment step.

https://github.com/PrestaShop/prestashop-specs/blob/master/content/1.7/front-office/checkout.md?plain=1#L35

In those cases in which the Payment Option have a form defined; or additional information defined; then that section of the payment method should be shown as well; since the payment method is selected.

• https://github.com/PrestaShop/PrestaShop/blob/1.7.8.1/src/Core/Payment/PaymentOption.php#L162-L167
• https://github.com/PrestaShop/PrestaShop/blob/1.7.8.1/src/Core/Payment/PaymentOption.php#L258-L263

Thanks in advanced for consider this suggestion.

Once the structure of the repository tree stop changing we should take the navigation that MatShir did in the first version of the README and put it back in the file.

In contributing.md, the last paragraph appears big and bold.

It seems to come from som Markdown.

Current state
This is how the translation for the theme works now

• Suppose, the theme uses 200 texts, of which only 1 is not in the core.
• When translating the theme it now show correctly only one text missing (thanks to this PR)
• I translate the missing text and change the wording of another translation
• I download the theme xlf files

I expect the xlf files for the theme to contain 2 translations, the one I added and the one I changed the wording, but the xlf files contain all the 200 texts of the theme.

Under The exported package it is written:

Note: If a given wording is not translated, then the original wording should be used as translation in the exported file.

This note is about not translated wordings. It is not about wordings that are translated, but not overridden.

The two options when overriding wording
The translation of themes is special, because the theme translation is overriding the core translation. This problem is not related to BO and FO-core translations.
For modules that have an official translation in app/Resources/translations, the translation overriding the core translation, like for themes. Thus, in the following, you can read also module every time theme is used.

If we translate a theme, most of the wordings are already present in the core translation. There will be few wordings specific to the theme, and there will be some translations that will be adapted.

1. All texts: As for now, the exported xlf files may contain all texts used in the theme, and their translations.
2. Only specific: The exported xlf files may contain only texts either specific to the theme or overridden core translations.

Purpose of the xlf files
As far as I understand, the purpose of the exported xlf files is twofold:

• Include the translation files in a public version of the theme
• Save the translations in a VCS instead of the database

Comparing the two options
Only specific has in my opinion several advantages over All texts:

• From a theoretic perspective, All texts is clearly in contradiction with DRY principles.
• In practice this means: When core translations are updated, the theme will never use them. The theme translation will be stuck at the wording at the time I first exported the xlf files.
• When the files contain Only specific translations, they are more meaningful when looking at them. Only the relevant few wording are there, instead of dozens. This specially applies when we use the xlf files for VCS
• When we include the translation files in a public version of the theme, we should never need All texts, because the core translation packs already contain all the other texts. This only requires to use the translation packs of the lowest supported PS version when generating the language files.

What are your thoughts about this?

Questions for https://github.com/PrestaShop/prestashop-specs/blob/master/back-office/catalog/catalog-price-rules.md

As I am going to migrate this, I checked how it behave. I saw some strange things.

• If you create a 1st condition group, then a 2nd one, you cannot edit the 1st. Adding conditions and hitting the "Add condition" button will add conditions to the 2nd group, not the 1st. The 1st group can never be edited again. => not an issue, but worth noticing
• If you create a 1st condition group, then a 2nd one, then you save and leave the page ; then you open again the page, hitting "Add condition" button will not do anything. You can now create a 3rd group of conditions but you cannot edit the 1st and 2nd groups. => I suggest some error message to explain this to user, else user thinks it's broken
• When you click "delete" on a condition inside a condition group, if you dont hit the "Save" button on the page (which is above), it will not be really deleted. => would be nice to find a UX way to tell user 'OK we understood your need but until you have saved, it will not be taken into account'
• If you hit "delete" on all conditions of a condition group, the group remains (empty) until you hit "save" => shall it be fixed by UX improvement ?
• You cannot add twice the same condition in a group (it makes sense), but nothing explains it: no error message, hitting the button "Add condition" will just do nothing => shall it be fixed by UX improvement ?
• It is not obvious that you need to hit "save" button to persist created condition groups, and the "save" button is small and above the form => shall it be fixed by UX improvement ? bigger button, multiple buttons ?

Guys I have some findings and I am not sure if they are already in the specs.

For a carrier to appear in FO checkout > Shipping, conditions are:

• Carrier is active.
• AND carrier is activated in region where customer address belong( if a customer address is in Europe, then Europe should be checked in "Shipping Locations and costs" in BO> carrier Edit page)
• AND carrier is selected in "Available carriers" for the product in BO> Product Edit page > Shipping.

Please correct me if I am wrong. Any ideas I miss are welcome.
It will be also invaluable if someone points me where to put them, so that I create a PR.

We need to make it clear how to contribute to this project.

It looks like the specs are contradictory in regards to the translation of modules:

In Installed module translations is written:

This catalogue is to be filtered by keeping only the translation domains whose name starts with "Modules.Nameofthemodule".

In Export Installed module translations is written:

Note: this export may include core translation domains if they are used by the module's files. However, only the wordings used by the module are to be included in the exported file.

fr-FR
├── ModulesymoduleAdmin.fr-FR.xlf
├── ModuleMymoduleShop.fr-FR.xlf
├── ShopNotificationsError.fr-FR.xlf
└── ...

ShopNotificationsError is explicitly stated in the example.

These two texts are contradictory. In fact, while translating, the core wordings (Shop and Admin) are not shown for translation. But when exporting the files, the spec expects them to be exported.
The real behavior is that modules always ignore core domains (Shop and Admin).

Considerations
I think the current behavior is correct. Modules may use existing core translations (Shop and Admin). But I cannot imagine a use case when it would be legitimate that a module translation overrides or extends wordings of domains other than Modules.

Proposed correction
I think in Export Installed module translations the note cited above should be removed.
Also the example should be corrected to:

fr-FR
├── ModulesMymoduleAdmin.fr-FR.xlf
├── ModulesMymoduleShop.fr-FR.xlf
└── ...

Please add a search-bar like in devdocs.

Also, I consider it a good idea to have the specs versioned with each of prestashop version, since they could change from one version to another.

During the Symfony migration, some Symfony controllers were created with the following access rules:

• index (display the page) can be accessed by a user if he is granted READ permission
• form submission requires either CREATE, UPDATE, DELETE permissions (depends on what the form does)

Others were created with the following access rules:

• index (display the page) can be accessed if the user is granted either READ, CREATE, UPDATE or DELETE permissions
• form submission requires either CREATE, UPDATE, DELETE permissions (depends on what the form does)
  The 2nd kind of controllers were implementing the rule "if you can modify it, you should be able to display it".

So there was 2 different behaviors being used in the backoffice.
There was a need to decide of a global rule to be applied systematically.

After discussing it the core team, we agreed to go for the 1st system:

• READ permission grants a BO user the ability to display the page
• CREATE, UPDATE and DELETE permission grants a BO user the ability to modify some of the page content

Following #197, a new main directory will be added to this repository: the 'Installer' directory. We should update the contribution guidelines, blog posts, etc. to mention.

Closed because issues need to be specified, we need to clarify the expected behavior for multi invoices regarding shipping fees management and discounts. The main problem is that we only have ONE Cart for multiple OrderInvoice so we have to manage weird computations to split the total among several invoices

One possible (and clean) solution would be to have one dedicated cart per invoice although it requires quite some changes in the database and model But we need to decide:

1. does each invoice have its dedicated shipping cost
2. can each invoice have a different Carrier
3. this means each invoice must have its Delivery slip
4. ... probably other issues ^^

Originally posted by @jolelievre in PrestaShop/PrestaShop#20776 (comment)

Images are broken in https://github.com/PrestaShop/prestashop-specs/blob/master/front-office/products-list.md

Whenever you have time guys, it will be invaluable if you give me help.

If we take the possible actions during the creation of cart rule from Catalog/Cart Rules / Create new cart rule, there are 16 cases:

Please to take a case(only 1 to 15) and give a comment . It may include:

• Should the case be allowed in back office?
• if yes, tell something about the 3 following things:
  
  Should I take the question from different angle?

Even with layman words, your contribution will be highly precious.

Hello,
After some thinking about the calculation of the shipping discount, I came up with the following draft . I hope I it is a good starting point for discussion about this important matter.

Some examples:

situation:
shop with:

• 3 products in catalog: product1, product2 and product3.
• 2 enabled non-free carriers: carrier1 with price1 and carrier2 with price2
• product1 has carrier1 as specific carrier.
• product2 has carrier2 as specific carrier.

1 . Case n>0

• 1or many cart rules with free shipping action, all without any restrictions.
• 1 or many cart rules with free shipping action, all with restrictions.

Examples:

• cart 1: product1 and product2 and product3.
  shipping discount = price1 + price2

• cart 2: product1 and product3
  shipping discount = price1 if product3 is carried by carrier1
  shipping discount = (price1+ price2) if product3 is carried by carrier2

• cart 3 : product2 and product3
  shipping discount = price2 if product3 is carried by carrier2
  shipping discount = (price1+ price2) if product3 is carried by carrier1

2. Case of n=0

• 0 cart rules with free shipping action without any restrictions (n=0).
• 2 cart rules with free shipping action with restrictions.
  • cartRule1 is restricted to carrier1
  • cartRule2 is restricted to product2

Examples:

• cart 1: product1
  shipping discount = price1

• cart 2: product2
  shipping discount = price2

• cart 3: product3
  shipping discount = 0

• cart 4: product1 and product2
  shipping discount = price1+price2

• cart 5: product2 and product3
  shipping discount = price2 if product3 shipped by carrier2
  shipping discount = (price1+ price2) if product3 shipped by carrier1

• cart 6: product1 and product3
  shipping discount = price1 if product3 shipped by carrier1
  shipping discount = 0 elsewhere

• cart 7: product1and product2 and product3
  shipping discount = (price2 + price1) if product3 shipped by carrier1
  shipping discount = price2 if product3 is shipped by carrier2

(Special thanks to @marionf, @matks, @Julievrz who already contributed to this VERY important matter.
The issue hugely affects how products are browsed by categories in FO).

What happens to the default category of a product P associated to category C when C is deleted and C is default category of P?

When merchant deletes category and chooses one of the two first options in modal (doesn't choose to delete associated products) THEN associate P to the parent category and set parent category as default.

some cases:

Behavior tests here: PrestaShop/PrestaShop#24668

Order splitting

Sometime PrestaShop will split a Cart in multiple Order with same Reference after a Payment.

Because this splitting is made by PrestaShop after the Payment, Customer has only paid Shipping Costs for one Order.

So PrestaShop will display a warning on Order view page to notify merchant the total order amount is not equal to total cart amount.

Possible cases

1. A product of Cart exceeds the price/weight range of carriers
2. A product of Cart is restricted to one Carrier (case described bellow)
3. Warehouse management in 1.6, removed in 1.7
4. Multi-shipping functionnality in 1.5 removed in 1.6
5. Others cases I don't know

➡️ Find every possible cases will cause Order splitting

How to handle that for PaymentModule

• Every PaymentModule will only update OrderState of the main Order, on module validation trigger by API (like bank validation return).
• Every child Order should be manually update by merchant because he needs to choose if additional shipping cost should be paid by Customer or if he take it in charge.

⚠️ This should be confirmed and documented

Related to PrestaShop/docs#508

README misses instructions on how to run locally the application

Hi @marionf the Product add/edit page mentions

The first step is to detail the behavior of each field per tab when creating / editing a product.
The second step of this document is to detail the type of each fields and error messages per tab.
The third step is to detail the multistore behavior.

https://github.com/PrestaShop/prestashop-specs/blob/master/back-office/catalog/catalog-products-add-edit.md

When can we get the 3rd step ? 😄it might bring some technical challenges that I'd like to explore early

Also it would be great, but it's a lot of work to know, for each field/input in Product page, how it behaves with multistore.

• For things like "product name" it's easy 😄
• But some fields are not multi-store compatible I guess (for example "product type": a product cannot be virtual for shop 1 and not-virtual for shop 2)
• Some inputs might have specific behaviors: what about specific prices ? can they be linked to multiple shops ? what about categories ? can you "link product A with category B on multiple shops" ?
• Some fields will have increased complexity because they involve lot of items: for example image upload : can you share images between multishops ? when I delete one image for 1 shop, should I really delete it or should I keep it but "unlink" it for this shop (and keep it for other shops). Actually I don't even know if this is possible

The very best would be, for each input, to tell us

• current multishop behavior (it can be used in multishop / it cannot be used / it's broken)
• expected multishop behavior

When running with hugo, I get 'found no layout file for "HTML" for kind "section"' error

List of missing or different behaviors between specs and product page on 1.7.7. Note that some of them are probably bugs.

• 1. In Product Listing - Link part : 1 missing link :

• Product image: Open the product in the same browser tab and on the basic settings tab. If there is no product image, there is no link

=> Fixed by #177

• 2. In Product Creation/Edit - Elements in all tabs : 5 missing behaviors (or bug on actual Product page ?) :

• Product list : When the quantity of a product is at 0 or negative, it's displayed on a red background
  
• Duplicate : Quantity (or combination quantity) is not duplicated (set to 0) => Bug , will be added during migration
• Duplicate : Quantity tab > Stock location is not duplicated (new product has an empty field) => Bug , will be added during migration
• Duplicate : Shipping tab > Available carriers is not duplicated (no carrier are selected after that) => Bug , will be added during migration
• Duplicate : Options tab > Files are not duplicated (the files are unchecked) => Bug , will be added during migration

3. In Product Creation/Edit - Basic settings tab, 2 suggestions, 2 missing infos and 3 issues :

• * Search category and Select category could be merged into only one point, since it's the same process.
• * Parent of the category : If two categories have the same name, only the first one is displayed : All should be displayed (with ID in front ?)

• Image upload : If I upload several images and one of them is too large (Advanced Parameters > Administration > Upload Quota), this image is not uploaded but there is no error message.
• Image upload : When uploading the following picture, I have an error. I uploaded another image, approximately same file size, but squared, so maybe it's the width of the image that triggers this bug.
  File uploaded :
  https://upload.wikimedia.org/wikipedia/commons/e/ea/Sydney_Harbour_Bridge_night.jpg
  Error :
  https://drive.google.com/file/d/1OYrPhmUz80tF7AiRh2YZZB4MmLebQPYJ/view?usp=sharing
• Delete [image] : What happens when we delete the cover image ?
• Add a brand : Maybe add that only one brand can be added ?
• Pack search for a product : Maybe add that each combination of a product with combination can be added ?

4. In Product Creation/Edit - Virtual product tab : 1 missing info

• In associated files, for Expiration date and Number of days fields : What happens if both fields are filled ? The first deadline reached is the one taken into account, or the last one ?
• Expiration date : What happens if product is buy after expiration date ?

5. In Product Creation/Edit - Combinations tab : 2 suggestions 3 questions 1 missing info

• "ISBN" field : On actual PS version, dash character is also accepted in this field (and it makes sense since ISBN are sometimes displayed with a dash in it, for example the « ISBN-13 » field on this Amazon book has a dash in it : https://www.amazon.com/gestion-projets-pour-nuls/dp/2754019847
  => This is also applicable to ISBN field in Product Creation/Edit - Options tab
• In "Bulk Action" and "Edit Combinations" : "Impact on weight" field : What happens when the impact on weight makes the product weight to be negative ? (should be 0, but it might be useful to add it to the spec, in order to avoid any unwanted behaviour)
• In Bulk Action : "Impact on price (tax excl.)" and "Impact on price (tax incl.)" : The line "When you change it, the same field in pricing tab is also updated." is false (probably a bad copy/paste)
• "MPN" field : The MPN is displayed in product details tab of the front-office and change accordingly to the selected combination.
• "Images" field : What is a « default » image ? And can we still select many images for each combination (this is not specified)

6. In Product Creation/Edit - Shipping tab : 2 missing info

• Additional shipping fees : Is this fee tax excluded ? And if there is a "Free shipping" voucher, is this shipping fee also free ?
• Available carriers : What is the expected behavior when all carriers are unchecked ?

7. In Product Creation/Edit - Pricing tab : 2 questions, 1 issue, 1 missing info

• I'm not sure to really understand how the "Price ecotax included" works : It appears the user can fill this field, but shouldn't it only be calculated using the "Price" (without ecotax) and the "Ecotax" fields ? Or does the "Price ecotax included" replace the standard "Price" field when Ecotax option is enabled ?
  Or do these fields replace the previous ones when Ecotax is enabled ?

• In "Display the "On sale!" flag on the product page, and on product listings" : The specification should use the English display instead of the French one (« ON SALE! »), or just « it displays a promotional banner » .
• "Retail price per unit (tax excl.)" and "Unity field" are displayed in FO only if both fields are filled.
• For "Priorities" choice : What happens if, for example, all priorities are the same (« Shop » for all 4 dropdown) : Which specific price is applied first ?

8. In Product Creation/Edit - SEO tab : 1 question and 1 issue

• I do not understand these two lines (the action seems to be the same, but the result is different ?)

If I edit the product name and if there is nothing in the meta title field, it’s displayed directly in the preview.
If I change the name of the product, the preview will not change until the meta title field is complete.

• "Indexation by search engines" : This field is in duplicate

9. In Product Creation/Edit - Options tab : 1 question 4 suggestions 1 missing info

• "Show price" field : The « volume discount » block is still displayed when « Show price » is disabled : Is this OK or should it be hidden too ?
• "ISBN" field : On actual PS version, dash character is also accepted in this field (and it makes sense since ISBN are sometimes displayed with a dash in it, for example the « ISBN-13 » field on this Amazon book has a dash in it : https://www.amazon.com/gestion-projets-pour-nuls/dp/2754019847
  => This is also applicable to ISBN field in Product Creation/Edit - Combinations tab
• ISBN, EAN, UPC and MPN fields are not displayed in FO, excepted when it’s added on combinations tab. This behavior seems weird to me : It should (IMHO) always be displayed when filled (no matter what type of product we are dealing with). If some on these fields are filled in Combinations Tab AND in Options Tab, the fields in Combinations Tab should be displayed on FO.
• "Label" field in customization : This field is required, I think it should be specified
• "Add" field in "Attach a new file" : «  If there is only 1 file and not checked » should be «  If there is no file checked »
• "Information message about suppliers" : This functionality does not exist anymore so this phrase should not be displayed : « “When using the advanced stock management tool (see Shop Parameters > Products settings), the values you define (price, references) will be used in supply orders.”

To have an easier navigation through the repo we should make sure all the existing files are located in the right folder.

Themes can override modules. Thus themes can contain module translations and add new module translations.

Currently, the translation UI for themes, displays these texts of the Modules* domains for translation. The xlf file export also exports them. After merging PrestaShop/PrestaShop#27422, everything will work correctly.

The spec should mention the translation of the Modules* for theme translation. It isn't mentioned neither under Front office translations nor under Export Theme translations

Which license should we use for the prestashop-specs project?

@ttoine what do you recommend?

Hi @hibatallahAouadni, you can leave it as TBS, I'll specify it as soon as possible, thank you.

Originally posted by @LouiseBonnard in PrestaShop/PrestaShop#19767 (comment)

Is your feature request related to a problem?
There is missing the field Company name in shop parameters. There is the field Shop name but often the the Shop name is not the same as the Company name. The Company name has to be printed on the invoice, delivery slip, credit memo... it is legal requirement.
We do not want to use the field Registration number also for company name, because we want to print e-shop company data in this order in pdf:
Company name
Shop name
Shop address line 1
Shop address line 2
Postal code
City
Country
Registration number

Describe the solution you'd like
Add new field Company name to e-shop parameters and use it in all pdfs and also all emails.

Additional context
BO > Shop parameters > Stores Contact details > missing field Company name