Can non-admins be allowed read-only access to customer / companies details?

Hi, I managed to give full access to Customers / Companies modules for regular agents by including them in a newly created group - AgentCcGroup - and then adding this group in the following "Group ro" sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration - Frontend::Module###Admin - Frontend::Module###AdminCustomerUser - Frontend::Module###AdminCustomerCompany Trouble is, the resulting access type is full - i.e. the agents can do any modifications to customer / companies details - and I need the access type to be "read-only". Also, I'm confused by what "Group ro" means as I expected it to mean "read-only" but practice showed me otherwise. I was guided by this http://forums.otterhub.org/viewtopic.php?f=60&t=7561solution to the same problem but it doesn't touch too much on the read-only part of my requirement, it just ~implies it should work. Does anyone know if there is such a thing as "read-only" access to a module in the sense that the user can explore it's GUI but not make changes? (or even better, someone maybe solved this exact problem?) Thanks, Bogdan

Hi, I think I found the answer to my question in an older mailing list entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html Hi Cyrille,
That’s a common misunderstanding in OTRS!
Group_ro only means that you only need “ro” permissions to access the module.
What you can do within the module is not limited or controled by this setting.
The module AdminUser doesn’t have a deeper permission concept.
If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here.
...
Cheers, Nils
So unless anyone thinks the above answer is obsolete, I'll just assume that
read-only access is not achievable at this time through configuration.
/bogdan
On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif
Hi,
I managed to give full access to Customers / Companies modules for regular agents by including them in a newly created group - AgentCcGroup - and then adding this group in the following "Group ro" sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration
- Frontend::Module###Admin - Frontend::Module###AdminCustomerUser - Frontend::Module###AdminCustomerCompany
Trouble is, the resulting access type is full - i.e. the agents can do any modifications to customer / companies details - and I need the access type to be "read-only". Also, I'm confused by what "Group ro" means as I expected it to mean "read-only" but practice showed me otherwise.
I was guided by this http://forums.otterhub.org/viewtopic.php?f=60&t=7561solution to the same problem but it doesn't touch too much on the read-only part of my requirement, it just ~implies it should work.
Does anyone know if there is such a thing as "read-only" access to a module in the sense that the user can explore it's GUI but not make changes? (or even better, someone maybe solved this exact problem?)
Thanks, Bogdan

The details for an individual customer can be found from the Customer link
on creation of a new ticket (Options above body). As for customer company,
not really ability to "look up" except in the context that, with
CustomerCompanySupport enabled, the company information will indeed be
linked to the customer, and show in the Customer Info section of a given
ticket.
Also, if the information is an LDAP source or otherwise marked as ReadOnly
in Config.pm because the data entry is handled by the external data source
frontend (ADUC, SalesForce, etc.), modifications to the customer and
customer company information via the web interface won't be possible.
On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif
Hi,
I think I found the answer to my question in an older mailing list entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html
Hi Cyrille,
That’s a common misunderstanding in OTRS!
Group_ro only means that you only need “ro” permissions to access the module.
What you can do within the module is not limited or controled by this setting.
The module AdminUser doesn’t have a deeper permission concept.
If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here.
...
Cheers, Nils
So unless anyone thinks the above answer is obsolete, I'll just assume that read-only access is not achievable at this time through configuration.
/bogdan
On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif
wrote: Hi,
I managed to give full access to Customers / Companies modules for regular agents by including them in a newly created group - AgentCcGroup - and then adding this group in the following "Group ro" sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration
- Frontend::Module###Admin - Frontend::Module###AdminCustomerUser - Frontend::Module###AdminCustomerCompany
Trouble is, the resulting access type is full - i.e. the agents can do any modifications to customer / companies details - and I need the access type to be "read-only". Also, I'm confused by what "Group ro" means as I expected it to mean "read-only" but practice showed me otherwise.
I was guided by this http://forums.otterhub.org/viewtopic.php?f=60&t=7561solution to the same problem but it doesn't touch too much on the read-only part of my requirement, it just ~implies it should work.
Does anyone know if there is such a thing as "read-only" access to a module in the sense that the user can explore it's GUI but not make changes? (or even better, someone maybe solved this exact problem?)
Thanks, Bogdan
--------------------------------------------------------------------- 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

The information available in the "Customer Information" panel - as seen in
ticket zoom view - is incomplete compared with the amount of info that is
captured in the Customers / Companies module (accesible from the admin
interface). For example, we'll most likely have to make some inventive use
of the Comment field for Customers / Companies and so agents would need to
be able to inspect those fields at any time. AFAIK this is only possible in
OTRS's GUI through the Customers / Companies modules (please correct me if
I'm wrong).
The option of using an alternative customers identity backend is an
interesting one, especially if it would cause OTRS to automatically switch
the customers / companies modules in true read-only mode (please reconfirm).
I'm shooting from the hip with this followup question but: Is it possible
to create, through configs, a simple DB customer backend that consists of a
table stored in a MySQL db? I could create that with relative ease and it
would contain data replicated from one of our other systems.
Thanks again for the help,
/bogdan
On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young
The details for an individual customer can be found from the Customer link on creation of a new ticket (Options above body). As for customer company, not really ability to "look up" except in the context that, with CustomerCompanySupport enabled, the company information will indeed be linked to the customer, and show in the Customer Info section of a given ticket.
Also, if the information is an LDAP source or otherwise marked as ReadOnly in Config.pm because the data entry is handled by the external data source frontend (ADUC, SalesForce, etc.), modifications to the customer and customer company information via the web interface won't be possible.
On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif
wrote: Hi,
I think I found the answer to my question in an older mailing list entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html
Hi Cyrille,
That’s a common misunderstanding in OTRS!
Group_ro only means that you only need “ro” permissions to access the module.
What you can do within the module is not limited or controled by this setting.
The module AdminUser doesn’t have a deeper permission concept.
If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here.
...
Cheers, Nils
So unless anyone thinks the above answer is obsolete, I'll just assume that read-only access is not achievable at this time through configuration.
/bogdan
On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif
wrote: Hi,
I managed to give full access to Customers / Companies modules for regular agents by including them in a newly created group - AgentCcGroup - and then adding this group in the following "Group ro" sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration
- Frontend::Module###Admin - Frontend::Module###AdminCustomerUser - Frontend::Module###AdminCustomerCompany
Trouble is, the resulting access type is full - i.e. the agents can do any modifications to customer / companies details - and I need the access type to be "read-only". Also, I'm confused by what "Group ro" means as I expected it to mean "read-only" but practice showed me otherwise.
I was guided by this http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution to the same problem but it doesn't touch too much on the read-only part of my requirement, it just ~implies it should work.
Does anyone know if there is such a thing as "read-only" access to a module in the sense that the user can explore it's GUI but not make changes? (or even better, someone maybe solved this exact problem?)
Thanks, Bogdan
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

BI> The information available in the "Customer Information" panel - as seen
in ticket zoom view - is incomplete compared with the amount of info that
is captured in the Customers / Companies module
I have not encountered this to be true. If the field is filled, it will
show. If you've otherwise modified the information screen, or you're
gathering from a source that doesn't have a good CustomerUser Map in
Config.pm (Fields not mapped won't show).
BI> if it would cause OTRS to automatically switch the customers /
companies modules in true read-only mode (please reconfirm).
I don't confirm this. This is a static configuration in Config.pm
BI> Is it possible to create, through configs, a simple DB customer
backend that consists of a table stored in a MySQL db?
Possible to create a table through Configs? No
Possible to use an external db source as a CustomerUser backend? Yes. See
the docs.http://doc.otrs.org/3.1/en/html/customer-user-backend.html
On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif
The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module (accesible from the admin interface). For example, we'll most likely have to make some inventive use of the Comment field for Customers / Companies and so agents would need to be able to inspect those fields at any time. AFAIK this is only possible in OTRS's GUI through the Customers / Companies modules (please correct me if I'm wrong).
The option of using an alternative customers identity backend is an interesting one, especially if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm).
I'm shooting from the hip with this followup question but: Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? I could create that with relative ease and it would contain data replicated from one of our other systems.
Thanks again for the help, /bogdan
On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young
wrote: The details for an individual customer can be found from the Customer link on creation of a new ticket (Options above body). As for customer company, not really ability to "look up" except in the context that, with CustomerCompanySupport enabled, the company information will indeed be linked to the customer, and show in the Customer Info section of a given ticket.
Also, if the information is an LDAP source or otherwise marked as ReadOnly in Config.pm because the data entry is handled by the external data source frontend (ADUC, SalesForce, etc.), modifications to the customer and customer company information via the web interface won't be possible.
On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif
wrote: Hi,
I think I found the answer to my question in an older mailing list entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html
Hi Cyrille,
That’s a common misunderstanding in OTRS!
Group_ro only means that you only need “ro” permissions to access the module.
What you can do within the module is not limited or controled by this setting.
The module AdminUser doesn’t have a deeper permission concept.
If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here.
...
Cheers, Nils
So unless anyone thinks the above answer is obsolete, I'll just assume that read-only access is not achievable at this time through configuration.
/bogdan
On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif
wrote: Hi,
I managed to give full access to Customers / Companies modules for regular agents by including them in a newly created group - AgentCcGroup - and then adding this group in the following "Group ro" sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration
- Frontend::Module###Admin - Frontend::Module###AdminCustomerUser - Frontend::Module###AdminCustomerCompany
Trouble is, the resulting access type is full - i.e. the agents can do any modifications to customer / companies details - and I need the access type to be "read-only". Also, I'm confused by what "Group ro" means as I expected it to mean "read-only" but practice showed me otherwise.
I was guided by this http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution to the same problem but it doesn't touch too much on the read-only part of my requirement, it just ~implies it should work.
Does anyone know if there is such a thing as "read-only" access to a module in the sense that the user can explore it's GUI but not make changes? (or even better, someone maybe solved this exact problem?)
Thanks, Bogdan
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

I have not encountered this to be true. If the field is filled, it will show.
You're right, thanks for the tip! I just never thought anything would show
up beside first / last name / email.
Though, the GUI doesn't show anything beside CustomerID about the
customer's company, right?
-=-
Putting your answer about db customer back-end together with
http://doc.otrs.org/3.1/en/html/customer-user-backend.html seems to open
the possibility of switching the default OTRS db customer back-end in
read-only mode. For my needs, this would be ok when coupled with a way to
replicate tables customer_user, customer_company from our other systems.
Possible gotchas:
- do not change customer_user.login and *.customer_id
- generating the password in Windows will probably be a bitch - I just
found this possibly obsolete mention "The password is crypted like 'man 3
crypt' with crypt()" in this OTRS 1.3 manual version
http://doc.otrs.org/1.3/en/html/problems-misc.html
Do you see any other gotchas with this simple idea?
/bogdan
On Mon, Oct 15, 2012 at 4:50 PM, Gerald Young
BI> The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module
I have not encountered this to be true. If the field is filled, it will show. If you've otherwise modified the information screen, or you're gathering from a source that doesn't have a good CustomerUser Map in Config.pm (Fields not mapped won't show).
BI> if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm). I don't confirm this. This is a static configuration in Config.pm
BI> Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? Possible to create a table through Configs? No Possible to use an external db source as a CustomerUser backend? Yes. See the docs.http://doc.otrs.org/3.1/en/html/customer-user-backend.html
On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif
wrote: The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module (accesible from the admin interface). For example, we'll most likely have to make some inventive use of the Comment field for Customers / Companies and so agents would need to be able to inspect those fields at any time. AFAIK this is only possible in OTRS's GUI through the Customers / Companies modules (please correct me if I'm wrong).
The option of using an alternative customers identity backend is an interesting one, especially if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm).
I'm shooting from the hip with this followup question but: Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? I could create that with relative ease and it would contain data replicated from one of our other systems.
Thanks again for the help, /bogdan
On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young
wrote: The details for an individual customer can be found from the Customer link on creation of a new ticket (Options above body). As for customer company, not really ability to "look up" except in the context that, with CustomerCompanySupport enabled, the company information will indeed be linked to the customer, and show in the Customer Info section of a given ticket.
Also, if the information is an LDAP source or otherwise marked as ReadOnly in Config.pm because the data entry is handled by the external data source frontend (ADUC, SalesForce, etc.), modifications to the customer and customer company information via the web interface won't be possible.
On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif
wrote: Hi,
I think I found the answer to my question in an older mailing list entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html
Hi Cyrille,
That’s a common misunderstanding in OTRS!
Group_ro only means that you only need “ro” permissions to access the module.
What you can do within the module is not limited or controled by this setting.
The module AdminUser doesn’t have a deeper permission concept.
If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here.
...
Cheers, Nils
So unless anyone thinks the above answer is obsolete, I'll just assume that read-only access is not achievable at this time through configuration.
/bogdan
On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif
wrote: Hi,
I managed to give full access to Customers / Companies modules for regular agents by including them in a newly created group - AgentCcGroup - and then adding this group in the following "Group ro" sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration
- Frontend::Module###Admin - Frontend::Module###AdminCustomerUser - Frontend::Module###AdminCustomerCompany
Trouble is, the resulting access type is full - i.e. the agents can do any modifications to customer / companies details - and I need the access type to be "read-only". Also, I'm confused by what "Group ro" means as I expected it to mean "read-only" but practice showed me otherwise.
I was guided by this http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution to the same problem but it doesn't touch too much on the read-only part of my requirement, it just ~implies it should work.
Does anyone know if there is such a thing as "read-only" access to a module in the sense that the user can explore it's GUI but not make changes? (or even better, someone maybe solved this exact problem?)
Thanks, Bogdan
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

