Re: [otrs] Add custom fields in Customer information

[Gerald Young]

BI> I would really need to have something shown in the Customer Info box if
the customer account is suspended
That's what I'm saying about changing the email address of the Customer. If
you prefix the word SUSPENDED to the email address, it will be obvious and
automatically address two different things. It's highly visible in the
Customer Info box. It also prevents email tickets from being assigned as
from this customer.

On Thu, Oct 11, 2012 at 10:57 AM, Bogdan Iosif wrote:

>
> Thanks, a lot, for the input.
>
> I'll keep the NewTicket hack in mind as a fallback.
>
> As far as notifications in agent / customer interfaces go... the
> CustomerAccept module is an interesting thing to know about but I can't
> imagine making use of it in my situation. In customer's interface I would
> really need to have something shown at all times if his account is in
> read-only mode. In agent's interface I would really need to have something
> shown in the Customer Info box if the customer account is suspended and,
> perhaps, have the ticket states changed to some special state that says
> something like "customer account suspended". This last part I think I can
> handle.
>
> /bogdan
>
> The CustomerAccept module is interesting and a good to know thing for one
> time notifications. However, I need to have a user connected on a read-only
> account aware at all times of this situation. I'll try having a dynamic
> field on all tickets that gets set and shows up when an account is in this
> situation.
>
>
> On Thu, Oct 11, 2012 at 4:44 PM, Gerald Young  wrote:
>
>> BI> you imply the customer account needs to be disabled,
>> I don't confirm this. Changing the email address is sufficient to block
>> incoming mail with the NewTicket hack. I only wanted to expand on your
>> inquiry "what happens if..." By default, random emails create tickets, even
>> if the user is disabled.
>>
>> Re: The second part ... basically group membership human carried
>> operation, yes. I'm not certain there will be a "SysConfig" able operation
>> for this. Modules can be created, of course, but OTRS by default only obeys
>> what you tell it.
>>
>> The CustomerAccept module is a one-shot popup message module that
>> requires all customers to read and acknowledge the popup message before
>> continuing. The "all customers" bit is what I'd suggest modifying to check
>> CustomerGroup membership (for instance, "Out of Service Contract") before
>> sending. One-shot being a rather loose term. This is like the following:
>> http://www.youtube.com/watch?v=NoJe_6rvVpY
>>  but
>> applied to Customers.
>>
>> The "error message" may be something that the login might throw if the
>> email address begins with "SUSPENDED". It's a thought, anyway.
>>
>>
>> On Thu, Oct 11, 2012 at 9:20 AM, Bogdan Iosif wrote:
>>
>>> Hi,
>>>
>>> Thanks for the reply. I read through it a couple of times but, because
>>> of out-of-my-league tech refs, my understanding is mediocre.
>>>
>>> Up until "The above can effectively handle the email part of this." I
>>> think I understood well. I hate to admit - because it involves .pm code
>>> changes - but I may need to look into it more. My understanding (please
>>> confirm/infirm) is that you imply the customer account needs to be
>>> disabled, which I do not want for reasons already explained in my initial
>>> reply. However, your whole email filtering proposal may be what I need in
>>> the end because I just tested what happens when I switch all Customer <->
>>> Groups permissions to read-only. The customer can't interact with tickets
>>> from the customer interface but he can still fully interact with OTRS via
>>> the email interface. New tickets get created and replies to older tickets
>>> have their answers added as new articles. So my idea of making access
>>> read-only is not really complete unless I can somehow block access via the
>>> email interface. (I'm still thinking about integrating somehow the
>>> customer-billing-problem event raised from the contract-management system
>>> with commands sent to the email server to blacklist customer's email
>>> address, just so that I would avoid changing any code in OTRS)
>>>
>>> The 2nd part of your reply I understood poorly. "Then procedure to click
>>> the checkbox..." did you meant human carried operation here? What I'm after
>>> is to integrate OTRS with a contract management system. When someone marks
>>> in that system that there is a billing problem with the customer, in OTRS
>>> the access suspension should occur automagically. Same thing when the
>>> billing problem is solved.
>>>
>>> The last paragraph I haven't understood almost at all because I don't
>>> know what CustomerAccept module is, but this remark "One in particular is
>>> to invoke the Error Message of the Login" peaked my interest even though I
>>> can't imagine how it's done.
>>>
>>> Thanks,
>>> Bogdan
>>>
>>>
>>>
>>> On Thu, Oct 11, 2012 at 3:08 PM, Gerald Young w

