Reasons for Deny

[Andrew Kucheriavy]

Looking over the revisions functionality got me thinking about something else.

What do you guys think about standardizing Reasons for Denial in places where there is a deny button. For example Orders, Users, Revisions, etc.

There could be a section in config where you could specify what those are and when you press the Deny button in the toolbar we could have a pulldown menu similar to view that allows to choose a reason for denial from a list (an maybe a free text custom) that gets recorded as part of the record.

I've had many projects where this was requested by customers. For example, when they deny an order, they want to be able to specify why by selecting a predetermined reason:

For example:
Address does not validate
Credit card fraud suspected
Exceeds customer credit, etc....

[Dmitry A.]

Hi Andrew,

Thanks for sharing your ideas. I see where you are coming from and it makes sense to me too.

The questions that we are going to face are the following:

1. Have "Deny Reasons" as text or Language Label so it can be translated?

I am for making it nice so it's a Language Labels and can be fully used in any language.

2. Have "Deny Reasons" as option in the Grid grid so it can filtered as drop-down and nicely searched when needed, or again have it as text.

I am for making it as an drop-down option

While, I like the idea of having a Deny Reason field and functionality, but it might be a little too much trying to make it super universal when you can manage these options for ALL Prefixes (orders, links, articles, polls and whatever you can think of) via Admin interfaces. Right now, you can do this in PHP code with no problem.

My proposal, what if we do the following:

a. make sure our Decline/Deny button (or other button in general) has interface/capability for showing options (like with Add Product)

b. find all most used placed where we need to have Decline reason by default - Catalog Items, Orders... and create a list of "Reasons" options for these.

c. improve our In-Portal CORE so it can easily allow us Enabling these Reasons options for ANY Button and it's going to be connected to ANY specific database field within that Prefix (unit).

In result, we (programmers) can very simply and quickly connect ANY toolbar button to have this functionality where you have list of Options when you click on it and selected option will be saved in ANY specified field.

Let me know if it makes sense to you guys.

DA

[Alexander Obuhovich]

I'll try to explain one of possible implementations and we'll decide how hard is it to implement.

Implementing that functionality will require a new "DenyReason" field in each unit's table (Orders, Users) where it's appropriate. Also adding "DenyField" (like TitleField) in unit config could prove useful in cases, when non-standard deny reason field must be used. Event "OnMassDeclne" can be changed to automatically detect deny reason field and place message there.

We can place all possible deny reasons (for a specific unit/list) into single phrase in a 1 deny reason per line form, e.g.

deny reason1

deny reason2

deny reason3

other

Then new tag on list template will be given that phrase as input and as a result it will draw submenu. Maybe we even can place inputbox as last deny reason option for user to enter it by hand.

This maybe useful functionality, but according to https://groups.google.com/d/topic/in-portal-dev/vuGnrVy25cA/discussion discussion I won't be suggesting to include it by default in "core" module. This way "Deny" button will work as for now, but when this new "deny reason module" will be downloaded, then it will allow to specify deny reason, where possible.

In this modular approach I don't know what to do with order and user deny reasons, since they belong to different modules and we can't create single module to associate with all possible modules developed.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

well, tell me if I'm totally out of subject, but don't you think this
feature looks like a small piece of a -long awaited- CRM module?

The reason is that if you deny and order and give a reason, this make
the event particular to this order and user who placed this order.
Keeping track of this information is the start of "customer's relation
history", which is the main part of every CRM module.

If I'm wrong, I'll open another thread ;-)

2011/3/5 Alexander Obuhovich <aik....@gmail.com>:

[Dmitry A.]

Hi Alex,

I really want to see the Deny Reason available as Drop-drop Filter in Grids where functionality is used.

Free text might be a mess down the road - don't you think?

DA

[Alexander Obuhovich]

Ok, no free text in DenyReason field. DenyReason will be a regular field in database. We can even add it to a grid and display filters as you like.

[Dmitry A.]

What about having a single Label to store all options? Do we really need to go this far or what's the real advantage of it?

So basically you are proposing the same things as I did - option to quickly configure the DenyReason Field to support the Reasons on Deny button, what about doing it on the Edit Record? I guess we can just have a Options field there so the person can choose from Drop-down and that field will be placed below Status field I suppose.

DA

[Alexander Obuhovich]

I'm ok with single deny reason list, but I'm not ready to create separate table just for that purpose.

We can have configuration variable with all deny reasons listed (one reason per line). Then it's value can be used to populate all deny reason fields across all forms (where it's used).

[Dmitry A.]

No, I don't want to have a table for this too.

Also, we might need to have different Reasons for different Fields in the system. Think about Users, Orders, Links and so on - they all can have different Reasons for Denial.

DA

[Alexander Obuhovich]

Then why to propose to create single phase for all deny reasons in previous post and now tell me that you don't want it again?

[Dmitry A.]

I think it was mis-communication, I actually have asked you why do you want to have a single Label for it and not said that I wanted it :)

Quote: What about having a single Label to store all options? Do we really need to go this far or what's the real advantage of it?

DA

[Alexander Obuhovich]

I don't have an opinion on that, since I'm not the one who will be using this feature. In this discussion I can only suggest a technical approach that will be used during this feature implementation, when/if it comes to that.

[Dmitry A.]

Andrew, what do you think on technical parts we described?

DA