Cannot edit order if payment method is cash on delivery in prestashop - prestashop-1.6

I have been searching for an answer to this question for a few hours now, but I can't find anything relevant.
The problem is the following: If i make an order and I choose to pay with bankwire or check, then I can edit, delete and add products to that specific order. If I use cash on delivery or another module that does the same thing then the buttons for edit, delete and add are not there.
Can anyone help me with this problem? Or at least point me in the right direction? I'm all out of ideas.

When the payment method is cash on delivery it creates the order with a different order state (preparation in progress) than with bank wire (awaiting confirmation). The order state "preparation in progress", by default, sets the order as paid and/or as validated. When paid, it doesn't allow the order to be altered.
You have 2 solutions, either change the order state "preparation in progress" in backoffice to not set the order paid and not validated, or override the module cash on delivery to use a different order state when creating the order.

Related

Visual data from logs

I have an app I'm working on that is a credits system for a store. A customer brings in items and receives a credit and then can turn around and use that credit towards certain goods in the store. I've set it up so every time a credit holder or credit is created,updated, or destroyed the event is logged. I'm wondering if there is an easy way to use the event data from the logs to create a dashboard displaying things such as X number of credits created and Y number of credits used today. This may not be the right way to go about doing this at all and if so feel free to guide me in another direction. Thanks in advance!
You should save the information into a database (in addition) to the log and operate on it in this fashion.
So for example, maybe you have a User it should be a Model and have credits which should be an integer. You can modify this value every time a transaction happens.
You can also create an associated model 'transactions' which belong_to the user and to find out transactions that happened on a certain day, you would be able to pull up all of the transactions of that user in a certain time range.
If your credits work similar to dollars and money. And your transactions are like orders, you may want to look into using the Spree gem. https://github.com/spree/spree
You definitely do not want to be reading from the logs to do very usual actions like you're describing.

Creating meaningful user stories

We are trying to use BDD to create a web service to supply data to a web page and then save the user's changes.
The story I have so far goes
Given I want the data for order number 1234
When I load the data
Then I have the data for order number 1234
What am I missing in my approach?
Are user stories not appropriate for this kind of task?
How do I go about formulating meaningful user stories?
[Update]
As a customer
I want to see my order
So that I can check it is what I expect
Given I have entered the order number
When I Click GO
Then I should see my order displayed on the screen
Here's how I'd write what you have so far:
Feature:
As a customer
I want to be able to view and change my orders
So that I can check that they're being processed as I expect and deal with them if they're not
Scenario:
Given I am a customer
And I have an order
When I go to the order
Then I should see the order
(I indented the way my tools seem to want me indent Cucumber, which is what I use, but that's not important.)
Here are at least some of the reasons why I'd rewrite it that way:
It is usual for several Scenarios that have to do with the same product feature (order management in this case) to be in the same Feature file, so the Feature section should have a broader scope than a single Scenario. Maybe this Feature should even include placing orders in the first place.
Givens are things that are true before the time period that the scenario is about, like the existence of the customer and the order. Actions during the scenario belong in Whens.
It's good to avoid UI detail like "click" and specific button names and "displayed on the screen". The scenario should focus on behavior. The When I go to the order step can encapsulate the details of going to the screen where you enter the number, entering the number, and clicking the button.
Likewise, all of the checks for different fields of the order that should be visible can be encapsulated in Then I should see the order.
I said "the order" rather than "my order" because And I have an order establishes that there's a single order with a special relationship with the scenario, and it's good to establish a language across all your scenarios that makes that relationship clear -- I always use "the" in that case. (This is a very small point.)
With those stylistic points taken care of, this is an OK scenario and I've certainly written many similar ones. To get to your real question, however:
Where Specflow-type tools really shine is when you use them to describe as complete a use case/user story as you can. For example:
Scenario:
Given I am a customer
And there is a product
When I go to the product page
Then I should see the product
When I add the product to my cart
And I check out
Then I should see that the order has been placed
And I should receive an order confirmation email
When I go to my orders
Then I should see the order listed
When I go to the order
Then I should see the order
When I cancel the order
Then I should see that the order has been cancelled
And I should receive an order cancellation email
When I go to my orders
Then I should not see the order listed
This is more valuable as an acceptance test, because it captures more requirements, and it's more powerful as an integration test, because it exercises more of the system, and fakes less of it. (In the short scenario we had to create an order artificially. Here we're doing it through the system.)

Purchasing one item multiple times in TInApppurchase in Delphi XE6

