Re: [otrs] Can non-admins be allowed read-only access to customer / companies details?

15 Oct 2012

      ...
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