Re: [otrs] Add custom fields in Customer information

[Bogdan Iosif]

Thanks, a lot, for the input.

I'll keep the NewTicket hack in mind as a fallback.

As far as notifications in agent / customer interfaces go... the
CustomerAccept module is an interesting thing to know about but I can't
imagine making use of it in my situation. In customer's interface I would
really need to have something shown at all times if his account is in
read-only mode. In agent's interface I would really need to have something
shown in the Customer Info box if the customer account is suspended and,
perhaps, have the ticket states changed to some special state that says
something like "customer account suspended". This last part I think I can
handle.

/bogdan

The CustomerAccept module is interesting and a good to know thing for one
time notifications. However, I need to have a user connected on a read-only
account aware at all times of this situation. I'll try having a dynamic
field on all tickets that gets set and shows up when an account is in this
situation.

On Thu, Oct 11, 2012 at 4:44 PM, Gerald Young  wrote:

> BI> you imply the customer account needs to be disabled,
> I don't confirm this. Changing the email address is sufficient to block
> incoming mail with the NewTicket hack. I only wanted to expand on your
> inquiry "what happens if..." By default, random emails create tickets, even
> if the user is disabled.
>
> Re: The second part ... basically group membership human carried
> operation, yes. I'm not certain there will be a "SysConfig" able operation
> for this. Modules can be created, of course, but OTRS by default only obeys
> what you tell it.
>
> The CustomerAccept module is a one-shot popup message module that requires
> all customers to read and acknowledge the popup message before continuing.
> The "all customers" bit is what I'd suggest modifying to check
> CustomerGroup membership (for instance, "Out of Service Contract") before
> sending. One-shot being a rather loose term. This is like the following:
> http://www.youtube.com/watch?v=NoJe_6rvVpY
>  but
> applied to Customers.
>
> The "error message" may be something that the login might throw if the
> email address begins with "SUSPENDED". It's a thought, anyway.
>
>
> On Thu, Oct 11, 2012 at 9:20 AM, Bogdan Iosif wrote:
>
>> Hi,
>>
>> Thanks for the reply. I read through it a couple of times but, because of
>> out-of-my-league tech refs, my understanding is mediocre.
>>
>> Up until "The above can effectively handle the email part of this." I
>> think I understood well. I hate to admit - because it involves .pm code
>> changes - but I may need to look into it more. My understanding (please
>> confirm/infirm) is that you imply the customer account needs to be
>> disabled, which I do not want for reasons already explained in my initial
>> reply. However, your whole email filtering proposal may be what I need in
>> the end because I just tested what happens when I switch all Customer <->
>> Groups permissions to read-only. The customer can't interact with tickets
>> from the customer interface but he can still fully interact with OTRS via
>> the email interface. New tickets get created and replies to older tickets
>> have their answers added as new articles. So my idea of making access
>> read-only is not really complete unless I can somehow block access via the
>> email interface. (I'm still thinking about integrating somehow the
>> customer-billing-problem event raised from the contract-management system
>> with commands sent to the email server to blacklist customer's email
>> address, just so that I would avoid changing any code in OTRS)
>>
>> The 2nd part of your reply I understood poorly. "Then procedure to click
>> the checkbox..." did you meant human carried operation here? What I'm after
>> is to integrate OTRS with a contract management system. When someone marks
>> in that system that there is a billing problem with the customer, in OTRS
>> the access suspension should occur automagically. Same thing when the
>> billing problem is solved.
>>
>> The last paragraph I haven't understood almost at all because I don't
>> know what CustomerAccept module is, but this remark "One in particular is
>> to invoke the Error Message of the Login" peaked my interest even though I
>> can't imagine how it's done.
>>
>> Thanks,
>> Bogdan
>>
>>
>>
>> On Thu, Oct 11, 2012 at 3:08 PM, Gerald Young  wrote:
>>
>>> Sessions are by default (SysConfig Framework->Core::Session) 57600
>>> seconds/16 hours while actually in use and 21600 seconds/6 hours when idle.
>>> BI> I haven't yet investigated what happens if an account is disabled
>>> and the customer responds to an issue via email.
>>> The ticket gets created. It gets created as if it's a random user, but
>>> not connected to the account that you've disabled (unless perhaps the
>>> CustomerID is email address...
>>>
>>> There's a hack to PostMaster/NewTicket.pm to fix this.
>>> http://forums.otterhub.org/viewtopic.php?f=60&t=6586 t