BI>the GUI doesn't show anything beside CustomerID about the customer's
company, right?
If CustomerCompanySupport is enabled in Config.pm, fields that are filled
will show. [this message will repeat].
BI> possibility of switching the default OTRS db customer back-end in
read-only mode
That's already possible. Copy the default CustomerUser keys from
Defaults.pm to Config.pm and set the ReadOnly flag. (Although it's always
this. Not changeable) You can, of course, use a different interface (php?
phpmyadmin?) to modify the CustomerUser table but I'd rather sync to
something that already can manage this away from OTRS.
BI>when coupled with a way to replicate tables customer_user,
customer_company from our other systems.
Note that any CustomerUser backend is a query, not a sync. (No replication.
Just Map).
Please look at Defaults.pm CustomerUser and read the comments in the
information. You can choose to have the whole backend as readonly or only
certain fields as readonly.
The CustomerUser Map determines what fields are shown. The comments tell
you what fields are necessary.
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown (1=always,2=lite), required, storage-type,
http-link, readonly, http-link-target, link class(es)
var: The variable that is being referenced through the web interface
frontend: The label as presented.
storage: The field from the data source
shown: 1 for always, 2 for lite, 0 for don't show
required: 0=no, 1=yes. Don't use 1/Not relevant in read only.
storage-type: the examples give var (string) or int.
http-link: a URL that wraps this field
readonly: 0=no, 1=yes. whether the field can be changed in the web interface
http-link-target: for instance, "_blank" (see HTML documentation for
targets)
link class(es): apparently, optional CSS class to apply to this link.
Sometimes this can be used for psuedo classes and Javascript ..
BI> do not change customer_user.login and *.customer_id
Query, not sync. just make sure the information is valid in the backend.
BI>generating the password in Windows will probably be a bitch
No. CustomerUser is not authentication. It's data.
Read this: http://forums.otterhub.org/viewtopic.php?f=60&t=16543
On Mon, Oct 15, 2012 at 10:31 AM, Bogdan Iosif
I have not encountered this to be true. If the field is filled, it will
show.
You're right, thanks for the tip! I just never thought anything would show up beside first / last name / email.
Though, the GUI doesn't show anything beside CustomerID about the customer's company, right?
-=-
Putting your answer about db customer back-end together with http://doc.otrs.org/3.1/en/html/customer-user-backend.html seems to open the possibility of switching the default OTRS db customer back-end in read-only mode. For my needs, this would be ok when coupled with a way to replicate tables customer_user, customer_company from our other systems.
Possible gotchas:
- do not change customer_user.login and *.customer_id - generating the password in Windows will probably be a bitch - I just found this possibly obsolete mention "The password is crypted like 'man 3 crypt' with crypt()" in this OTRS 1.3 manual version http://doc.otrs.org/1.3/en/html/problems-misc.html
Do you see any other gotchas with this simple idea?
/bogdan
On Mon, Oct 15, 2012 at 4:50 PM, Gerald Young
wrote: BI> The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module
I have not encountered this to be true. If the field is filled, it will show. If you've otherwise modified the information screen, or you're gathering from a source that doesn't have a good CustomerUser Map in Config.pm (Fields not mapped won't show).
BI> if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm). I don't confirm this. This is a static configuration in Config.pm
BI> Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? Possible to create a table through Configs? No Possible to use an external db source as a CustomerUser backend? Yes. See the docs.http://doc.otrs.org/3.1/en/html/customer-user-backend.html
On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif
wrote: The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module (accesible from the admin interface). For example, we'll most likely have to make some inventive use of the Comment field for Customers / Companies and so agents would need to be able to inspect those fields at any time. AFAIK this is only possible in OTRS's GUI through the Customers / Companies modules (please correct me if I'm wrong).
The option of using an alternative customers identity backend is an interesting one, especially if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm).
I'm shooting from the hip with this followup question but: Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? I could create that with relative ease and it would contain data replicated from one of our other systems.
Thanks again for the help, /bogdan
On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young
wrote: The details for an individual customer can be found from the Customer link on creation of a new ticket (Options above body). As for customer company, not really ability to "look up" except in the context that, with CustomerCompanySupport enabled, the company information will indeed be linked to the customer, and show in the Customer Info section of a given ticket.
Also, if the information is an LDAP source or otherwise marked as ReadOnly in Config.pm because the data entry is handled by the external data source frontend (ADUC, SalesForce, etc.), modifications to the customer and customer company information via the web interface won't be possible.
On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif
wrote: Hi,
I think I found the answer to my question in an older mailing list entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html
Hi Cyrille,
That’s a common misunderstanding in OTRS!
Group_ro only means that you only need “ro” permissions to access the module.
What you can do within the module is not limited or controled by this setting.
The module AdminUser doesn’t have a deeper permission concept.
If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here.
...
Cheers, Nils
So unless anyone thinks the above answer is obsolete, I'll just assume that read-only access is not achievable at this time through configuration.
/bogdan
On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif
wrote:
Hi,
I managed to give full access to Customers / Companies modules for regular agents by including them in a newly created group - AgentCcGroup - and then adding this group in the following "Group ro" sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration
- Frontend::Module###Admin - Frontend::Module###AdminCustomerUser - Frontend::Module###AdminCustomerCompany
Trouble is, the resulting access type is full - i.e. the agents can do any modifications to customer / companies details - and I need the access type to be "read-only". Also, I'm confused by what "Group ro" means as I expected it to mean "read-only" but practice showed me otherwise.
I was guided by this http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution to the same problem but it doesn't touch too much on the read-only part of my requirement, it just ~implies it should work.
Does anyone know if there is such a thing as "read-only" access to a module in the sense that the user can explore it's GUI but not make changes? (or even better, someone maybe solved this exact problem?)
Thanks, Bogdan
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

If CustomerCompanySupport is enabled in Config.pm, fields that are filled will show. [this message will repeat].
Right again Note that any CustomerUser backend is a query, not a sync. (No replication.
Just Map). [...] You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS. [...]
I think I get what you say and it's also what I've meant. I meant
replication as performed by a process / tool independent of OTRS with the
purpose of keeping data in customer_user, customer_company tables up to
date as dictated by our CRM system. I wasn't assuming any replication
capability being built-in OTRS, it would just query the customer data made
available to it. Mainly, I was aiming to re-use OTRS's default db client
back-end configuration by just switching it in read-only mode and updating
client info through a side channel.
I want to avoid switching to a LDAP based customer back-end for as long as
possible because we're using Active Directory and our licensing probably
doesn't cover including a couple hundred customers in AD. The alternative
would be something like OpenLDAP and I expect that to be a bumpy road
because non-AD LDAP servers on Windows is not a common occurrence.
Thank You,
/bogdan
On Mon, Oct 15, 2012 at 6:07 PM, Gerald Young
BI>the GUI doesn't show anything beside CustomerID about the customer's company, right? If CustomerCompanySupport is enabled in Config.pm, fields that are filled will show. [this message will repeat].
BI> possibility of switching the default OTRS db customer back-end in read-only mode That's already possible. Copy the default CustomerUser keys from Defaults.pm to Config.pm and set the ReadOnly flag. (Although it's always this. Not changeable) You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS.
BI>when coupled with a way to replicate tables customer_user, customer_company from our other systems. Note that any CustomerUser backend is a query, not a sync. (No replication. Just Map).
Please look at Defaults.pm CustomerUser and read the comments in the information. You can choose to have the whole backend as readonly or only certain fields as readonly.
The CustomerUser Map determines what fields are shown. The comments tell you what fields are necessary. # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es) var: The variable that is being referenced through the web interface frontend: The label as presented. storage: The field from the data source shown: 1 for always, 2 for lite, 0 for don't show required: 0=no, 1=yes. Don't use 1/Not relevant in read only. storage-type: the examples give var (string) or int. http-link: a URL that wraps this field readonly: 0=no, 1=yes. whether the field can be changed in the web interface http-link-target: for instance, "_blank" (see HTML documentation for targets) link class(es): apparently, optional CSS class to apply to this link. Sometimes this can be used for psuedo classes and Javascript ..
BI> do not change customer_user.login and *.customer_id Query, not sync. just make sure the information is valid in the backend.
BI>generating the password in Windows will probably be a bitch No. CustomerUser is not authentication. It's data. Read this: http://forums.otterhub.org/viewtopic.php?f=60&t=16543
On Mon, Oct 15, 2012 at 10:31 AM, Bogdan Iosif
wrote: I have not encountered this to be true. If the field is filled, it will
show.
You're right, thanks for the tip! I just never thought anything would show up beside first / last name / email.
Though, the GUI doesn't show anything beside CustomerID about the customer's company, right?
-=-
Putting your answer about db customer back-end together with http://doc.otrs.org/3.1/en/html/customer-user-backend.html seems to open the possibility of switching the default OTRS db customer back-end in read-only mode. For my needs, this would be ok when coupled with a way to replicate tables customer_user, customer_company from our other systems.
Possible gotchas:
- do not change customer_user.login and *.customer_id - generating the password in Windows will probably be a bitch - I just found this possibly obsolete mention "The password is crypted like 'man 3 crypt' with crypt()" in this OTRS 1.3 manual version http://doc.otrs.org/1.3/en/html/problems-misc.html
Do you see any other gotchas with this simple idea?
/bogdan
On Mon, Oct 15, 2012 at 4:50 PM, Gerald Young
wrote: BI> The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module
I have not encountered this to be true. If the field is filled, it will show. If you've otherwise modified the information screen, or you're gathering from a source that doesn't have a good CustomerUser Map in Config.pm (Fields not mapped won't show).
BI> if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm). I don't confirm this. This is a static configuration in Config.pm
BI> Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? Possible to create a table through Configs? No Possible to use an external db source as a CustomerUser backend? Yes. See the docs.http://doc.otrs.org/3.1/en/html/customer-user-backend.html
On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif
wrote: The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module (accesible from the admin interface). For example, we'll most likely have to make some inventive use of the Comment field for Customers / Companies and so agents would need to be able to inspect those fields at any time. AFAIK this is only possible in OTRS's GUI through the Customers / Companies modules (please correct me if I'm wrong).
The option of using an alternative customers identity backend is an interesting one, especially if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm).
I'm shooting from the hip with this followup question but: Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? I could create that with relative ease and it would contain data replicated from one of our other systems.
Thanks again for the help, /bogdan
On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young
wrote: The details for an individual customer can be found from the Customer link on creation of a new ticket (Options above body). As for customer company, not really ability to "look up" except in the context that, with CustomerCompanySupport enabled, the company information will indeed be linked to the customer, and show in the Customer Info section of a given ticket.
Also, if the information is an LDAP source or otherwise marked as ReadOnly in Config.pm because the data entry is handled by the external data source frontend (ADUC, SalesForce, etc.), modifications to the customer and customer company information via the web interface won't be possible.
On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif
wrote: Hi,
I think I found the answer to my question in an older mailing list entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html
Hi Cyrille, > > That’s a common misunderstanding in OTRS! > > Group_ro only means that you only need “ro” permissions to access the module. > > What you can do within the module is not limited or controled by this setting. > > The module AdminUser doesn’t have a deeper permission concept. > > If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here. > > ... > > Cheers, Nils > > So unless anyone thinks the above answer is obsolete, I'll just assume that read-only access is not achievable at this time through configuration.
/bogdan
On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif < bogdan.iosif@gmail.com> wrote:
> Hi, > > I managed to give full access to Customers / Companies modules for > regular agents by including them in a newly created group - AgentCcGroup - > and then adding this group in the following "Group ro" sections from > SysConfig -> Framework -> Frontend::Admin::ModuleRegistration > > - Frontend::Module###Admin > - Frontend::Module###AdminCustomerUser > - Frontend::Module###AdminCustomerCompany > > Trouble is, the resulting access type is full - i.e. the agents can > do any modifications to customer / companies details - and I need the > access type to be "read-only". Also, I'm confused by what "Group ro" means > as I expected it to mean "read-only" but practice showed me otherwise. > > I was guided by this > http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution to > the same problem but it doesn't touch too much on the read-only part of my > requirement, it just ~implies it should work. > > Does anyone know if there is such a thing as "read-only" access to a > module in the sense that the user can explore it's GUI but not make > changes? (or even better, someone maybe solved this exact problem?) > > Thanks, > Bogdan >
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

