Re: [otrs] GenericAgent doesn't delete tickets

2014-11-27 Thread Martin Gruner
Hi Ralf,

which OTRS version do you use?

Regards, mg


Am 21.11.14 um 14:10 schrieb Ralf Hildebrandt:
> I created a generic agent to delete some old, unneeded tickets.
> The system reports:
> 
> 6901 Tickets sind betroffen! Was wollen Sie tun?
> Warnung: Sie verwenden die Option LÖSCHEN. Alle gelöschten Tickets
> gehen verloren!
> 
> Job bearbeiten
> Job ausführen
> oder Abbrechen
> 
> Clicking on "Job ausführen" invokes:
> 
> https://otrs.charite.de/otrs/index.pl?Action=AdminGenericAgent;Subaction=RunNow;Profile=name%20of%20job;ChallengeToken=Td1PuaA8mFWDAze8lBQDitcnERsgHUF9;
> 
> which returns immediately, not deleting anything.
> Prior to that I executed the SAME job (on about 10.000 tickets), which
> obviously didn't delete all 10.000 but "only" 3.000
> 

-- 
Martin Gruner
Senior Developer R&D

OTRS AG
Bahnhofplatz 1a
94315 Straubing

T: +49 (0)6172 681988 0
F: +49 (0)9421 56818 18
I:  www.otrs.com/

Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751,
USt-Nr.: DE256610065
Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André
Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel

Schlanker, schneller und flacher denn je - OTRS 4! Und für alle, die
MEHR wollen: Entdecken Sie hier die OTRS Business Solution™ mit mehr
Business Features!
https://www.otrs.com/otrs-business-solution-fuer-besseren-kundenservice/?lang=de
-
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] Generic REST Interface TicketUpdate function with python

2014-11-27 Thread Michael Ablassmeier

hi guys,

im playing around with the new REST Interface struggling to find out how 
to pass valid data to the TicketUpdate function. I can read the

TicketData with the TicketGet function without any problems, but fail
to update any ticket information.

I have registered the WS as following:


---
Debugger:
  DebugThreshold: debug
  TestMode: '0'
Description: ''
FrameworkVersion: 4.0.1
Provider:
  Operation:
TicketGet:
  Description: ''
  MappingInbound:
Type: Simple
  MappingOutbound:
Type: Simple
  Type: Ticket::TicketGet
TicketUpdate:
  Description: ''
  MappingInbound:
Type: Simple
  MappingOutbound:
Type: Simple
  Type: Ticket::TicketUpdate
  Transport:
Config:
  KeepAlive: ''
  MaxLength: '2000'
  RouteOperationMapping:
TicketGet:
  Route: /TicketGet/:TicketID
TicketUpdate:
  RequestMethod:
  - POST
  Route: /TicketUpdate/:TicketID
Type: HTTP::REST
RemoteSystem: ''
Requester:
  Transport:
Type: '



And i try to access the TicketUpdate Function via python, short
snipped like this:



ticketdata = dict(
UserLogin='username',
Password='username',
Data=dict(
Ticket=dict(
Title='changeme'
))
)
url = 
'http://myotrs/otrs/nph-genericinterface.pl/Webservice/Test/TicketUpdate/10017'
r = requests.post(url, params=ticketdata)
print r.content


And the TicketUpdate function returns like:


{"TicketNumber":"201411268111","TicketID":"10017"}


but does not change anything in the Ticket and does not
error out.

Looking at the debugger it seems clear that not all data
is passed in my post request:


Incoming data before mapping (2014-11-27 10:41:34, debug)
$VAR1 = {
  'Data' => 'Ticket',
  'Password' => 'username',
  'RequestMethod' => 'POST',
  'TicketID' => '10017',
  'UserLogin' => 'username'
};
Incoming data after mapping (2014-11-27 10:41:34, debug)
$VAR1 = {
  'Data' => 'Ticket',
  'Password' => 'username',
  'RequestMethod' => 'POST',
  'TicketID' => '10017',
  'UserLogin' => 'username'
};


but i struggle to find out how to pass it rightfully?
Passing a json.dumps() generated data string will error
out and urlencoding seems not the right way. Can someone
give me a pointer here? Thanks!
--
Michael Ablassmeier
Senior Support Engineer

Ziegelstrasse 1
D-83629 Weyarn

Fon+49 (0) 80 20 / 180-0
Fax+49 (0) 80 20 / 180-666