Re: [otrs] Add custom fields in Customer information

[Gerald Young]

BI> you imply the customer account needs to be disabled,
I don't confirm this. Changing the email address is sufficient to block
incoming mail with the NewTicket hack. I only wanted to expand on your
inquiry "what happens if..." By default, random emails create tickets, even
if the user is disabled.

Re: The second part ... basically group membership human carried operation,
yes. I'm not certain there will be a "SysConfig" able operation for this.
Modules can be created, of course, but OTRS by default only obeys what you
tell it.

The CustomerAccept module is a one-shot popup message module that requires
all customers to read and acknowledge the popup message before continuing.
The "all customers" bit is what I'd suggest modifying to check
CustomerGroup membership (for instance, "Out of Service Contract") before
sending. One-shot being a rather loose term. This is like the following:
http://www.youtube.com/watch?v=NoJe_6rvVpY
but
applied to Customers.

The "error message" may be something that the login might throw if the
email address begins with "SUSPENDED". It's a thought, anyway.


On Thu, Oct 11, 2012 at 9:20 AM, Bogdan Iosif wrote:

> Hi,
>
> Thanks for the reply. I read through it a couple of times but, because of
> out-of-my-league tech refs, my understanding is mediocre.
>
> Up until "The above can effectively handle the email part of this." I
> think I understood well. I hate to admit - because it involves .pm code
> changes - but I may need to look into it more. My understanding (please
> confirm/infirm) is that you imply the customer account needs to be
> disabled, which I do not want for reasons already explained in my initial
> reply. However, your whole email filtering proposal may be what I need in
> the end because I just tested what happens when I switch all Customer <->
> Groups permissions to read-only. The customer can't interact with tickets
> from the customer interface but he can still fully interact with OTRS via
> the email interface. New tickets get created and replies to older tickets
> have their answers added as new articles. So my idea of making access
> read-only is not really complete unless I can somehow block access via the
> email interface. (I'm still thinking about integrating somehow the
> customer-billing-problem event raised from the contract-management system
> with commands sent to the email server to blacklist customer's email
> address, just so that I would avoid changing any code in OTRS)
>
> The 2nd part of your reply I understood poorly. "Then procedure to click
> the checkbox..." did you meant human carried operation here? What I'm after
> is to integrate OTRS with a contract management system. When someone marks
> in that system that there is a billing problem with the customer, in OTRS
> the access suspension should occur automagically. Same thing when the
> billing problem is solved.
>
> The last paragraph I haven't understood almost at all because I don't know
> what CustomerAccept module is, but this remark "One in particular is to
> invoke the Error Message of the Login" peaked my interest even though I
> can't imagine how it's done.
>
> Thanks,
> Bogdan
>
>
>
> On Thu, Oct 11, 2012 at 3:08 PM, Gerald Young  wrote:
>
>> Sessions are by default (SysConfig Framework->Core::Session) 57600
>> seconds/16 hours while actually in use and 21600 seconds/6 hours when idle.
>> BI> I haven't yet investigated what happens if an account is disabled and
>> the customer responds to an issue via email.
>> The ticket gets created. It gets created as if it's a random user, but
>> not connected to the account that you've disabled (unless perhaps the
>> CustomerID is email address...
>>
>> There's a hack to PostMaster/NewTicket.pm to fix this.
>> http://forums.otterhub.org/viewtopic.php?f=60&t=6586 talks about where
>> to hack such things in PostMaster/NewTicket.pm, but it's prevention of
>> unsolicited email tickets, not rejection of disabled users, but concepts
>> should similarly apply. (specifically, if you put an "x" in front of the
>> user's email address, for instance, the sender's email no longer exists in
>> the database, so further email tickets from the user are unsolicited.)
>>
>> If you further hack this to test if removing the x matches the email
>> address, you can use that as a flag to send an email to the sender (see the
>> subsequent post by MichaelR in that thread).
>>
>> The above can effectively handle the email part of this.
>>
>> As for the user interface part, whatever "x" is in your case will be
>> prepended to the email address. it could be "suspended-em...@address.tld".
>> This would be very obvious.
>>
>> Of course, if the information is in LDAP, you would need to modify this
>> at the LDAP side.
>>
>> This handles Agent knowledge.
>>
>> What's left? Notification to customers via web interface and set
>> read-only.
>> You've a basic handling of this. I don't know if you've done this, but
>