BI> Mainly, I was aiming to re-use OTRS's default db client back-end
configuration by just switching it in read-only mode and updating client
info through a side channel.
:) yep. Sounds good to me. :)
BI> because we're using Active Directory and our licensing probably doesn't
cover including a couple hundred customers in AD.
This is an interesting issue. You're not using file/print, you're just
storing data. It appears either 1 device (OTRS server) or 1 user (ldap
lookup user) CAL will be the actual "user" of the services to look up the
information, regardless of how many results are returned.
http://www.microsoft.com/licensing/about-licensing/client-access-license.asp...
On Mon, Oct 15, 2012 at 12:11 PM, Bogdan Iosif
If CustomerCompanySupport is enabled in Config.pm, fields that are filled
will show. [this message will repeat].
Right again
Note that any CustomerUser backend is a query, not a sync. (No
replication. Just Map). [...] You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS. [...]
I think I get what you say and it's also what I've meant. I meant replication as performed by a process / tool independent of OTRS with the purpose of keeping data in customer_user, customer_company tables up to date as dictated by our CRM system. I wasn't assuming any replication capability being built-in OTRS, it would just query the customer data made available to it. Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel.
I want to avoid switching to a LDAP based customer back-end for as long as possible because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. The alternative would be something like OpenLDAP and I expect that to be a bumpy road because non-AD LDAP servers on Windows is not a common occurrence.
Thank You, /bogdan
On Mon, Oct 15, 2012 at 6:07 PM, Gerald Young
wrote: BI>the GUI doesn't show anything beside CustomerID about the customer's company, right? If CustomerCompanySupport is enabled in Config.pm, fields that are filled will show. [this message will repeat].
BI> possibility of switching the default OTRS db customer back-end in read-only mode That's already possible. Copy the default CustomerUser keys from Defaults.pm to Config.pm and set the ReadOnly flag. (Although it's always this. Not changeable) You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS.
BI>when coupled with a way to replicate tables customer_user, customer_company from our other systems. Note that any CustomerUser backend is a query, not a sync. (No replication. Just Map).
Please look at Defaults.pm CustomerUser and read the comments in the information. You can choose to have the whole backend as readonly or only certain fields as readonly.
The CustomerUser Map determines what fields are shown. The comments tell you what fields are necessary. # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es) var: The variable that is being referenced through the web interface frontend: The label as presented. storage: The field from the data source shown: 1 for always, 2 for lite, 0 for don't show required: 0=no, 1=yes. Don't use 1/Not relevant in read only. storage-type: the examples give var (string) or int. http-link: a URL that wraps this field readonly: 0=no, 1=yes. whether the field can be changed in the web interface http-link-target: for instance, "_blank" (see HTML documentation for targets) link class(es): apparently, optional CSS class to apply to this link. Sometimes this can be used for psuedo classes and Javascript ..
BI> do not change customer_user.login and *.customer_id Query, not sync. just make sure the information is valid in the backend.
BI>generating the password in Windows will probably be a bitch No. CustomerUser is not authentication. It's data. Read this: http://forums.otterhub.org/viewtopic.php?f=60&t=16543
On Mon, Oct 15, 2012 at 10:31 AM, Bogdan Iosif
wrote: I have not encountered this to be true. If the field is filled, it will
show.
You're right, thanks for the tip! I just never thought anything would show up beside first / last name / email.
Though, the GUI doesn't show anything beside CustomerID about the customer's company, right?
-=-
Putting your answer about db customer back-end together with http://doc.otrs.org/3.1/en/html/customer-user-backend.html seems to open the possibility of switching the default OTRS db customer back-end in read-only mode. For my needs, this would be ok when coupled with a way to replicate tables customer_user, customer_company from our other systems.
Possible gotchas:
- do not change customer_user.login and *.customer_id - generating the password in Windows will probably be a bitch - I just found this possibly obsolete mention "The password is crypted like 'man 3 crypt' with crypt()" in this OTRS 1.3 manual version http://doc.otrs.org/1.3/en/html/problems-misc.html
Do you see any other gotchas with this simple idea?
/bogdan
On Mon, Oct 15, 2012 at 4:50 PM, Gerald Young
wrote: BI> The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module
I have not encountered this to be true. If the field is filled, it will show. If you've otherwise modified the information screen, or you're gathering from a source that doesn't have a good CustomerUser Map in Config.pm (Fields not mapped won't show).
BI> if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm). I don't confirm this. This is a static configuration in Config.pm
BI> Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? Possible to create a table through Configs? No Possible to use an external db source as a CustomerUser backend? Yes. See the docs.http://doc.otrs.org/3.1/en/html/customer-user-backend.html
On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif
wrote: The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module (accesible from the admin interface). For example, we'll most likely have to make some inventive use of the Comment field for Customers / Companies and so agents would need to be able to inspect those fields at any time. AFAIK this is only possible in OTRS's GUI through the Customers / Companies modules (please correct me if I'm wrong).
The option of using an alternative customers identity backend is an interesting one, especially if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm).
I'm shooting from the hip with this followup question but: Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? I could create that with relative ease and it would contain data replicated from one of our other systems.
Thanks again for the help, /bogdan
On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young
wrote: The details for an individual customer can be found from the Customer link on creation of a new ticket (Options above body). As for customer company, not really ability to "look up" except in the context that, with CustomerCompanySupport enabled, the company information will indeed be linked to the customer, and show in the Customer Info section of a given ticket.
Also, if the information is an LDAP source or otherwise marked as ReadOnly in Config.pm because the data entry is handled by the external data source frontend (ADUC, SalesForce, etc.), modifications to the customer and customer company information via the web interface won't be possible.
On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif
wrote: > Hi, > > I think I found the answer to my question in an older mailing list > entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html > > Hi Cyrille, >> >> That’s a common misunderstanding in OTRS! >> >> Group_ro only means that you only need “ro” permissions to access the module. >> >> What you can do within the module is not limited or controled by this setting. >> >> The module AdminUser doesn’t have a deeper permission concept. >> >> If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here. >> >> ... >> >> Cheers, Nils >> >> > So unless anyone thinks the above answer is obsolete, I'll just > assume that read-only access is not achievable at this time through > configuration. > > /bogdan > > > On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif < > bogdan.iosif@gmail.com> wrote: > >> Hi, >> >> I managed to give full access to Customers / Companies modules for >> regular agents by including them in a newly created group - AgentCcGroup - >> and then adding this group in the following "Group ro" sections from >> SysConfig -> Framework -> Frontend::Admin::ModuleRegistration >> >> - Frontend::Module###Admin >> - Frontend::Module###AdminCustomerUser >> - Frontend::Module###AdminCustomerCompany >> >> Trouble is, the resulting access type is full - i.e. the agents can >> do any modifications to customer / companies details - and I need the >> access type to be "read-only". Also, I'm confused by what "Group ro" means >> as I expected it to mean "read-only" but practice showed me otherwise. >> >> I was guided by this >> http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution to >> the same problem but it doesn't touch too much on the read-only part of my >> requirement, it just ~implies it should work. >> >> Does anyone know if there is such a thing as "read-only" access to >> a module in the sense that the user can explore it's GUI but not make >> changes? (or even better, someone maybe solved this exact problem?) >> >> Thanks, >> Bogdan >> > > > --------------------------------------------------------------------- > 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 >
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