I have developed an application with Delphi XE6 including inappPurchase, I have defined the product as 'Consumable' in itunesConnect, but after purchasing one item, it won't let me buy another one.
In my application user should be able to buy 'n' number of licenses, in PurchaseProduct Method just takes productID as parameter so I need to call this method multiple times.
I thought defining another Product like as 10-Licenses would be a good idea, but there is no relation between this two Products, and ConsumeProduct Method just takes a ProductID not the number of consumtion.
Since lack of resources about that, I appreciate if some one gives me some hints, or best practices.
p.s. Is storing the number of purchased products in application good idea?
I found the solution but I don't know if it is correct or not:
I consume the product just right after purchasing, and I locally get the track of bought items.
if productquery is fill with list, actually u can consume. i put try finally end statement, and put consumeproduct after try. and it will work,
what do u mean by locally get the track of bought items?

RoR 3 Aproval on records

I have an blog where anyone can comment. I would like to approve the comments before they are published. I have a boolean field named "published" and I'm unsure what to do next. Can anyone point me in the right direction?
I can imagine several features :
you need to be be notified when a comment is created. If you're not expecting too much traffic, the application can notify you by email with the ActionMailer
you need an admin page where you'll see all the comments that are waiting from your approval. Use filters to ensure that only you have access to this page.
you'll certainly need to see the comments "in situ" before approving them. The blog page should display only "published" comments for average user, but for you it should display all comments, with a button to publish the ones waiting for approval.

Allow users to remove their account

I am developing a gallery which allows users to post photos, comments, vote and do many other tasks.
Now I think that it is correct to allow users to unsubscribe and remove all their data if they want to. However it is difficult to allow such a thing because you run the risk to break your application (e.g. what should I do when a comment has many replies? what should I do with pages that have many revisions by different users?).
Photos can be easily removed, but for other data (i.e. comments, revisions...) I thought that there are three possibilities:
assign it to the admin
assign it to a user called "removed-user"
mantain the current associations (i.e. the user ID) and only rename user's data (e.g. assign a new username such as "removed-user-24" and a non-existent e-mail such as "noreply-removed-user-24#mysite.com"
What are the best practices to follow when we allow users to remove their accounts? How do you implement them (particularly in Rails)?
I've typically solved this type of problem by having an active flag on user, and simply setting active to false when the user is deleted. That way I maintain referential integrity throughout the system even if a user is "deleted". In the business layer I always validate a user is active before allowing them to perform operations. I also filter inactive users when retrieving data.
The usual thing to do is instead of deleting them from a database, add a boolean flag field and have it be true for valid users and false for invalid users. You will have to add code to filter on the flag. You should also remove all relevant data from the user that you can. The primary purpose of this flag is to keep the links intact. It is a variant of the renaming the user's data, but the flag will be easier to check.
Ideally in a system you would not want to "hard delete" data. The best way I know of and that we have implemented in past is "soft delete". Maintain a status column in all your data tables which ideally refers to the fact whether the row is active or not. Any row when created is "Active" by default; however as entries are deleted; they are made inactive.
All select queries which display data on screen filter results for only "active records". This way you get following advantages:
1. Data Recovery is possible.
2. You can have a scheduled task on database level, which can take care of hard deletes of once in a way; if really needed. (Like a SQL procedure or something)
3. You can have an admin screen to be able to decide which accounts, entries etc you'd really want to mark for deletion
4. A temperory disabling of account can also be implemented with same solution.
In prod environments where I have worked on, a hard delete is a strict No-No. Infact audits are maintained for deletes also. But if application is really small; it'd be upto user.
I would still suggest a "virtual delete" or a "soft delete" with periodic cleanup on db level; which will be faster efficient and optimized way of cleaning up.
I generally don't like to delete anything and instead opt to mark records as deleted/unpublished using states (with AASM i.e. acts as state machine).
I prefer states and events to just using flags as you can use events to update attributes and send emails etc. in one foul swoop. Then check states to decide what to do later on.
HTH.
I would recommend putting in a delete date field that contains the date/time the user unsubscribed - not only to the user record, but to all information related to that user. The app should check the field prior to displaying anything. You can then run a hard delete for all records 30 days (your choice of time) after the delete date. This will allow the information not to be shown (you will probably need to update the app in a few places), time to allow the user to re-subscribe (accidental or rethinking) and a scheduled process to delete old data. I would remove ALL information about the member and any related comments about the member or their prior published data (photos, etc.)
I am sure it changing lot since update with Data Protection and GDPR, etc.
the reason I found this page as I was looking for advice because of new Apply policy on account deletion requirements extended https://developer.apple.com/news/?id=i71db0mv
We are using Ruby on Rails right now. Your answers seem a little outdated? or not or still useful right now
I was thinking something like that
create a new table “old_user_table” with old user_id , First name, Second name, email, and booking slug.
It will allow keep all users who did previous booking. And deleted their user ID in the app. We need to keep all records for booking for audit purpose in the last 5 years in the app.
the user setup with this app, the user but never booking, then the user will not transfer to “old_user_table” cos the user never booking.
Does it make sense? something like that?

Resources