AW: [rt-users] AW: [rt-usersl] [Fwd: 2-1-79 questions]

[Gerald Fehringer]

RE: [rt-users] AW: [rt-usersl] [Fwd: 2-1-79 questions]hi,

i never so a option like *pseudo-groups*, where can i add this kind of
groups ?

my issue is that the customer is NOT allowed to create new tickets, only the
customer care team.
he should see only his new/closed tickets and should be able to add new
comments, that's it.

no, i use the local user database, we don't have so much customers.

well, unfortunately i'm also not a big perl crack (perl syntax ;-))

kind regards
geri


BTW: RT3 IS REALLY AWESOME, great work Jesse & the rest of the development
!!


  -----Ursprüngliche Nachricht-----
  Von: THAUVIN Blaise (Dir. Informatique) [mailto:bthauvin at clearchannel.fr]
  Gesendet: Donnerstag, 6. März 2003 12:10
  An: 'gerald.fehringer at openadvice.de'; RT Users
  Betreff: RE: [rt-users] AW: [rt-usersl] [Fwd: 2-1-79 questions]


  I never tried it for real, but I think the solution to your problem is to
be found in the "pseudogroups". You have pseudogroups for requestors, CCs,
AdminCCs and Owner.

  I you grant priviledges to the requestors in your queue, each customer
will be able to see the tickets he personnaly created, as he will be the
requestor. He will not see other tickets in the queue which belong to other
resquestors. Is this level of confidentiality what you need?

  If you want some specific people at your customer to see all tickets,
you'all have to give them specific rights to the queue.

  If you wan't to make the entire queue visible to anybody at your customer,
but still need to hide some other queues to them, you can play with the
"everyone" group applied individualy on each queue. This will only work if
you have one customer. As soon as you get two, you'll need to create a group
per customer.

  Are you using an external user base? ie : do you rely or not on automatic
usder creation? If the customer can be identified through the email domain,
it would be rather easy to add the user to the proper group on creation. As
I am not a perl developer, I could only do it through database SQL queries,
but somebody more knowledgable than me could do better.

  Would thgis be a "on user creation" scrip condition to add?



  Blaise

  -----Message d'origine-----
  De : Gerald Fehringer [mailto:gerald.fehringer at openadvice.de]
  Envoyé : jeudi 6 mars 2003 11:38
  À : RT Users
  Objet : [rt-users] AW: [rt-usersl] [Fwd: 2-1-79 questions]



  Dear Members,

  first of all, i apologies for the urgent flag, this was unmeant !
  Well, i was posting this question at the devel list, because i'm
  using rt 2-1-80 (since this morning) so i thought it's related
  to the devel list.

  my problem:
  the basic view contents only: new/close/view & changing password.
  this is exactly the view what we would like to have for our
  customers, because they should only have rights to see their closed
  or new tickets in their queue, nothing else and they should not
  confused with to much extra informations !

  Ticket creation/modify etc. should be only allowed for our customer care.

  so if i create a unprivileged user, first of all i can't see the user
  (only when i look up also for deactive user, makes not really sense)
  the next logic step would be, to create a group for this specific
  customer queue (each of our customers will have their own queue) and
  add this unprivileged user to the group.
  not possible, because the user doesn't appear on the screen.
  so the only way is to give this customer queue all unprivileged user
  according permissions :-(
  so if i have several customers, everyone can see ALL queus !

  they only way i can resolve this issue, right now, is to set for this
  customer queue the user as watcher and then i define the according
  permissions for this watcher.
  (not really a good idea, because he should not get any emails, only
  when our employees create a new ticket for him. he should only check
  his stutus/history in his own customer view)



  Any ideas ?

  thank you,
  geri


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20030306/521381d5/attachment.htm>