This is an interesting issue. You're not using file/print, you're just storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
:) It's shockingly expensive to run Microsoft infrastructures legally but
the fact is that any user accesing Windows Server for any service is
required to have a Windows Server CAL. This is true regardless of the exact
path a user takes to consume the service exposed by Windows Server. In our
case, OTRS would act as something that is called multiplexing software, for
licensing purposes. That is to say that OTRS intermediates access to the
Active Directory Windows Server service for authentication. So you would
need one Windows Server CAL for each OTRS user that is registered in Active
Directory (agent/customer it doesn't matter). The prices for CALs - and all
other licenses - vary wildly based on how many you buy and the way you buy
them (retail or volume licensing / subscriptions). There are a couple of
specific situations where you don't require a CAL for
over-the-Internet-users of web applications hosted on Windows Server.
However, AFAIK there are a couple of hooks in those conditions that would
catch you so that you require a CAL if the user is not anonymous.
Bottom line is: Microsoft licensing is very very complicated (ensuring you
are most likely not perfectly legal ok at all times) and very very
expensive.
On Mon, Oct 15, 2012 at 8:07 PM, Gerald Young
BI> Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel. :) yep. Sounds good to me. :)
BI> because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. This is an interesting issue. You're not using file/print, you're just storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
http://www.microsoft.com/licensing/about-licensing/client-access-license.asp...
On Mon, Oct 15, 2012 at 12:11 PM, Bogdan Iosif
wrote: If CustomerCompanySupport is enabled in Config.pm, fields that are filled
will show. [this message will repeat].
Right again
Note that any CustomerUser backend is a query, not a sync. (No
replication. Just Map). [...] You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS. [...]
I think I get what you say and it's also what I've meant. I meant replication as performed by a process / tool independent of OTRS with the purpose of keeping data in customer_user, customer_company tables up to date as dictated by our CRM system. I wasn't assuming any replication capability being built-in OTRS, it would just query the customer data made available to it. Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel.
I want to avoid switching to a LDAP based customer back-end for as long as possible because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. The alternative would be something like OpenLDAP and I expect that to be a bumpy road because non-AD LDAP servers on Windows is not a common occurrence.
Thank You, /bogdan
On Mon, Oct 15, 2012 at 6:07 PM, Gerald Young
wrote: BI>the GUI doesn't show anything beside CustomerID about the customer's company, right? If CustomerCompanySupport is enabled in Config.pm, fields that are filled will show. [this message will repeat].
BI> possibility of switching the default OTRS db customer back-end in read-only mode That's already possible. Copy the default CustomerUser keys from Defaults.pm to Config.pm and set the ReadOnly flag. (Although it's always this. Not changeable) You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS.
BI>when coupled with a way to replicate tables customer_user, customer_company from our other systems. Note that any CustomerUser backend is a query, not a sync. (No replication. Just Map).
Please look at Defaults.pm CustomerUser and read the comments in the information. You can choose to have the whole backend as readonly or only certain fields as readonly.
The CustomerUser Map determines what fields are shown. The comments tell you what fields are necessary. # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es) var: The variable that is being referenced through the web interface frontend: The label as presented. storage: The field from the data source shown: 1 for always, 2 for lite, 0 for don't show required: 0=no, 1=yes. Don't use 1/Not relevant in read only. storage-type: the examples give var (string) or int. http-link: a URL that wraps this field readonly: 0=no, 1=yes. whether the field can be changed in the web interface http-link-target: for instance, "_blank" (see HTML documentation for targets) link class(es): apparently, optional CSS class to apply to this link. Sometimes this can be used for psuedo classes and Javascript ..
BI> do not change customer_user.login and *.customer_id Query, not sync. just make sure the information is valid in the backend.
BI>generating the password in Windows will probably be a bitch No. CustomerUser is not authentication. It's data. Read this: http://forums.otterhub.org/viewtopic.php?f=60&t=16543
On Mon, Oct 15, 2012 at 10:31 AM, Bogdan Iosif
wrote: I have not encountered this to be true. If the field is filled, it will
show.
You're right, thanks for the tip! I just never thought anything would show up beside first / last name / email.
Though, the GUI doesn't show anything beside CustomerID about the customer's company, right?
-=-
Putting your answer about db customer back-end together with http://doc.otrs.org/3.1/en/html/customer-user-backend.html seems to open the possibility of switching the default OTRS db customer back-end in read-only mode. For my needs, this would be ok when coupled with a way to replicate tables customer_user, customer_company from our other systems.
Possible gotchas:
- do not change customer_user.login and *.customer_id - generating the password in Windows will probably be a bitch - I just found this possibly obsolete mention "The password is crypted like 'man 3 crypt' with crypt()" in this OTRS 1.3 manual version http://doc.otrs.org/1.3/en/html/problems-misc.html
Do you see any other gotchas with this simple idea?
/bogdan
On Mon, Oct 15, 2012 at 4:50 PM, Gerald Young
wrote: BI> The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module
I have not encountered this to be true. If the field is filled, it will show. If you've otherwise modified the information screen, or you're gathering from a source that doesn't have a good CustomerUser Map in Config.pm (Fields not mapped won't show).
BI> if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm). I don't confirm this. This is a static configuration in Config.pm
BI> Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? Possible to create a table through Configs? No Possible to use an external db source as a CustomerUser backend? Yes. See the docs. http://doc.otrs.org/3.1/en/html/customer-user-backend.html
On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif
wrote: The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module (accesible from the admin interface). For example, we'll most likely have to make some inventive use of the Comment field for Customers / Companies and so agents would need to be able to inspect those fields at any time. AFAIK this is only possible in OTRS's GUI through the Customers / Companies modules (please correct me if I'm wrong).
The option of using an alternative customers identity backend is an interesting one, especially if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm).
I'm shooting from the hip with this followup question but: Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? I could create that with relative ease and it would contain data replicated from one of our other systems.
Thanks again for the help, /bogdan
On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young
wrote: > The details for an individual customer can be found from the > Customer link on creation of a new ticket (Options above body). As for > customer company, not really ability to "look up" except in the context > that, with CustomerCompanySupport enabled, the company information will > indeed be linked to the customer, and show in the Customer Info section of > a given ticket. > > Also, if the information is an LDAP source or otherwise marked as > ReadOnly in Config.pm because the data entry is handled by the external > data source frontend (ADUC, SalesForce, etc.), modifications to the > customer and customer company information via the web interface won't be > possible. > > On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif < > bogdan.iosif@gmail.com> wrote: > >> Hi, >> >> I think I found the answer to my question in an older mailing list >> entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html >> >> Hi Cyrille, >>> >>> That’s a common misunderstanding in OTRS! >>> >>> Group_ro only means that you only need “ro” permissions to access the module. >>> >>> What you can do within the module is not limited or controled by this setting. >>> >>> The module AdminUser doesn’t have a deeper permission concept. >>> >>> If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here. >>> >>> ... >>> >>> Cheers, Nils >>> >>> >> So unless anyone thinks the above answer is obsolete, I'll just >> assume that read-only access is not achievable at this time through >> configuration. >> >> /bogdan >> >> >> On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif < >> bogdan.iosif@gmail.com> wrote: >> >>> Hi, >>> >>> I managed to give full access to Customers / Companies modules for >>> regular agents by including them in a newly created group - AgentCcGroup - >>> and then adding this group in the following "Group ro" sections from >>> SysConfig -> Framework -> Frontend::Admin::ModuleRegistration >>> >>> - Frontend::Module###Admin >>> - Frontend::Module###AdminCustomerUser >>> - Frontend::Module###AdminCustomerCompany >>> >>> Trouble is, the resulting access type is full - i.e. the agents >>> can do any modifications to customer / companies details - and I need the >>> access type to be "read-only". Also, I'm confused by what "Group ro" means >>> as I expected it to mean "read-only" but practice showed me otherwise. >>> >>> I was guided by this >>> http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution to >>> the same problem but it doesn't touch too much on the read-only part of my >>> requirement, it just ~implies it should work. >>> >>> Does anyone know if there is such a thing as "read-only" access to >>> a module in the sense that the user can explore it's GUI but not make >>> changes? (or even better, someone maybe solved this exact problem?) >>> >>> Thanks, >>> Bogdan >>> >> >> >> >> --------------------------------------------------------------------- >> 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 >> > > > --------------------------------------------------------------------- > 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 >
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