Mailsupp...@sep.de
Web   http://www.sep.de
-
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] How multiple authentication and identity backends for agents and customers work

2014-11-27 Thread Bogdan Iosif
Hi,

This email is an extended documentation of how multiple authentication and
identity backends for agents and customers work. The information herein was
tested on OTRS 3.3.7. I decided to publish it after parsing through a lot
of useless Internet search results about the subject and ultimately having
to explore the source code to figure out how things work.

I wrote the doc while setting up 2 backend types: DB and LDAP

To be able to use this documentation you need to know how to configure OTRS
via Config.pm and to understand how OTRS works out of the box using the DB
backend type for its authentication / identity info needs.

HTH someone.

Regards,
Bogdan

- OTRS supports multiple types of backends (e.g. DB and LDAP (WinAD))

- OTRS distinguishes between backends used for agents and backends used for
customers

- OTRS distinguishes between backends used for authentication and backends
used for identity info / details
- Using a backend for authentication means verifying given credentials
with the backend to ensure they are valid
- Using a backend for identity info means:
- Using a given agent / customer id (but not its password) to
retrieve from the backend detailed info about this identity (e.g. retrieve
first name, last name, address, email, etc.)
- Searching and retrieving identity info for a set of agent /
customer identities from the backend

- Up to 11 backends of varying types are supported for each of the
following:
- Agent authentication, Agent identity info, Customer authentication,
Customer identity info

- Correlating configurations with multiple physical backends
- Having a different configuration for an agent / customer
authentication backend vs. an identity info backend is a niche case.
Usually, the same physical backend needs to be configured at least twice,
once for authentication and once for identity info. When the same physical
backend is used for both agents and customer it needs to be configured four
times (each in slightly different ways).
- When more than one physical backend needs to be used (e.g. DB + LDAP)
care must be taken to configure them in the same order each time to avoid
inexplicable behavior

- Configuring backends for agent authentication
- Each backend is configured by specifying a set of settings (available
in Defaults.pm) with names like:
- {AuthModule*},
{'AuthModule::%{DB|LDAP|...}%::%SettingShortName%*'}
- The settings for the first configured backend appear with names as
found in Defaults.pm
- Settings for additional backends appear by duplicating the initial
setting set and modifying their names
- Choose a number between 1..10 to identify the additional set
- Modify all duplicated setting names by appending the set number
to their name
- e.g. For original set: {AuthModule},
{'AuthModule::%{DB|LDAP|...}%::%SettingShortName%'} ...
- e.g. For set 1: {AuthModule1},
{'AuthModule::%{DB|LDAP|...}%::%SettingShortName%1'} ...
- Each configured backend must specify if it's paired with a backend
for identity info
- The configuration setting set contains a setting named like
'AuthSyncBackend*' having either the empty value or values like
'AuthSyncBackend*'
- The empty value ('') means this backend is not paired with an
identity info backend and no sync must be attempted after agent login
- The value 'AuthSyncBackend' means this backend is paired with
the identity info backend specified through the settings set named like
{AuthSyncModule}, {'AuthSyncModule::%{DB|LDAP|...}%::%SettingShortName%'}
... and a sync must occur after agent login
- The value 'AuthSyncBackend1' means this backend is paired
with the identity info backend specified through the settings set named
like {AuthSyncModule1},
{'AuthSyncModule::%{DB|LDAP|...}%::%SettingShortName%1'} ... and a sync
must occur after agent login
- etc.

- Configuring backends for agent identity info
- Each backend is configured by specifying a set of settings (available
in Defaults.pm) with names like:
- {AuthSyncModule*},
{'AuthSyncModule::%{DB|LDAP|...}%::%SettingShortName%*'}
- The settings for the first configured backend appear with names as
found in Defaults.pm
- Settings for additional backends appear by duplicating the initial
setting set and modifying their names
- Choose a number between 1..10 to identify the additional set
- Modify all duplicated setting names by appending the set number
to their name
- e.g. For original set: {AuthSyncModule},
{'AuthSyncModule::%{DB|LDAP|...}%::%SettingShortName%'} ...
- e.g. For set 1: {AuthSyncModule1},
{'AuthSyncModule::%{DB|LDAP|...}%::%SettingShortName%1'} ...
- Agent identity info is retrieved (synched) after every successful
authentication and stored in OTRS' DB
- After sync, identity info is used directly from OTRS' DB where
it's stored in a single tab