Re: [otrs] Add custom fields in Customer information

[Bogdan Iosif]

Hi,

Thanks for the reply. I read through it a couple of times but, because of
out-of-my-league tech refs, my understanding is mediocre.

Up until "The above can effectively handle the email part of this." I think
I understood well. I hate to admit - because it involves .pm code changes -
but I may need to look into it more. My understanding (please
confirm/infirm) is that you imply the customer account needs to be
disabled, which I do not want for reasons already explained in my initial
reply. However, your whole email filtering proposal may be what I need in
the end because I just tested what happens when I switch all Customer <->
Groups permissions to read-only. The customer can't interact with tickets
from the customer interface but he can still fully interact with OTRS via
the email interface. New tickets get created and replies to older tickets
have their answers added as new articles. So my idea of making access
read-only is not really complete unless I can somehow block access via the
email interface. (I'm still thinking about integrating somehow the
customer-billing-problem event raised from the contract-management system
with commands sent to the email server to blacklist customer's email
address, just so that I would avoid changing any code in OTRS)

The 2nd part of your reply I understood poorly. "Then procedure to click
the checkbox..." did you meant human carried operation here? What I'm after
is to integrate OTRS with a contract management system. When someone marks
in that system that there is a billing problem with the customer, in OTRS
the access suspension should occur automagically. Same thing when the
billing problem is solved.

The last paragraph I haven't understood almost at all because I don't know
what CustomerAccept module is, but this remark "One in particular is to
invoke the Error Message of the Login" peaked my interest even though I
can't imagine how it's done.

Thanks,
Bogdan


On Thu, Oct 11, 2012 at 3:08 PM, Gerald Young  wrote:

> Sessions are by default (SysConfig Framework->Core::Session) 57600
> seconds/16 hours while actually in use and 21600 seconds/6 hours when idle.
> BI> I haven't yet investigated what happens if an account is disabled and
> the customer responds to an issue via email.
> The ticket gets created. It gets created as if it's a random user, but not
> connected to the account that you've disabled (unless perhaps the
> CustomerID is email address...
>
> There's a hack to PostMaster/NewTicket.pm to fix this.
> http://forums.otterhub.org/viewtopic.php?f=60&t=6586 talks about where to
> hack such things in PostMaster/NewTicket.pm, but it's prevention of
> unsolicited email tickets, not rejection of disabled users, but concepts
> should similarly apply. (specifically, if you put an "x" in front of the
> user's email address, for instance, the sender's email no longer exists in
> the database, so further email tickets from the user are unsolicited.)
>
> If you further hack this to test if removing the x matches the email
> address, you can use that as a flag to send an email to the sender (see the
> subsequent post by MichaelR in that thread).
>
> The above can effectively handle the email part of this.
>
> As for the user interface part, whatever "x" is in your case will be
> prepended to the email address. it could be "suspended-em...@address.tld".
> This would be very obvious.
>
> Of course, if the information is in LDAP, you would need to modify this at
> the LDAP side.
>
> This handles Agent knowledge.
>
> What's left? Notification to customers via web interface and set read-only.
> You've a basic handling of this. I don't know if you've done this, but you
> may simplify by having a positive membership CREATE TICKETS group and READ
> TICKETS group and add all customers to both. Then procedure to click the
> checkbox for CREATE TICKETS membership when removing the SUSPENDED- part of
> the email address.
>
> To provide the notification:
> Probably a bit more hacking, but this is because it's a special case for
> your business.
>
> I may have some other thoughts on this if I have time. One in particular
> is to invoke the Error Message of the Login. Another would be to use a
> version of the CustomerAccept module rewritten for specific CustomerGroup
> membership. This would be a copy of CustomerAccept, implemented via
> Framework->Frontend::Customer with the CustomerAccept InfoKey and InfoFile
> set up. The *copy/mod* of CustomerAccept.pm would survive updates.The
> result would be a popup the user has to accept and you'd have "proof" of
> acknowledgement.
>
> On Thu, Oct 11, 2012 at 6:53 AM, Bogdan Iosif wrote:
>
>> Hi,
>>
>> I'm also looking into solving the "customer's support contract is in
>> trouble => reduce / cut his access to OTRS" problem, *without* changing
>> code shipped with OTRS (no HTML mods, no PL script tweaks, etc.) and in a
>> manner that can be automated (integrated with our contract management
>> system)
>>
>> = My conclusions so far