Do you have documentation on this? Because I can't verify your statement.
Especially since it would appear that a device cal would mitigate this
issue.
On Mon, Oct 15, 2012 at 3:54 PM, Bogdan Iosif
This is an interesting issue. You're not using file/print, you're just
storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
:) It's shockingly expensive to run Microsoft infrastructures legally but the fact is that any user accesing Windows Server for any service is required to have a Windows Server CAL. This is true regardless of the exact path a user takes to consume the service exposed by Windows Server. In our case, OTRS would act as something that is called multiplexing software, for licensing purposes. That is to say that OTRS intermediates access to the Active Directory Windows Server service for authentication. So you would need one Windows Server CAL for each OTRS user that is registered in Active Directory (agent/customer it doesn't matter). The prices for CALs - and all other licenses - vary wildly based on how many you buy and the way you buy them (retail or volume licensing / subscriptions). There are a couple of specific situations where you don't require a CAL for over-the-Internet-users of web applications hosted on Windows Server. However, AFAIK there are a couple of hooks in those conditions that would catch you so that you require a CAL if the user is not anonymous.
Bottom line is: Microsoft licensing is very very complicated (ensuring you are most likely not perfectly legal ok at all times) and very very expensive.
On Mon, Oct 15, 2012 at 8:07 PM, Gerald Young
wrote: BI> Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel. :) yep. Sounds good to me. :)
BI> because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. This is an interesting issue. You're not using file/print, you're just storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
http://www.microsoft.com/licensing/about-licensing/client-access-license.asp...
On Mon, Oct 15, 2012 at 12:11 PM, Bogdan Iosif
wrote: If CustomerCompanySupport is enabled in Config.pm, fields that are
filled will show. [this message will repeat].
Right again
Note that any CustomerUser backend is a query, not a sync. (No
replication. Just Map). [...] You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS. [...]
I think I get what you say and it's also what I've meant. I meant replication as performed by a process / tool independent of OTRS with the purpose of keeping data in customer_user, customer_company tables up to date as dictated by our CRM system. I wasn't assuming any replication capability being built-in OTRS, it would just query the customer data made available to it. Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel.
I want to avoid switching to a LDAP based customer back-end for as long as possible because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. The alternative would be something like OpenLDAP and I expect that to be a bumpy road because non-AD LDAP servers on Windows is not a common occurrence.
Thank You, /bogdan
On Mon, Oct 15, 2012 at 6:07 PM, Gerald Young
wrote: BI>the GUI doesn't show anything beside CustomerID about the customer's company, right? If CustomerCompanySupport is enabled in Config.pm, fields that are filled will show. [this message will repeat].
BI> possibility of switching the default OTRS db customer back-end in read-only mode That's already possible. Copy the default CustomerUser keys from Defaults.pm to Config.pm and set the ReadOnly flag. (Although it's always this. Not changeable) You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS.
BI>when coupled with a way to replicate tables customer_user, customer_company from our other systems. Note that any CustomerUser backend is a query, not a sync. (No replication. Just Map).
Please look at Defaults.pm CustomerUser and read the comments in the information. You can choose to have the whole backend as readonly or only certain fields as readonly.
The CustomerUser Map determines what fields are shown. The comments tell you what fields are necessary. # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es) var: The variable that is being referenced through the web interface frontend: The label as presented. storage: The field from the data source shown: 1 for always, 2 for lite, 0 for don't show required: 0=no, 1=yes. Don't use 1/Not relevant in read only. storage-type: the examples give var (string) or int. http-link: a URL that wraps this field readonly: 0=no, 1=yes. whether the field can be changed in the web interface http-link-target: for instance, "_blank" (see HTML documentation for targets) link class(es): apparently, optional CSS class to apply to this link. Sometimes this can be used for psuedo classes and Javascript ..
BI> do not change customer_user.login and *.customer_id Query, not sync. just make sure the information is valid in the backend.
BI>generating the password in Windows will probably be a bitch No. CustomerUser is not authentication. It's data. Read this: http://forums.otterhub.org/viewtopic.php?f=60&t=16543
On Mon, Oct 15, 2012 at 10:31 AM, Bogdan Iosif
wrote: I have not encountered this to be true. If the field is filled, it
will show.
You're right, thanks for the tip! I just never thought anything would show up beside first / last name / email.
Though, the GUI doesn't show anything beside CustomerID about the customer's company, right?
-=-
Putting your answer about db customer back-end together with http://doc.otrs.org/3.1/en/html/customer-user-backend.html seems to open the possibility of switching the default OTRS db customer back-end in read-only mode. For my needs, this would be ok when coupled with a way to replicate tables customer_user, customer_company from our other systems.
Possible gotchas:
- do not change customer_user.login and *.customer_id - generating the password in Windows will probably be a bitch - I just found this possibly obsolete mention "The password is crypted like 'man 3 crypt' with crypt()" in this OTRS 1.3 manual version http://doc.otrs.org/1.3/en/html/problems-misc.html
Do you see any other gotchas with this simple idea?
/bogdan
On Mon, Oct 15, 2012 at 4:50 PM, Gerald Young
wrote: BI> The information available in the "Customer Information" panel - as seen in ticket zoom view - is incomplete compared with the amount of info that is captured in the Customers / Companies module
I have not encountered this to be true. If the field is filled, it will show. If you've otherwise modified the information screen, or you're gathering from a source that doesn't have a good CustomerUser Map in Config.pm (Fields not mapped won't show).
BI> if it would cause OTRS to automatically switch the customers / companies modules in true read-only mode (please reconfirm). I don't confirm this. This is a static configuration in Config.pm
BI> Is it possible to create, through configs, a simple DB customer backend that consists of a table stored in a MySQL db? Possible to create a table through Configs? No Possible to use an external db source as a CustomerUser backend? Yes. See the docs. http://doc.otrs.org/3.1/en/html/customer-user-backend.html
On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif
wrote: > The information available in the "Customer Information" panel - as > seen in ticket zoom view - is incomplete compared with the amount of info > that is captured in the Customers / Companies module (accesible from the > admin interface). For example, we'll most likely have to make some > inventive use of the Comment field for Customers / Companies and so agents > would need to be able to inspect those fields at any time. AFAIK this is > only possible in OTRS's GUI through the Customers / Companies modules > (please correct me if I'm wrong). > > The option of using an alternative customers identity backend is an > interesting one, especially if it would cause OTRS to automatically switch > the customers / companies modules in true read-only mode (please reconfirm). > > I'm shooting from the hip with this followup question but: Is it > possible to create, through configs, a simple DB customer backend that > consists of a table stored in a MySQL db? I could create that with relative > ease and it would contain data replicated from one of our other systems. > > Thanks again for the help, > /bogdan > > > > On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young
wrote: > >> The details for an individual customer can be found from the >> Customer link on creation of a new ticket (Options above body). As for >> customer company, not really ability to "look up" except in the context >> that, with CustomerCompanySupport enabled, the company information will >> indeed be linked to the customer, and show in the Customer Info section of >> a given ticket. >> >> Also, if the information is an LDAP source or otherwise marked as >> ReadOnly in Config.pm because the data entry is handled by the external >> data source frontend (ADUC, SalesForce, etc.), modifications to the >> customer and customer company information via the web interface won't be >> possible. >> >> On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif < >> bogdan.iosif@gmail.com> wrote: >> >>> Hi, >>> >>> I think I found the answer to my question in an older mailing list >>> entry: http://lists.otrs.org/pipermail/otrs/2012-March/037662.html >>> >>> Hi Cyrille, >>>> >>>> That’s a common misunderstanding in OTRS! >>>> >>>> Group_ro only means that you only need “ro” permissions to access the module. >>>> >>>> What you can do within the module is not limited or controled by this setting. >>>> >>>> The module AdminUser doesn’t have a deeper permission concept. >>>> >>>> If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here. >>>> >>>> ... >>>> >>>> Cheers, Nils >>>> >>>> >>> So unless anyone thinks the above answer is obsolete, I'll just >>> assume that read-only access is not achievable at this time through >>> configuration. >>> >>> /bogdan >>> >>> >>> On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif < >>> bogdan.iosif@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I managed to give full access to Customers / Companies modules >>>> for regular agents by including them in a newly created group - >>>> AgentCcGroup - and then adding this group in the following "Group ro" >>>> sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration >>>> >>>> - Frontend::Module###Admin >>>> - Frontend::Module###AdminCustomerUser >>>> - Frontend::Module###AdminCustomerCompany >>>> >>>> Trouble is, the resulting access type is full - i.e. the agents >>>> can do any modifications to customer / companies details - and I need the >>>> access type to be "read-only". Also, I'm confused by what "Group ro" means >>>> as I expected it to mean "read-only" but practice showed me otherwise. >>>> >>>> I was guided by this >>>> http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution to >>>> the same problem but it doesn't touch too much on the read-only part of my >>>> requirement, it just ~implies it should work. >>>> >>>> Does anyone know if there is such a thing as "read-only" access >>>> to a module in the sense that the user can explore it's GUI but not make >>>> changes? (or even better, someone maybe solved this exact problem?) >>>> >>>> Thanks, >>>> Bogdan >>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >>> >> >> >> >> --------------------------------------------------------------------- >> 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 >> > > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

There is no Active Directory specific documentation. Only general Windows
Server services licensing docs:
http://www.microsoft.com/en-us/server-cloud/windows-server/buy.aspx which
doesn't explain very well all the details in one place. The licensing
documents from Microsoft are hundreds of pages long and I'm no expert in
Microsoft licensing to point you exactly to where OTRS's scenario is
documented but I'll do my best to give you the basis for my opinion.
1. Here
http://www.microsoft.com/en-us/server-cloud/windows-server/buy.aspx you
can see that Windows Standard is licensed only as Processor + CAL. There is
no simple per processor license that would grant you unlimited users
connecting to that server's services. You need additional CALs for those
using the server.
2. This
http://www.microsoft.com/licensing/about-licensing/product-licensing-faq.asp...
entry explains that when a user / device is individually identified by
Windows Server it requires a CAL. Even when Active Directory is not used.
- If a user or device accesses a server running Windows Server but is
authenticating via a third-party authentication application
(non-Microsoft-based authentication), does the user or device
still require
a Windows Server CAL?
-
Yes, if the user or device is authenticated or otherwise individually
identified by a server running Windows Server through any other means, it
requires a Windows Server CAL. The specific Windows Server CAL
requirement
is defined in the Microsoft Product Use Rights as follows: "You
do not need
CALs for any user or device that accesses your instances of the server
software only through the Internet without being authenticated
or otherwise
individually identified by the server software or through any
other means."
3. Here
http://www.microsoftvolumelicensing.com/DocumentSearch.aspx?Mode=3&DocumentT...
can find a huge doc on licensing. It defines multiplexing, very
vaguely
as:
- Hardware or software you use to pool connections, reroute
information, reduce the number of devices or users that directly
access or
use the product, or reduce the number of operating system
environments (or
OSEs), devices or users the product directly manages, (sometimes referred
to as “multiplexing” or “pooling”), does not reduce the number
of licenses
of any type that you need.
4. Here
http://download.microsoft.com/download/8/7/3/8733d036-92b0-4cb8-8912-3b6ab96...
a document that treats a little bit better multiplexing. It's actually
pretty tied to SQL Server but right under Figure 1 you can see "This
includes users who view data through web-based applications or enter
information into a database through an intermediary product." and that
is exactly the scenario where OTRS fits in relation to Windows Server.
5. The same document from above also mentions
- What is the difference between a device licensed with a device CAL
and a multiplexing device?
- A device CAL allows one device, used by any user, to access
instances of the server software on the licensed server. A multiplexing
device pools connections from other devices, which users can
license with a
device CAL.
All CAL licensing is actually focused on the user, even device CALs.
Devices are actually very easy to imagine as "workstations" that are
alternatively used by one user at a time. Web based applications are
multiplexors allowing many users to access a backend service (be it offered
by SQL Server or Windows Server) simultaneously.
This is also interesting:
http://serverfault.com/questions/13956/active-directory-licensing for
popular opinion
/bogdan
On Mon, Oct 15, 2012 at 11:06 PM, Gerald Young
Do you have documentation on this? Because I can't verify your statement. Especially since it would appear that a device cal would mitigate this issue.
On Mon, Oct 15, 2012 at 3:54 PM, Bogdan Iosif
wrote: This is an interesting issue. You're not using file/print, you're just
storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
:) It's shockingly expensive to run Microsoft infrastructures legally but the fact is that any user accesing Windows Server for any service is required to have a Windows Server CAL. This is true regardless of the exact path a user takes to consume the service exposed by Windows Server. In our case, OTRS would act as something that is called multiplexing software, for licensing purposes. That is to say that OTRS intermediates access to the Active Directory Windows Server service for authentication. So you would need one Windows Server CAL for each OTRS user that is registered in Active Directory (agent/customer it doesn't matter). The prices for CALs - and all other licenses - vary wildly based on how many you buy and the way you buy them (retail or volume licensing / subscriptions). There are a couple of specific situations where you don't require a CAL for over-the-Internet-users of web applications hosted on Windows Server. However, AFAIK there are a couple of hooks in those conditions that would catch you so that you require a CAL if the user is not anonymous.
Bottom line is: Microsoft licensing is very very complicated (ensuring you are most likely not perfectly legal ok at all times) and very very expensive.
On Mon, Oct 15, 2012 at 8:07 PM, Gerald Young
wrote: BI> Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel. :) yep. Sounds good to me. :)
BI> because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. This is an interesting issue. You're not using file/print, you're just storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
http://www.microsoft.com/licensing/about-licensing/client-access-license.asp...
On Mon, Oct 15, 2012 at 12:11 PM, Bogdan Iosif
wrote: If CustomerCompanySupport is enabled in Config.pm, fields that are
filled will show. [this message will repeat].
Right again
Note that any CustomerUser backend is a query, not a sync. (No
replication. Just Map). [...] You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS. [...]
I think I get what you say and it's also what I've meant. I meant replication as performed by a process / tool independent of OTRS with the purpose of keeping data in customer_user, customer_company tables up to date as dictated by our CRM system. I wasn't assuming any replication capability being built-in OTRS, it would just query the customer data made available to it. Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel.
I want to avoid switching to a LDAP based customer back-end for as long as possible because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. The alternative would be something like OpenLDAP and I expect that to be a bumpy road because non-AD LDAP servers on Windows is not a common occurrence.
Thank You, /bogdan
On Mon, Oct 15, 2012 at 6:07 PM, Gerald Young
wrote: BI>the GUI doesn't show anything beside CustomerID about the customer's company, right? If CustomerCompanySupport is enabled in Config.pm, fields that are filled will show. [this message will repeat].
BI> possibility of switching the default OTRS db customer back-end in read-only mode That's already possible. Copy the default CustomerUser keys from Defaults.pm to Config.pm and set the ReadOnly flag. (Although it's always this. Not changeable) You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS.
BI>when coupled with a way to replicate tables customer_user, customer_company from our other systems. Note that any CustomerUser backend is a query, not a sync. (No replication. Just Map).
Please look at Defaults.pm CustomerUser and read the comments in the information. You can choose to have the whole backend as readonly or only certain fields as readonly.
The CustomerUser Map determines what fields are shown. The comments tell you what fields are necessary. # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es) var: The variable that is being referenced through the web interface frontend: The label as presented. storage: The field from the data source shown: 1 for always, 2 for lite, 0 for don't show required: 0=no, 1=yes. Don't use 1/Not relevant in read only. storage-type: the examples give var (string) or int. http-link: a URL that wraps this field readonly: 0=no, 1=yes. whether the field can be changed in the web interface http-link-target: for instance, "_blank" (see HTML documentation for targets) link class(es): apparently, optional CSS class to apply to this link. Sometimes this can be used for psuedo classes and Javascript ..
BI> do not change customer_user.login and *.customer_id Query, not sync. just make sure the information is valid in the backend.
BI>generating the password in Windows will probably be a bitch No. CustomerUser is not authentication. It's data. Read this: http://forums.otterhub.org/viewtopic.php?f=60&t=16543
On Mon, Oct 15, 2012 at 10:31 AM, Bogdan Iosif
wrote:
I have not encountered this to be true. If the field is filled, it > will show. >
You're right, thanks for the tip! I just never thought anything would show up beside first / last name / email.
Though, the GUI doesn't show anything beside CustomerID about the customer's company, right?
-=-
Putting your answer about db customer back-end together with http://doc.otrs.org/3.1/en/html/customer-user-backend.html seems to open the possibility of switching the default OTRS db customer back-end in read-only mode. For my needs, this would be ok when coupled with a way to replicate tables customer_user, customer_company from our other systems.
Possible gotchas:
- do not change customer_user.login and *.customer_id - generating the password in Windows will probably be a bitch - I just found this possibly obsolete mention "The password is crypted like 'man 3 crypt' with crypt()" in this OTRS 1.3 manual version http://doc.otrs.org/1.3/en/html/problems-misc.html
Do you see any other gotchas with this simple idea?
/bogdan
On Mon, Oct 15, 2012 at 4:50 PM, Gerald Young
wrote: > BI> The information available in the "Customer Information" panel - > as seen in ticket zoom view - is incomplete compared with the amount of > info that is captured in the Customers / Companies module > > I have not encountered this to be true. If the field is filled, it > will show. If you've otherwise modified the information screen, or you're > gathering from a source that doesn't have a good CustomerUser Map in > Config.pm (Fields not mapped won't show). > > > BI> if it would cause OTRS to automatically switch the customers / > companies modules in true read-only mode (please reconfirm). > I don't confirm this. This is a static configuration in Config.pm > > BI> Is it possible to create, through configs, a simple DB customer > backend that consists of a table stored in a MySQL db? > Possible to create a table through Configs? No > Possible to use an external db source as a CustomerUser backend? > Yes. See the docs. > http://doc.otrs.org/3.1/en/html/customer-user-backend.html > > > > On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif < > bogdan.iosif@gmail.com> wrote: > >> The information available in the "Customer Information" panel - as >> seen in ticket zoom view - is incomplete compared with the amount of info >> that is captured in the Customers / Companies module (accesible from the >> admin interface). For example, we'll most likely have to make some >> inventive use of the Comment field for Customers / Companies and so agents >> would need to be able to inspect those fields at any time. AFAIK this is >> only possible in OTRS's GUI through the Customers / Companies modules >> (please correct me if I'm wrong). >> >> The option of using an alternative customers identity backend is an >> interesting one, especially if it would cause OTRS to automatically switch >> the customers / companies modules in true read-only mode (please reconfirm). >> >> I'm shooting from the hip with this followup question but: Is it >> possible to create, through configs, a simple DB customer backend that >> consists of a table stored in a MySQL db? I could create that with relative >> ease and it would contain data replicated from one of our other systems. >> >> Thanks again for the help, >> /bogdan >> >> >> >> On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young
wrote: >> >>> The details for an individual customer can be found from the >>> Customer link on creation of a new ticket (Options above body). As for >>> customer company, not really ability to "look up" except in the context >>> that, with CustomerCompanySupport enabled, the company information will >>> indeed be linked to the customer, and show in the Customer Info section of >>> a given ticket. >>> >>> Also, if the information is an LDAP source or otherwise marked as >>> ReadOnly in Config.pm because the data entry is handled by the external >>> data source frontend (ADUC, SalesForce, etc.), modifications to the >>> customer and customer company information via the web interface won't be >>> possible. >>> >>> On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif < >>> bogdan.iosif@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I think I found the answer to my question in an older mailing >>>> list entry: >>>> http://lists.otrs.org/pipermail/otrs/2012-March/037662.html >>>> >>>> Hi Cyrille, >>>>> >>>>> That’s a common misunderstanding in OTRS! >>>>> >>>>> Group_ro only means that you only need “ro” permissions to access the module. >>>>> >>>>> What you can do within the module is not limited or controled by this setting. >>>>> >>>>> The module AdminUser doesn’t have a deeper permission concept. >>>>> >>>>> If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here. >>>>> >>>>> ... >>>>> >>>>> Cheers, Nils >>>>> >>>>> >>>> So unless anyone thinks the above answer is obsolete, I'll just >>>> assume that read-only access is not achievable at this time through >>>> configuration. >>>> >>>> /bogdan >>>> >>>> >>>> On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif < >>>> bogdan.iosif@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I managed to give full access to Customers / Companies modules >>>>> for regular agents by including them in a newly created group - >>>>> AgentCcGroup - and then adding this group in the following "Group ro" >>>>> sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration >>>>> >>>>> - Frontend::Module###Admin >>>>> - Frontend::Module###AdminCustomerUser >>>>> - Frontend::Module###AdminCustomerCompany >>>>> >>>>> Trouble is, the resulting access type is full - i.e. the agents >>>>> can do any modifications to customer / companies details - and I need the >>>>> access type to be "read-only". Also, I'm confused by what "Group ro" means >>>>> as I expected it to mean "read-only" but practice showed me otherwise. >>>>> >>>>> I was guided by this >>>>> http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution >>>>> to the same problem but it doesn't touch too much on the read-only part of >>>>> my requirement, it just ~implies it should work. >>>>> >>>>> Does anyone know if there is such a thing as "read-only" access >>>>> to a module in the sense that the user can explore it's GUI but not make >>>>> changes? (or even better, someone maybe solved this exact problem?) >>>>> >>>>> Thanks, >>>>> Bogdan >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >>> >> >> >> >> --------------------------------------------------------------------- >> 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 >> > > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

