Hi, when i open a sales or purchase order and press (by accident) the delete button there is no confirmation but the order is deleted right away. Please add a confirmation box or undo button.
(desktop 21.3.76)
1 Like
You can use the History to undo the Delete so a Confirm Delete button would be an extra step for most of the time and for most users.
I think that the confirmation for any delete activity is good practice. In some instances, one could indicate not to be asked to confirm such actions in the future but it should be there.
If you delete a purchase or sales invoice than there is confirmation box. To be consistant use one or the other method. The most common way however is a confirmation box.
Prior to addition of the History file, every deletion included a confirmation step. Now that deletions can be undone, the risk of deleting important information by accident has been removed. The confirmation dialog box is being systematically removed tab by tab. I believe you will eventually see complete consistency across the entire program.
This is worrisome. I do not agree that âthe risk of deleting important information by accident has been removedâ is the right assumption. If one works hundreds of transactions it is difficult to identify in history where the changes are made, there is no search function in history. If several others worked on the file and by accident (not knowing) deleted something you will never fiind this error nor be able to reset it in history. For a small single person business this may be doable but not when larger and many different operators. This should be reconsidered rather than seeing as a good development. As mentioned the normal practice is to allow the user to disable the confirmation function, this should never be a default status. Thanks!
1 Like
It is not an assumption. It is a fact. Any transaction, customer, supplier, item, etc. that is accidentally deleted can be restored.
Yes, there is:
Most programs do not have a History file, nor do they allow deletions to be undone. Their confirmation step is no guarantee against deletion at any rate. Check a box and the entry is gone forever. With Managerâs History file, the situations are just not analogous.
You are right as far as 1) all can be restored from history, and that 2) a rudimentary search function exists in history, but difficult to get to something someone may have accidentally deleted. For example, a deleted by date and person-search advanced function would help. As for your final point, I am not sure why you can not have both? Why is there such insistence to not have a delete confirmation box that a user may or may not be disabled based on user preferences? I do not think one replaces the other, more that one complements the other. Unless you give me good reasons why such confirmation box should not exist, and having a history with undo definitely is not enough reason as it would only benefit the one accidentally making the mistake and not those that may not be aware of such error, then I remain the point to keep it.
This is not true either. Anyone with permission to view the History file can benefit from it. Often, in fact, the users making the mistakes are denied permissions for access to History, and only supervisors are given that permission.
But you are arguing with the wrong person. Many people complained about constantly being presented with confirmation dialog boxes. That is one of the reasons the developer implemented History the way he did. It speeds up normal transactions, while providing both audit and recovery capability.
If dealing with the wrong person why do you then feel the urge to provide extensive answers that I disagree with? You can just leave it to @lubos to respond if you are not in a position to.
1 Like
As a forum moderator, I am asked to explain, which I did, extensively. I can also provide historical context. Sometimes, I even know the developerâs reasoning, but not always. You are free to have different opinions about how the program works. But, when you start demanding that I justify decisions made by the developer or make changes to the program, you are wasting your time. Meanwhile, I will keep providing explanations wherever I can, because that is what Iâve been asked to do.
1 Like
That maybe be suitable for users with very basic simplistic businesses, but what about the Manager Users who have multiple users in multiple departments with hundreds if not thousands of transactions a day, do you expect them to have an employee to regularly review the History to see if any deletions have been done by mistake. Let say, the History has 100 deletes and after the review 3 were mistakes. Do you think that the extra step of reviewing the entire 100 delete History is more efficient then the extra step of a âConfirm Delete buttonâ which may have prevented the 3 from occurring. Not saying that mistakes wont still occur.
How so. A user who inadvertently hits the Delete button, without any warning dialog box, has a much greater risk of deleting important information as they could be totally oblivious to their mistake. The presence of the âwarning dialog boxâ as a primary upfront process reduces the risk by making the user at least double check their actions at the time the mistake is potentially being made.
The History facility is nothing more than a backup of transaction actions which is very useful for any recovery, but that secondary process is only useful if the mistaken deletion is actually known about.
It is only a fact if the accidental deletion is actually known about at the time. Let say a user mistakenly deletes a Sales Invoice, as it never gets paid, one can be none the wiser forever. At least the âwarning dialog boxâ could prevent the deletion from occurring at the source event.
Then those âmany peopleâ have a very low expectation of data security and Manager, if it is meaning to be professional accounting software, shouldnât be supporting their complaints. Despite the current History recovery process, I donât expect there would be many auditors who would support the removal of the mistaken deletion prevention process, the warning dialog box.
I whole heartedly agree, in fact, âthe risk of deleting important information by accident" has been exceedingly increased as the user NOW HAS NO DOUBLE CHECK on their actions, whereas the warning dialog box at least provided a active first line of defence, rather then the re-active History recovery.
In my view, this is just another instance of where Manager is increasingly depreciating / downgrading its quality by removing user friendly features and efficiencies. Currently why would one want to upgrade to inferior versions.
2 Likes
If we have to have a Confirm on a Delete transaction, can we also have one on an Update or Create transaction, please?
Or even Are you sure you want to Confirm the confirm?
Honestly, treating users as stupid is demeaning
1 Like
Huh?
Being smart overall and having stupid actions are not mutually exclusive. Even geniuses have their stupid moments.
Because wrong entries are there to been seen and examined and be an eye sore, thatâs off course as long as theyâre not deleted.
However, omissions are very hard to detect unless you purposely review each and every history entry (which isnât efficient). A simple confirmation is a much efficient control for prevention. While history is good for detection and correction.
I cannot provide a better case for prevention of accidental deletion than this:
1 Like
Several comments posted in this thread overlook one essential fact. When users (of any program) are constantly faced with confirmation questions in dialog boxes, they quickly learn to ignore them and just click on through. The confirmation step does not prevent anything from happening.
1 Like
I disagree. Why generalize such behaviour? I mentioned that those that want to disable it should have such option as with many programs. However, to just disable it is where the concern is. Everyone has their opinion on this, but up till today for example most software will prompt me if I really wanted to delete it and I am happy for it. I do not understand why there is so much âdefenseâ to what is asked for to not disable, I do not get that.
When executing an important action like in this case deleting sales or purchase orders, it is common practice for there to be a warning or confirmation. This common behavior in software and users are used to this (just like hot and cold water are left and right) and itâs not a good idea to deviate from this.
This is a bit exaggerated. Deleting something you do occasionally and not constantly.
I can see this conversation is getting heated.
The arguments and justifications and use cases are there for both points of view
- To confirm
- Not to confirm
But the real -life situations we seek to address are wildly varied. Software is used by tiny micro businesses, where there is one, or may be 2 users. The kind who press the wrong button, the transaction vanishes, and they instantly curse and open up the history, or use ctrl-Z or whatever the âundoâ action is.
Software is also used by big concerns, where a monkey is entering data, and presses a button, caring not what happens, or being distracted, and not noticing. A few hundred or thousand transactions later someone notices an oddity about an account, and it may be investigated. Or not.
How to provide software assistance?
There is certainly the argument that users with a buffered keyboard can be ahead of the processing, and use the confirm key automatically. This should not be acceptable.
Imposing a requirement for the extra keystrokes on every transaction is not efficient
Hoping that a search will show up the error over Mb of history is even less efficient.
We can
a) Make âconfirmâ a configurable action.
For the system?
Only per user, according to their security profile
This would be an improvement - new users, trainees, cautious people, can use confirm, but it is not imposed on everyone.
b) make confirm non-guessable
big improvement to confirm - you do not key the same entry for every confirm. You are obliged to engage brain, read the confirm character(s) and enter them. The enforced interruption to data entry provides a real chance to make people spot unintentional actions. Needs to be combined with being able to configure it as âoffâ as above.
c) provide a specific auditor / management report of all deleted records for end of a period. Management can check each (day) on what has been deleted, and satisfy themselves that all is well, or ask questions.
d) provide âundo last deleteâ functionality. after the intelligent user presses delete and the transaction vanishes, provide a means of restoring it from the data entry screen where it was made to vanish.
Simple, efficient, covers the issue for small users, and for competent large users where a mistaken button press causes inadvertent deletion. Both the delete and restore would be logged.
e) provide a view option for transactions which explicitly allows âdeleted recordsâ to be viewed alongside live records. (Different colour / strike through font etc)
At the touch of a button, when looking at accounts, Audiroes, managers, account supervisors can see that records were deleted, and can see what they would have contained.
The major issue Manager has is trying to satisfy the differing requirements for Audit and security between Mom & Pop outfits and real businesses. Scaleability is not just about database handling, but about the care and skill and knowledge of the people using the software. Mom&Pop= Care High, Skill Low. BigCompany=Care Low, Skill Low with outbreaks of Care High Skill High occasionally, professionally, and expensively.
Just my take⌠from the perspective of large systems with many, many low skill workers