Re: [otrs] Add custom fields in Customer information

[Gerald Young]

Sessions are by default (SysConfig Framework->Core::Session) 57600
seconds/16 hours while actually in use and 21600 seconds/6 hours when idle.
BI> I haven't yet investigated what happens if an account is disabled and
the customer responds to an issue via email.
The ticket gets created. It gets created as if it's a random user, but not
connected to the account that you've disabled (unless perhaps the
CustomerID is email address...

There's a hack to PostMaster/NewTicket.pm to fix this.
http://forums.otterhub.org/viewtopic.php?f=60&t=6586 talks about where to
hack such things in PostMaster/NewTicket.pm, but it's prevention of
unsolicited email tickets, not rejection of disabled users, but concepts
should similarly apply. (specifically, if you put an "x" in front of the
user's email address, for instance, the sender's email no longer exists in
the database, so further email tickets from the user are unsolicited.)

If you further hack this to test if removing the x matches the email
address, you can use that as a flag to send an email to the sender (see the
subsequent post by MichaelR in that thread).

The above can effectively handle the email part of this.

As for the user interface part, whatever "x" is in your case will be
prepended to the email address. it could be "suspended-em...@address.tld".
This would be very obvious.

Of course, if the information is in LDAP, you would need to modify this at
the LDAP side.

This handles Agent knowledge.

What's left? Notification to customers via web interface and set read-only.
You've a basic handling of this. I don't know if you've done this, but you
may simplify by having a positive membership CREATE TICKETS group and READ
TICKETS group and add all customers to both. Then procedure to click the
checkbox for CREATE TICKETS membership when removing the SUSPENDED- part of
the email address.

To provide the notification:
Probably a bit more hacking, but this is because it's a special case for
your business.

I may have some other thoughts on this if I have time. One in particular is
to invoke the Error Message of the Login. Another would be to use a version
of the CustomerAccept module rewritten for specific CustomerGroup
membership. This would be a copy of CustomerAccept, implemented via
Framework->Frontend::Customer with the CustomerAccept InfoKey and InfoFile
set up. The *copy/mod* of CustomerAccept.pm would survive updates.The
result would be a popup the user has to accept and you'd have "proof" of
acknowledgement.

On Thu, Oct 11, 2012 at 6:53 AM, Bogdan Iosif wrote:

> Hi,
>
> I'm also looking into solving the "customer's support contract is in
> trouble => reduce / cut his access to OTRS" problem, *without* changing
> code shipped with OTRS (no HTML mods, no PL script tweaks, etc.) and in a
> manner that can be automated (integrated with our contract management
> system)
>
> = My conclusions so far =
>
> - Disabling a customer account is excessive as a 1st response to a problem
> with his support contract. It would result in him being unable to login and
> OTRS just saying "Login failed! Your user name or password was entered
> incorrectly." without an option to transmit additional info such as "...
> your account has been disabled because ...". There's another problem with
> disabling a customer account and that's OTRS leaving his existing sessions
> operational. Thus, the customer can still interact with OTRS for quite some
> time after his account was disabled if he had an active session before
> disabling occurred. It's non-obvious how session-killing-on-account-disable
> can happen because the provided "otrs.DeleteSessionIDs.pl" can't delete
> specific user session(s). It can either delete all active sessions or only
> those that have expired. I haven't yet investigated what happens if an
> account is disabled and the customer responds to an issue via email. That
> may yield other surprises.
>
> - Ideally, when a problem with his support contract occurs, the customer
> would have his access changed to a "read-only" mode until the problem is
> fixed. The only way I've found to do that is to change his permissions in
> "Customers <-> Groups" from "rw" to "ro". The trouble with this approach is
> that it requires manual intervention and remembering exactly for which
> groups you downgraded the rights (on some groups the customer may have
> permanent "ro" rights so when the support contract problem is fixed you
> need to know for which groups the access should be switched back to "rw"
> and for which groups it should be left to "ro").
>
> - There is no mechanism provisioned in OTRS to show a message to certain
> customers in the customer interface. Something like "There is a problem
> with your support contract!!!". Ideally, something like this would manifest
> itself in about the same manner as messages for admins do when they show up
> in the admin interface announcing "do not use root account for operational
> work" or "scheduler is not running".
>
> - The