Well, that's a whole lot of not fun.
*Are multiplexing rules different for Windows Server CALs? Does
authentication make a difference?*
No. Like the SQL Server examples previously detailed, CALs are required for
access to Windows Server whether direct or indirect. Users who are
authenticated or individually identified, whether by the Windows Server
software or by multiplexing hardware or software, require a Windows Server
CAL to access Windows Server.
I'm thinking that the Windows Server external connector license then could
address that.
On Mon, Oct 15, 2012 at 5:11 PM, Bogdan Iosif
There is no Active Directory specific documentation. Only general Windows Server services licensing docs: http://www.microsoft.com/en-us/server-cloud/windows-server/buy.aspx which doesn't explain very well all the details in one place. The licensing documents from Microsoft are hundreds of pages long and I'm no expert in Microsoft licensing to point you exactly to where OTRS's scenario is documented but I'll do my best to give you the basis for my opinion.
1. Here http://www.microsoft.com/en-us/server-cloud/windows-server/buy.aspxyou can see that Windows Standard is licensed only as Processor + CAL. There is no simple per processor license that would grant you unlimited users connecting to that server's services. You need additional CALs for those using the server. 2. This http://www.microsoft.com/licensing/about-licensing/product-licensing-faq.asp... entry explains that when a user / device is individually identified by Windows Server it requires a CAL. Even when Active Directory is not used. - If a user or device accesses a server running Windows Server but is authenticating via a third-party authentication application (non-Microsoft-based authentication), does the user or device still require a Windows Server CAL? -
Yes, if the user or device is authenticated or otherwise individually identified by a server running Windows Server through any other means, it requires a Windows Server CAL. The specific Windows Server CAL requirement is defined in the Microsoft Product Use Rights as follows: "You do not need CALs for any user or device that accesses your instances of the server software only through the Internet without being authenticated or otherwise individually identified by the server software or through any other means." 3. Here http://www.microsoftvolumelicensing.com/DocumentSearch.aspx?Mode=3&DocumentT... can find a huge doc on licensing. It defines multiplexing, very vaguely as: - Hardware or software you use to pool connections, reroute information, reduce the number of devices or users that directly access or use the product, or reduce the number of operating system environments (or OSEs), devices or users the product directly manages, (sometimes referred to as “multiplexing” or “pooling”), does not reduce the number of licenses of any type that you need. 4. Here http://download.microsoft.com/download/8/7/3/8733d036-92b0-4cb8-8912-3b6ab96... a document that treats a little bit better multiplexing. It's actually pretty tied to SQL Server but right under Figure 1 you can see "This includes users who view data through web-based applications or enter information into a database through an intermediary product." and that is exactly the scenario where OTRS fits in relation to Windows Server. 5. The same document from above also mentions - What is the difference between a device licensed with a device CAL and a multiplexing device? - A device CAL allows one device, used by any user, to access instances of the server software on the licensed server. A multiplexing device pools connections from other devices, which users can license with a device CAL.
All CAL licensing is actually focused on the user, even device CALs. Devices are actually very easy to imagine as "workstations" that are alternatively used by one user at a time. Web based applications are multiplexors allowing many users to access a backend service (be it offered by SQL Server or Windows Server) simultaneously.
This is also interesting: http://serverfault.com/questions/13956/active-directory-licensing for popular opinion
/bogdan
On Mon, Oct 15, 2012 at 11:06 PM, Gerald Young
wrote: Do you have documentation on this? Because I can't verify your statement. Especially since it would appear that a device cal would mitigate this issue.
On Mon, Oct 15, 2012 at 3:54 PM, Bogdan Iosif
wrote: This is an interesting issue. You're not using file/print, you're just
storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
:) It's shockingly expensive to run Microsoft infrastructures legally but the fact is that any user accesing Windows Server for any service is required to have a Windows Server CAL. This is true regardless of the exact path a user takes to consume the service exposed by Windows Server. In our case, OTRS would act as something that is called multiplexing software, for licensing purposes. That is to say that OTRS intermediates access to the Active Directory Windows Server service for authentication. So you would need one Windows Server CAL for each OTRS user that is registered in Active Directory (agent/customer it doesn't matter). The prices for CALs - and all other licenses - vary wildly based on how many you buy and the way you buy them (retail or volume licensing / subscriptions). There are a couple of specific situations where you don't require a CAL for over-the-Internet-users of web applications hosted on Windows Server. However, AFAIK there are a couple of hooks in those conditions that would catch you so that you require a CAL if the user is not anonymous.
Bottom line is: Microsoft licensing is very very complicated (ensuring you are most likely not perfectly legal ok at all times) and very very expensive.
On Mon, Oct 15, 2012 at 8:07 PM, Gerald Young
wrote: BI> Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel. :) yep. Sounds good to me. :)
BI> because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. This is an interesting issue. You're not using file/print, you're just storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
http://www.microsoft.com/licensing/about-licensing/client-access-license.asp...
On Mon, Oct 15, 2012 at 12:11 PM, Bogdan Iosif
wrote: If CustomerCompanySupport is enabled in Config.pm, fields that are
filled will show. [this message will repeat].
Right again
Note that any CustomerUser backend is a query, not a sync. (No
replication. Just Map). [...] You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS. [...]
I think I get what you say and it's also what I've meant. I meant replication as performed by a process / tool independent of OTRS with the purpose of keeping data in customer_user, customer_company tables up to date as dictated by our CRM system. I wasn't assuming any replication capability being built-in OTRS, it would just query the customer data made available to it. Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel.
I want to avoid switching to a LDAP based customer back-end for as long as possible because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. The alternative would be something like OpenLDAP and I expect that to be a bumpy road because non-AD LDAP servers on Windows is not a common occurrence.
Thank You, /bogdan
On Mon, Oct 15, 2012 at 6:07 PM, Gerald Young
wrote: BI>the GUI doesn't show anything beside CustomerID about the customer's company, right? If CustomerCompanySupport is enabled in Config.pm, fields that are filled will show. [this message will repeat].
BI> possibility of switching the default OTRS db customer back-end in read-only mode That's already possible. Copy the default CustomerUser keys from Defaults.pm to Config.pm and set the ReadOnly flag. (Although it's always this. Not changeable) You can, of course, use a different interface (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to something that already can manage this away from OTRS.
BI>when coupled with a way to replicate tables customer_user, customer_company from our other systems. Note that any CustomerUser backend is a query, not a sync. (No replication. Just Map).
Please look at Defaults.pm CustomerUser and read the comments in the information. You can choose to have the whole backend as readonly or only certain fields as readonly.
The CustomerUser Map determines what fields are shown. The comments tell you what fields are necessary. # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target, link class(es) var: The variable that is being referenced through the web interface frontend: The label as presented. storage: The field from the data source shown: 1 for always, 2 for lite, 0 for don't show required: 0=no, 1=yes. Don't use 1/Not relevant in read only. storage-type: the examples give var (string) or int. http-link: a URL that wraps this field readonly: 0=no, 1=yes. whether the field can be changed in the web interface http-link-target: for instance, "_blank" (see HTML documentation for targets) link class(es): apparently, optional CSS class to apply to this link. Sometimes this can be used for psuedo classes and Javascript ..
BI> do not change customer_user.login and *.customer_id Query, not sync. just make sure the information is valid in the backend.
BI>generating the password in Windows will probably be a bitch No. CustomerUser is not authentication. It's data. Read this: http://forums.otterhub.org/viewtopic.php?f=60&t=16543
On Mon, Oct 15, 2012 at 10:31 AM, Bogdan Iosif < bogdan.iosif@gmail.com> wrote:
> I have not encountered this to be true. If the field is filled, it >> will show. >> > > You're right, thanks for the tip! I just never thought anything > would show up beside first / last name / email. > > Though, the GUI doesn't show anything beside CustomerID about the > customer's company, right? > > -=- > > Putting your answer about db customer back-end together with > http://doc.otrs.org/3.1/en/html/customer-user-backend.html seems to > open the possibility of switching the default OTRS db customer back-end in > read-only mode. For my needs, this would be ok when coupled with a way to > replicate tables customer_user, customer_company from our other systems. > > Possible gotchas: > > - do not change customer_user.login and *.customer_id > - generating the password in Windows will probably be a bitch - > I just found this possibly obsolete mention "The password is crypted like > 'man 3 crypt' with crypt()" in this OTRS 1.3 manual version > http://doc.otrs.org/1.3/en/html/problems-misc.html > > Do you see any other gotchas with this simple idea? > > /bogdan > > On Mon, Oct 15, 2012 at 4:50 PM, Gerald Young
wrote: > >> BI> The information available in the "Customer Information" panel - >> as seen in ticket zoom view - is incomplete compared with the amount of >> info that is captured in the Customers / Companies module >> >> I have not encountered this to be true. If the field is filled, it >> will show. If you've otherwise modified the information screen, or you're >> gathering from a source that doesn't have a good CustomerUser Map in >> Config.pm (Fields not mapped won't show). >> >> >> BI> if it would cause OTRS to automatically switch the customers / >> companies modules in true read-only mode (please reconfirm). >> I don't confirm this. This is a static configuration in Config.pm >> >> BI> Is it possible to create, through configs, a simple DB >> customer backend that consists of a table stored in a MySQL db? >> Possible to create a table through Configs? No >> Possible to use an external db source as a CustomerUser backend? >> Yes. See the docs. >> http://doc.otrs.org/3.1/en/html/customer-user-backend.html >> >> >> >> On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif < >> bogdan.iosif@gmail.com> wrote: >> >>> The information available in the "Customer Information" panel - as >>> seen in ticket zoom view - is incomplete compared with the amount of info >>> that is captured in the Customers / Companies module (accesible from the >>> admin interface). For example, we'll most likely have to make some >>> inventive use of the Comment field for Customers / Companies and so agents >>> would need to be able to inspect those fields at any time. AFAIK this is >>> only possible in OTRS's GUI through the Customers / Companies modules >>> (please correct me if I'm wrong). >>> >>> The option of using an alternative customers identity backend is >>> an interesting one, especially if it would cause OTRS to automatically >>> switch the customers / companies modules in true read-only mode (please >>> reconfirm). >>> >>> I'm shooting from the hip with this followup question but: Is it >>> possible to create, through configs, a simple DB customer backend that >>> consists of a table stored in a MySQL db? I could create that with relative >>> ease and it would contain data replicated from one of our other systems. >>> >>> Thanks again for the help, >>> /bogdan >>> >>> >>> >>> On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young wrote: >>> >>>> The details for an individual customer can be found from the >>>> Customer link on creation of a new ticket (Options above body). As for >>>> customer company, not really ability to "look up" except in the context >>>> that, with CustomerCompanySupport enabled, the company information will >>>> indeed be linked to the customer, and show in the Customer Info section of >>>> a given ticket. >>>> >>>> Also, if the information is an LDAP source or otherwise marked as >>>> ReadOnly in Config.pm because the data entry is handled by the external >>>> data source frontend (ADUC, SalesForce, etc.), modifications to the >>>> customer and customer company information via the web interface won't be >>>> possible. >>>> >>>> On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif < >>>> bogdan.iosif@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I think I found the answer to my question in an older mailing >>>>> list entry: >>>>> http://lists.otrs.org/pipermail/otrs/2012-March/037662.html >>>>> >>>>> Hi Cyrille, >>>>>> >>>>>> That’s a common misunderstanding in OTRS! >>>>>> >>>>>> Group_ro only means that you only need “ro” permissions to access the module. >>>>>> >>>>>> What you can do within the module is not limited or controled by this setting. >>>>>> >>>>>> The module AdminUser doesn’t have a deeper permission concept. >>>>>> >>>>>> If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here. >>>>>> >>>>>> ... >>>>>> >>>>>> Cheers, Nils >>>>>> >>>>>> >>>>> So unless anyone thinks the above answer is obsolete, I'll just >>>>> assume that read-only access is not achievable at this time through >>>>> configuration. >>>>> >>>>> /bogdan >>>>> >>>>> >>>>> On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif < >>>>> bogdan.iosif@gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I managed to give full access to Customers / Companies modules >>>>>> for regular agents by including them in a newly created group - >>>>>> AgentCcGroup - and then adding this group in the following "Group ro" >>>>>> sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration >>>>>> >>>>>> - Frontend::Module###Admin >>>>>> - Frontend::Module###AdminCustomerUser >>>>>> - Frontend::Module###AdminCustomerCompany >>>>>> >>>>>> Trouble is, the resulting access type is full - i.e. the agents >>>>>> can do any modifications to customer / companies details - and I need the >>>>>> access type to be "read-only". Also, I'm confused by what "Group ro" means >>>>>> as I expected it to mean "read-only" but practice showed me otherwise. >>>>>> >>>>>> I was guided by this >>>>>> http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution >>>>>> to the same problem but it doesn't touch too much on the read-only part of >>>>>> my requirement, it just ~implies it should work. >>>>>> >>>>>> Does anyone know if there is such a thing as "read-only" access >>>>>> to a module in the sense that the user can explore it's GUI but not make >>>>>> changes? (or even better, someone maybe solved this exact problem?) >>>>>> >>>>>> Thanks, >>>>>> Bogdan >>>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >>> >> >> >> >> --------------------------------------------------------------------- >> 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 >> > > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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

Yes, the External Connector is the license to get for the Windows Server
running AD. I've read a little more about it here
http://download.microsoft.com/download/E/8/E/E8EDAE36-CBC6-4123-BC5A-F651D17...
the bottom of page 14, Initiative 7: Company Website is an example
relatable to OTRS.
I find it "funny" that you can host OTRS on Linux and then when you need
your customers authenticated via Active Directory... bam, 1500$+ for each
AD server (there's more than one for companies with more than ~100
employees).
So the way to do it in a cost effective manner would be to authenticate
your agents against AD (presumably they are employees and you get Windows
Server user CALs for them, which cover usage for any Windows Server of the
same version or lower in the organization) and then authenticate your
customers against an independently setup, open source, LDAP server.
On Tue, Oct 16, 2012 at 12:30 AM, Gerald Young
Well, that's a whole lot of not fun.
*Are multiplexing rules different for Windows Server CALs? Does authentication make a difference?*
No. Like the SQL Server examples previously detailed, CALs are required for access to Windows Server whether direct or indirect. Users who are authenticated or individually identified, whether by the Windows Server software or by multiplexing hardware or software, require a Windows Server CAL to access Windows Server.
I'm thinking that the Windows Server external connector license then could address that.
On Mon, Oct 15, 2012 at 5:11 PM, Bogdan Iosif
wrote: There is no Active Directory specific documentation. Only general Windows Server services licensing docs: http://www.microsoft.com/en-us/server-cloud/windows-server/buy.aspxwhich doesn't explain very well all the details in one place. The licensing documents from Microsoft are hundreds of pages long and I'm no expert in Microsoft licensing to point you exactly to where OTRS's scenario is documented but I'll do my best to give you the basis for my opinion.
1. Here http://www.microsoft.com/en-us/server-cloud/windows-server/buy.aspxyou can see that Windows Standard is licensed only as Processor + CAL. There is no simple per processor license that would grant you unlimited users connecting to that server's services. You need additional CALs for those using the server. 2. This http://www.microsoft.com/licensing/about-licensing/product-licensing-faq.asp... entry explains that when a user / device is individually identified by Windows Server it requires a CAL. Even when Active Directory is not used. - If a user or device accesses a server running Windows Server but is authenticating via a third-party authentication application (non-Microsoft-based authentication), does the user or device still require a Windows Server CAL? -
Yes, if the user or device is authenticated or otherwise individually identified by a server running Windows Server through any other means, it requires a Windows Server CAL. The specific Windows Server CAL requirement is defined in the Microsoft Product Use Rights as follows: "You do not need CALs for any user or device that accesses your instances of the server software only through the Internet without being authenticated or otherwise individually identified by the server software or through any other means." 3. Here http://www.microsoftvolumelicensing.com/DocumentSearch.aspx?Mode=3&DocumentT... can find a huge doc on licensing. It defines multiplexing, very vaguely as: - Hardware or software you use to pool connections, reroute information, reduce the number of devices or users that directly access or use the product, or reduce the number of operating system environments (or OSEs), devices or users the product directly manages, (sometimes referred to as “multiplexing” or “pooling”), does not reduce the number of licenses of any type that you need. 4. Here http://download.microsoft.com/download/8/7/3/8733d036-92b0-4cb8-8912-3b6ab96... a document that treats a little bit better multiplexing. It's actually pretty tied to SQL Server but right under Figure 1 you can see "This includes users who view data through web-based applications or enter information into a database through an intermediary product." and that is exactly the scenario where OTRS fits in relation to Windows Server. 5. The same document from above also mentions - What is the difference between a device licensed with a device CAL and a multiplexing device? - A device CAL allows one device, used by any user, to access instances of the server software on the licensed server. A multiplexing device pools connections from other devices, which users can license with a device CAL.
All CAL licensing is actually focused on the user, even device CALs. Devices are actually very easy to imagine as "workstations" that are alternatively used by one user at a time. Web based applications are multiplexors allowing many users to access a backend service (be it offered by SQL Server or Windows Server) simultaneously.
This is also interesting: http://serverfault.com/questions/13956/active-directory-licensing for popular opinion
/bogdan
On Mon, Oct 15, 2012 at 11:06 PM, Gerald Young
wrote: Do you have documentation on this? Because I can't verify your statement. Especially since it would appear that a device cal would mitigate this issue.
On Mon, Oct 15, 2012 at 3:54 PM, Bogdan Iosif
wrote: This is an interesting issue. You're not using file/print, you're just
storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
:) It's shockingly expensive to run Microsoft infrastructures legally but the fact is that any user accesing Windows Server for any service is required to have a Windows Server CAL. This is true regardless of the exact path a user takes to consume the service exposed by Windows Server. In our case, OTRS would act as something that is called multiplexing software, for licensing purposes. That is to say that OTRS intermediates access to the Active Directory Windows Server service for authentication. So you would need one Windows Server CAL for each OTRS user that is registered in Active Directory (agent/customer it doesn't matter). The prices for CALs - and all other licenses - vary wildly based on how many you buy and the way you buy them (retail or volume licensing / subscriptions). There are a couple of specific situations where you don't require a CAL for over-the-Internet-users of web applications hosted on Windows Server. However, AFAIK there are a couple of hooks in those conditions that would catch you so that you require a CAL if the user is not anonymous.
Bottom line is: Microsoft licensing is very very complicated (ensuring you are most likely not perfectly legal ok at all times) and very very expensive.
On Mon, Oct 15, 2012 at 8:07 PM, Gerald Young
wrote: BI> Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel. :) yep. Sounds good to me. :)
BI> because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. This is an interesting issue. You're not using file/print, you're just storing data. It appears either 1 device (OTRS server) or 1 user (ldap lookup user) CAL will be the actual "user" of the services to look up the information, regardless of how many results are returned.
http://www.microsoft.com/licensing/about-licensing/client-access-license.asp...
On Mon, Oct 15, 2012 at 12:11 PM, Bogdan Iosif
wrote:
If CustomerCompanySupport is enabled in Config.pm, fields that are > filled will show. [this message will repeat]. >
Right again
Note that any CustomerUser backend is a query, not a sync. (No > replication. Just Map). [...] You can, of course, use a different interface > (php? phpmyadmin?) to modify the CustomerUser table but I'd rather sync to > something that already can manage this away from OTRS. [...] >
I think I get what you say and it's also what I've meant. I meant replication as performed by a process / tool independent of OTRS with the purpose of keeping data in customer_user, customer_company tables up to date as dictated by our CRM system. I wasn't assuming any replication capability being built-in OTRS, it would just query the customer data made available to it. Mainly, I was aiming to re-use OTRS's default db client back-end configuration by just switching it in read-only mode and updating client info through a side channel.
I want to avoid switching to a LDAP based customer back-end for as long as possible because we're using Active Directory and our licensing probably doesn't cover including a couple hundred customers in AD. The alternative would be something like OpenLDAP and I expect that to be a bumpy road because non-AD LDAP servers on Windows is not a common occurrence.
Thank You, /bogdan
On Mon, Oct 15, 2012 at 6:07 PM, Gerald Young
wrote: > BI>the GUI doesn't show anything beside CustomerID about the > customer's company, right? > If CustomerCompanySupport is enabled in Config.pm, fields that are > filled will show. [this message will repeat]. > > BI> possibility of switching the default OTRS db customer back-end > in read-only mode > That's already possible. Copy the default CustomerUser keys from > Defaults.pm to Config.pm and set the ReadOnly flag. (Although it's always > this. Not changeable) You can, of course, use a different interface (php? > phpmyadmin?) to modify the CustomerUser table but I'd rather sync to > something that already can manage this away from OTRS. > > BI>when coupled with a way to replicate tables customer_user, > customer_company from our other systems. > Note that any CustomerUser backend is a query, not a sync. (No > replication. Just Map). > > Please look at Defaults.pm CustomerUser and read the comments in the > information. You can choose to have the whole backend as readonly or only > certain fields as readonly. > > The CustomerUser Map determines what fields are shown. The comments > tell you what fields are necessary. > # note: Login, Email and CustomerID needed! > # var, frontend, storage, shown (1=always,2=lite), required, > storage-type, http-link, readonly, http-link-target, link class(es) > var: The variable that is being referenced through the web interface > frontend: The label as presented. > storage: The field from the data source > shown: 1 for always, 2 for lite, 0 for don't show > required: 0=no, 1=yes. Don't use 1/Not relevant in read only. > storage-type: the examples give var (string) or int. > http-link: a URL that wraps this field > readonly: 0=no, 1=yes. whether the field can be changed in the web > interface > http-link-target: for instance, "_blank" (see HTML documentation for > targets) > link class(es): apparently, optional CSS class to apply to this > link. Sometimes this can be used for psuedo classes and Javascript .. > > BI> do not change customer_user.login and *.customer_id > Query, not sync. just make sure the information is valid in the > backend. > > BI>generating the password in Windows will probably be a bitch > No. CustomerUser is not authentication. It's data. > Read this: http://forums.otterhub.org/viewtopic.php?f=60&t=16543 > > > On Mon, Oct 15, 2012 at 10:31 AM, Bogdan Iosif < > bogdan.iosif@gmail.com> wrote: > >> I have not encountered this to be true. If the field is filled, it >>> will show. >>> >> >> You're right, thanks for the tip! I just never thought anything >> would show up beside first / last name / email. >> >> Though, the GUI doesn't show anything beside CustomerID about the >> customer's company, right? >> >> -=- >> >> Putting your answer about db customer back-end together with >> http://doc.otrs.org/3.1/en/html/customer-user-backend.html seems >> to open the possibility of switching the default OTRS db customer back-end >> in read-only mode. For my needs, this would be ok when coupled with a way >> to replicate tables customer_user, customer_company from our other systems. >> >> Possible gotchas: >> >> - do not change customer_user.login and *.customer_id >> - generating the password in Windows will probably be a bitch - >> I just found this possibly obsolete mention "The password is crypted like >> 'man 3 crypt' with crypt()" in this OTRS 1.3 manual version >> http://doc.otrs.org/1.3/en/html/problems-misc.html >> >> Do you see any other gotchas with this simple idea? >> >> /bogdan >> >> On Mon, Oct 15, 2012 at 4:50 PM, Gerald Young
wrote: >> >>> BI> The information available in the "Customer Information" panel >>> - as seen in ticket zoom view - is incomplete compared with the amount of >>> info that is captured in the Customers / Companies module >>> >>> I have not encountered this to be true. If the field is filled, it >>> will show. If you've otherwise modified the information screen, or you're >>> gathering from a source that doesn't have a good CustomerUser Map in >>> Config.pm (Fields not mapped won't show). >>> >>> >>> BI> if it would cause OTRS to automatically switch the customers / >>> companies modules in true read-only mode (please reconfirm). >>> I don't confirm this. This is a static configuration in Config.pm >>> >>> BI> Is it possible to create, through configs, a simple DB >>> customer backend that consists of a table stored in a MySQL db? >>> Possible to create a table through Configs? No >>> Possible to use an external db source as a CustomerUser backend? >>> Yes. See the docs. >>> http://doc.otrs.org/3.1/en/html/customer-user-backend.html >>> >>> >>> >>> On Mon, Oct 15, 2012 at 9:15 AM, Bogdan Iosif < >>> bogdan.iosif@gmail.com> wrote: >>> >>>> The information available in the "Customer Information" panel - >>>> as seen in ticket zoom view - is incomplete compared with the amount of >>>> info that is captured in the Customers / Companies module (accesible from >>>> the admin interface). For example, we'll most likely have to make some >>>> inventive use of the Comment field for Customers / Companies and so agents >>>> would need to be able to inspect those fields at any time. AFAIK this is >>>> only possible in OTRS's GUI through the Customers / Companies modules >>>> (please correct me if I'm wrong). >>>> >>>> The option of using an alternative customers identity backend is >>>> an interesting one, especially if it would cause OTRS to automatically >>>> switch the customers / companies modules in true read-only mode (please >>>> reconfirm). >>>> >>>> I'm shooting from the hip with this followup question but: Is it >>>> possible to create, through configs, a simple DB customer backend that >>>> consists of a table stored in a MySQL db? I could create that with relative >>>> ease and it would contain data replicated from one of our other systems. >>>> >>>> Thanks again for the help, >>>> /bogdan >>>> >>>> >>>> >>>> On Mon, Oct 15, 2012 at 3:04 PM, Gerald Young >>> > wrote: >>>> >>>>> The details for an individual customer can be found from the >>>>> Customer link on creation of a new ticket (Options above body). As for >>>>> customer company, not really ability to "look up" except in the context >>>>> that, with CustomerCompanySupport enabled, the company information will >>>>> indeed be linked to the customer, and show in the Customer Info section of >>>>> a given ticket. >>>>> >>>>> Also, if the information is an LDAP source or otherwise marked >>>>> as ReadOnly in Config.pm because the data entry is handled by the external >>>>> data source frontend (ADUC, SalesForce, etc.), modifications to the >>>>> customer and customer company information via the web interface won't be >>>>> possible. >>>>> >>>>> On Mon, Oct 15, 2012 at 7:20 AM, Bogdan Iosif < >>>>> bogdan.iosif@gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I think I found the answer to my question in an older mailing >>>>>> list entry: >>>>>> http://lists.otrs.org/pipermail/otrs/2012-March/037662.html >>>>>> >>>>>> Hi Cyrille, >>>>>>> >>>>>>> That’s a common misunderstanding in OTRS! >>>>>>> >>>>>>> Group_ro only means that you only need “ro” permissions to access the module. >>>>>>> >>>>>>> What you can do within the module is not limited or controled by this setting. >>>>>>> >>>>>>> The module AdminUser doesn’t have a deeper permission concept. >>>>>>> >>>>>>> If you can access the module you can administrate agents/users, nothing else - no further magic or hacks here. >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> Cheers, Nils >>>>>>> >>>>>>> >>>>>> So unless anyone thinks the above answer is obsolete, I'll just >>>>>> assume that read-only access is not achievable at this time through >>>>>> configuration. >>>>>> >>>>>> /bogdan >>>>>> >>>>>> >>>>>> On Mon, Oct 15, 2012 at 12:06 PM, Bogdan Iosif < >>>>>> bogdan.iosif@gmail.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I managed to give full access to Customers / Companies modules >>>>>>> for regular agents by including them in a newly created group - >>>>>>> AgentCcGroup - and then adding this group in the following "Group ro" >>>>>>> sections from SysConfig -> Framework -> Frontend::Admin::ModuleRegistration >>>>>>> >>>>>>> - Frontend::Module###Admin >>>>>>> - Frontend::Module###AdminCustomerUser >>>>>>> - Frontend::Module###AdminCustomerCompany >>>>>>> >>>>>>> Trouble is, the resulting access type is full - i.e. the >>>>>>> agents can do any modifications to customer / companies details - and I >>>>>>> need the access type to be "read-only". Also, I'm confused by what "Group >>>>>>> ro" means as I expected it to mean "read-only" but practice showed me >>>>>>> otherwise. >>>>>>> >>>>>>> I was guided by this >>>>>>> http://forums.otterhub.org/viewtopic.php?f=60&t=7561 solution >>>>>>> to the same problem but it doesn't touch too much on the read-only part of >>>>>>> my requirement, it just ~implies it should work. >>>>>>> >>>>>>> Does anyone know if there is such a thing as "read-only" >>>>>>> access to a module in the sense that the user can explore it's GUI but not >>>>>>> make changes? (or even better, someone maybe solved this exact problem?) >>>>>>> >>>>>>> Thanks, >>>>>>> Bogdan >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >>> >> >> >> >> --------------------------------------------------------------------- >> 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 >> > > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
participants (2)
-
Bogdan Iosif
-
Gerald Young