Re: [otrs] Add custom fields in Customer information

[Bogdan Iosif]

Hi,

I'm also looking into solving the "customer's support contract is in
trouble => reduce / cut his access to OTRS" problem, *without* changing
code shipped with OTRS (no HTML mods, no PL script tweaks, etc.) and in a
manner that can be automated (integrated with our contract management
system)

= My conclusions so far =

- Disabling a customer account is excessive as a 1st response to a problem
with his support contract. It would result in him being unable to login and
OTRS just saying "Login failed! Your user name or password was entered
incorrectly." without an option to transmit additional info such as "...
your account has been disabled because ...". There's another problem with
disabling a customer account and that's OTRS leaving his existing sessions
operational. Thus, the customer can still interact with OTRS for quite some
time after his account was disabled if he had an active session before
disabling occurred. It's non-obvious how session-killing-on-account-disable
can happen because the provided "otrs.DeleteSessionIDs.pl" can't delete
specific user session(s). It can either delete all active sessions or only
those that have expired. I haven't yet investigated what happens if an
account is disabled and the customer responds to an issue via email. That
may yield other surprises.

- Ideally, when a problem with his support contract occurs, the customer
would have his access changed to a "read-only" mode until the problem is
fixed. The only way I've found to do that is to change his permissions in
"Customers <-> Groups" from "rw" to "ro". The trouble with this approach is
that it requires manual intervention and remembering exactly for which
groups you downgraded the rights (on some groups the customer may have
permanent "ro" rights so when the support contract problem is fixed you
need to know for which groups the access should be switched back to "rw"
and for which groups it should be left to "ro").

- There is no mechanism provisioned in OTRS to show a message to certain
customers in the customer interface. Something like "There is a problem
with your support contract!!!". Ideally, something like this would manifest
itself in about the same manner as messages for admins do when they show up
in the admin interface announcing "do not use root account for operational
work" or "scheduler is not running".

- There is no way to add dynamic fields to anything except tickets and
articles. So you can't easily mark a customer account as being "in trouble"
unless you use some convention and write something in his "Comment" field,
which would be a fragile solution, or if you use a different/additional
customer backend which is way more complicated than what I'm confident to
explore at this time. Even if you do mark a customer account as being "in
trouble", OTRS doesn't make it in any way easier for you to reduce his
access to the system.

= Solution I'm playing with =

1. Create a queue that all customers can access, dedicated to handling
customer support contract problems.

2. When such a problem occurs for customer X, automatically post a ticket
in this queue and assign it to customer X (via OTRS web services, generic
interface, etc.) and, in the OTRS database, "group_customer_user" table,
set permission_value to 0 for customer X (by user_id) where permission_key
is "rw", except for the group related to the queue from step 1. It is
possible that an entry in this table doesn't exist for "ro" permissions
(depending on how the "rw" permission was created from UI). If it doesn't
exist, create it. OTRS doesn't set permission_value to 0, it just deletes
the row. So by looking for 0 on that column when it comes to restore
customer X's access rights, you'll know you'll find entries modified by
this mechanism.

3. From now on, customer X has read-only access to all his previous tickets
and he can only interact with the tickets related to support contract
troubles.

4. When the support contract trouble is solved, update the table from step
2 by setting permission_value to 1 where it is 0 for the targeted customer.

There are more issues to take under consideration (I haven't finished
elaborating the whole solution) such as:

- How will agents know, just by working normally, that a ticket belongs to
a customer who's support contract is in trouble. A possible solution would
be to add a dynamic field to tickets that is automatically updated at step
2 for all non-closed tickets.

I hope I was clear and if you or anyone else has some feedback I would
warmly welcome it.

/bogdan

On Thu, Oct 11, 2012 at 10:21 AM, Adrià García-Alzórriz <
adria.garcia-alzor...@adam.es> wrote:

> Hi there,
>
> I'm interested in adding more fields in Customer details. It can be
> possible with OTRS? I think that Dynamic Fields are available only in
> Tickets or Articles.
>
> I try to keep helpdesk offers support if a customer didn't pay his
> previous bill, so a *visible* message (such pop-up, custom HTML) would
> be great.
>
> Disabling c

Re: [otrs] Add custom fields in Customer information

[Adrià García-Alzórriz]

El dj 11 de 10 de 2012 a les 12:17 +0200, en/na Roy Kaldung va escriure:
> On Oct 11, 2012, at 12:14 PM, Adrià García-Alzórriz 
>  wrote:
> > El dj 11 de 10 de 2012 a les 09:51 +0200, en/na Roy Kaldung va escriure:
> >> On Oct 11, 2012, at 9:21 AM, Adrià García-Alzórriz 
> >>  wrote:
> >>> Hi there,
> >>> 
> >>> I'm interested in adding more fields in Customer details. It can be
> >>> possible with OTRS? I think that Dynamic Fields are available only in
> >>> Tickets or Articles.
> >> 
> >> Yes, this is possible. Add as much fields as needed in the mapping 
> >> definition for the customer source.
> > 
> > Excuse my newbie question, but I can't find where is this option.
> > For example, I can't add more objects in
> > DynamicFields::ObjectType::Registration.
> > Could someone tell me how could be that, or forward me to the right
> > chapter in documentation?
> 
> 
> Check out http://doc.otrs.org/3.1/en/html/external-backends.html in the docs.
> These options are not available via SysConfig, you have to edit 
> Kernel/Config.pm.
> 

Thanks, I'm going to have a look.

-- 
Adrià García-Alzórriz 


signature.asc
Description: This is a digitally signed message part
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Add custom fields in Customer information

[Roy Kaldung]

On Oct 11, 2012, at 12:14 PM, Adrià García-Alzórriz 
 wrote:
> El dj 11 de 10 de 2012 a les 09:51 +0200, en/na Roy Kaldung va escriure:
>> On Oct 11, 2012, at 9:21 AM, Adrià García-Alzórriz 
>>  wrote:
>>> Hi there,
>>> 
>>> I'm interested in adding more fields in Customer details. It can be
>>> possible with OTRS? I think that Dynamic Fields are available only in
>>> Tickets or Articles.
>> 
>> Yes, this is possible. Add as much fields as needed in the mapping 
>> definition for the customer source.
> 
> Excuse my newbie question, but I can't find where is this option.
> For example, I can't add more objects in
> DynamicFields::ObjectType::Registration.
> Could someone tell me how could be that, or forward me to the right
> chapter in documentation?


Check out http://doc.otrs.org/3.1/en/html/external-backends.html in the docs.
These options are not available via SysConfig, you have to edit 
Kernel/Config.pm.

-Roy

-- 
Roy Kaldung
e-mail: r...@kaldung.com





-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Add custom fields in Customer information

[Adrià García-Alzórriz]

El dj 11 de 10 de 2012 a les 09:51 +0200, en/na Roy Kaldung va escriure:
> On Oct 11, 2012, at 9:21 AM, Adrià García-Alzórriz 
>  wrote:
> > Hi there,
> > 
> > I'm interested in adding more fields in Customer details. It can be
> > possible with OTRS? I think that Dynamic Fields are available only in
> > Tickets or Articles.
> 
> Yes, this is possible. Add as much fields as needed in the mapping definition 
> for the customer source.

Excuse my newbie question, but I can't find where is this option.
For example, I can't add more objects in
DynamicFields::ObjectType::Registration.
Could someone tell me how could be that, or forward me to the right
chapter in documentation?

Anyway, thanks Roy for your valuable answers.

-- 
Adrià García-Alzórriz 


signature.asc
Description: This is a digitally signed message part
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Re: [otrs] Add custom fields in Customer information

[Roy Kaldung]

On Oct 11, 2012, at 9:21 AM, Adrià García-Alzórriz 
 wrote:
> Hi there,
> 
> I'm interested in adding more fields in Customer details. It can be
> possible with OTRS? I think that Dynamic Fields are available only in
> Tickets or Articles.

Yes, this is possible. Add as much fields as needed in the mapping definition 
for the customer source.

> I try to keep helpdesk offers support if a customer didn't pay his
> previous bill, so a *visible* message (such pop-up, custom HTML) would
> be great.

You can solve this issue with some Javascript which looks for a specific field 
defined in the customer field mapping.

> Disabling customers or add text comments into customer's profile are
> insufficient for us beacause in first case the agent can't find the
> customer when opens a phone ticket; in the second one, if customer
> creates a ticket via mail it can be difficult to notice these kind of
> administrative messages.

One idea for incoming tickets via e-mail could be a customization which checks 
the customer's account details and add an note, decrease priority or whatever.

-Roy

-- 
Roy Kaldung
e-mail: r...@kaldung.com





-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs