Default password

Regarding what makes a field “mandatory”:

What I’d love to see (and what I initially assumed the “mandatory” option
provided) was for fields to be required before a ticket could be resolved.

We have yet to implement the mandatory feature on any queues here because,
for the vast majority of the time, the fields we’d love to require don’t
contain information we have when the request is made, but rather pertain to
the steps/process we go through to resolve a ticket.

It would be great if, in future versions, you could specify mandatory for
ticket creation and mandatory for ticket resolution.

ForrestOn 8/8/07, Ruslan Zakirov ruz@bestpractical.com wrote:

On 8/8/07, Ham MI-ID, Torsten Brumm torsten.brumm@kuehne-nagel.com wrote:

Hmmmm, an new right would not fix the core of the problem…i think
this
not only occurs on create, this can also hapen at resolve time.
What exactly can happen?

From the workflow point of view we have the situation that a user
creates a
ticket with only limited rights, later groups working at the same ticket
have more rights and have to set this cf, later groups only need to see
what
happens with this ticket and resolve this…
Ok, if user who creates a ticket has no right to set/modify a CF and
some privileged user should set it later, then why this CF is
mandatory? I think it shouldn’t be.

I think to bypass the mandatory check and only display the cf if needed
but
with no chance to ut something should be a cleaner solution?!?
“ut” == “put”?

What should we show? Disabled input/select box? User can not set a
field then why should we confuse him by showing it?

Torsten

-----Original Message-----
From: ruslan.zakirov@gmail.com ruslan.zakirov@gmail.com
To: Ham MI-ID, Torsten Brumm
CC: rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com
Sent: Wed Aug 08 18:02:08 2007
Subject: Re: Re: [rt-users] Custom Fields and Rights Question / maybe a
bug

If a CF is mandatory then all users who can create tickets in queues
CF applies to must have ‘ModifyCustomField’ right. I think this way.
Do you have another ideas? At least as I understand this the way it
work now.

I was thinking about while fixing bug in 3.7 and came to two ideas:

  1. Mandatory CFs must have default value. So when people couldn’t set
    a CF then we apply default and the fact that the CF is mandatory
    doesn’t prevent creation.
  2. We can add new ‘SetCustomFieldOnCreate’ right which can be useful
    in many workflows and also admins would be able to allow users to
    create tickets with mandatory fields, but deny changing a field after
    that.

Both ideas are subject of RT 3.8 only, as I said we can only back port
a patch from 3.8 to avoid confusion of users and admins.

On 8/8/07, Ham MI-ID, Torsten Brumm torsten.brumm@kuehne-nagel.com wrote:

Hi ruslan,

Yes for a normal cf this is not critical, but together with a cf set
to
mandatory this becomes critical, because the user is not able to
create a
ticket via gui anymore for this queue :frowning:

Torsten

-----Original Message-----
From: ruslan.zakirov@gmail.com ruslan.zakirov@gmail.com
To: Ham MI-ID, Torsten Brumm
CC: rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com
Sent: Wed Aug 08 16:13:33 2007
Subject: Re: [rt-users] Custom Fields and Rights Question / maybe a
bug

On 8/8/07, Ham MI-ID, Torsten Brumm torsten.brumm@kuehne-nagel.com wrote:

Hi RT Users, Developers,

i’m not 100% sure if this is a bug or if i’m again too dumb…

For a Custom Field, I can grant the following Group Rights:

SeeCustomField
ModifyCustomField
AdminCustomField

From my point of understanding, SeeCustomFields allows a user to
see
the
CF and it’s content, but not to change it?
right

ModifyCustomFields grant him the right to change the Content of
the CF
and AdminCF grants him the right to change this CF, is this correct
so
far?
AdminCF allow user to admin a CF, add new possible values, change
type…
ModifyCF allow user to modify value(s) of a CF on tickets or objects
this particular CF applies to.

If the point above is correct, then if a user that only have the
rights
SeeCustomField should only be able to see this field and content, but
should
not be able to change the content?
right.

OK, now my problem and why I’m thinking that’s a bug…

If a user creates a ticket in a queue with a custom field assigned
and
he
has only the right SeeCustomField at this CF, he should see the field
but
should not be able to enter something there?!? But he is…!..is
this
the
correct way of handling the ACL or do I something wrong?
Yeah, there is a small bug on create. User see fields he can see
even
if he can’t modify them, but as far as I know user gets ‘permission
denied’ after creation for fields he can’t modify.

In 3.7 development branch we don’t show fields user can’t modify on
the create ticket page anymore. I think we can backport that fix.

Its under RT 3.6.4 and I have double checked the rights, the
global
rights, group rights and user rights…

Any Ideas or hints or understand I the rights Setup for CF totally
wrong???

Thanks in advance

: Torsten Brumm
:
: Kuehne + Nagel
: HAM - MI-ID
:
: Bauerbergweg 23-25
: 22111 Hamburg
:
: +49 (40) 30333 3199
: +49 (40) 30333 44 3199
:
: torsten.brumm@kuehne-nagel.com
: www.kn-portal.com
: icq: 78258840

Kühne + Nagel (AG & Co.) KG, Geschäftsleitung: Hans-Georg
Brinkmann
(Vors.), Uwe Bielang (Stellv.), Dr. Björn Johansson (Stellv.), Bruno
Mang,
Alfred Manke, Thorsten Meincke, Mark Reinhardt (Stellv.), Tim
Scharwath,
Jens Wollesen Sitz: Bremen, Registergericht: Bremen, HRA 21928,
USt-IdNr.:
DE 812773878, Persönlich haftende Gesellschaft: Kühne & Nagel A.G.,
Sitz:
Contern/LuxemburgGeschäftsführender Verwaltungsrat:
Klaus-Michael Kühne


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly
Media.
Buy a copy at http://rtbook.bestpractical.com


Best regards, Ruslan.


Best regards, Ruslan.


Best regards, Ruslan.


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

To all,

I can think of many situations where I could have a business group 

watching the progress (workflow status, etc.) of a ticket that is
set/modified using a custom field. They need to see it because they are
affected, but I do not want them to change it.

Kenn
LBNL

Ruslan Zakirov wrote:> On 8/8/07, Ham MI-ID, Torsten Brumm torsten.brumm@kuehne-nagel.com wrote:

Hmmmm, an new right would not fix the core of the problem…i think this
not only occurs on create, this can also hapen at resolve time.
What exactly can happen?

From the workflow point of view we have the situation that a user creates a
ticket with only limited rights, later groups working at the same ticket
have more rights and have to set this cf, later groups only need to see what
happens with this ticket and resolve this…
Ok, if user who creates a ticket has no right to set/modify a CF and
some privileged user should set it later, then why this CF is
mandatory? I think it shouldn’t be.

I think to bypass the mandatory check and only display the cf if needed but
with no chance to ut something should be a cleaner solution?!?
“ut” == “put”?

What should we show? Disabled input/select box? User can not set a
field then why should we confuse him by showing it?

Torsten

-----Original Message-----
From: ruslan.zakirov@gmail.com ruslan.zakirov@gmail.com
To: Ham MI-ID, Torsten Brumm
CC: rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com
Sent: Wed Aug 08 18:02:08 2007
Subject: Re: Re: [rt-users] Custom Fields and Rights Question / maybe a bug

If a CF is mandatory then all users who can create tickets in queues
CF applies to must have ‘ModifyCustomField’ right. I think this way.
Do you have another ideas? At least as I understand this the way it
work now.

I was thinking about while fixing bug in 3.7 and came to two ideas:

  1. Mandatory CFs must have default value. So when people couldn’t set
    a CF then we apply default and the fact that the CF is mandatory
    doesn’t prevent creation.
  2. We can add new ‘SetCustomFieldOnCreate’ right which can be useful
    in many workflows and also admins would be able to allow users to
    create tickets with mandatory fields, but deny changing a field after
    that.

Both ideas are subject of RT 3.8 only, as I said we can only back port
a patch from 3.8 to avoid confusion of users and admins.

On 8/8/07, Ham MI-ID, Torsten Brumm torsten.brumm@kuehne-nagel.com wrote:

Hi ruslan,

Yes for a normal cf this is not critical, but together with a cf set to
mandatory this becomes critical, because the user is not able to create a
ticket via gui anymore for this queue :frowning:

Torsten

-----Original Message-----
From: ruslan.zakirov@gmail.com ruslan.zakirov@gmail.com
To: Ham MI-ID, Torsten Brumm
CC: rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com
Sent: Wed Aug 08 16:13:33 2007
Subject: Re: [rt-users] Custom Fields and Rights Question / maybe a bug

On 8/8/07, Ham MI-ID, Torsten Brumm torsten.brumm@kuehne-nagel.com wrote:

Hi RT Users, Developers,

i’m not 100% sure if this is a bug or if i’m again too dumb…

For a Custom Field, I can grant the following Group Rights:

SeeCustomField
ModifyCustomField
AdminCustomField

From my point of understanding, SeeCustomFields allows a user to see
the
CF and it’s content, but not to change it?
right

ModifyCustomFields grant him the right to change the Content of the CF
and AdminCF grants him the right to change this CF, is this correct so
far?
AdminCF allow user to admin a CF, add new possible values, change
type…
ModifyCF allow user to modify value(s) of a CF on tickets or objects
this particular CF applies to.

If the point above is correct, then if a user that only have the
rights
SeeCustomField should only be able to see this field and content, but
should
not be able to change the content?
right.

OK, now my problem and why I’m thinking that’s a bug…

If a user creates a ticket in a queue with a custom field assigned and
he
has only the right SeeCustomField at this CF, he should see the field but
should not be able to enter something there?!? But he is…!..is this
the
correct way of handling the ACL or do I something wrong?
Yeah, there is a small bug on create. User see fields he can see even
if he can’t modify them, but as far as I know user gets ‘permission
denied’ after creation for fields he can’t modify.

In 3.7 development branch we don’t show fields user can’t modify on
the create ticket page anymore. I think we can backport that fix.

Its under RT 3.6.4 and I have double checked the rights, the global
rights, group rights and user rights…

Any Ideas or hints or understand I the rights Setup for CF totally
wrong???

Thanks in advance

: Torsten Brumm
:
: Kuehne + Nagel
: HAM - MI-ID
:
: Bauerbergweg 23-25
: 22111 Hamburg
:
: +49 (40) 30333 3199
: +49 (40) 30333 44 3199
:
: torsten.brumm@kuehne-nagel.com
: www.kn-portal.com
: icq: 78258840

K�hne + Nagel (AG & Co.) KG, Gesch�ftsleitung: Hans-Georg Brinkmann
(Vors.), Uwe Bielang (Stellv.), Dr. Bj�rn Johansson (Stellv.), Bruno
Mang,
Alfred Manke, Thorsten Meincke, Mark Reinhardt (Stellv.), Tim Scharwath,
Jens Wollesen Sitz: Bremen, Registergericht: Bremen, HRA 21928,
USt-IdNr.:
DE 812773878, Pers�nlich haftende Gesellschaft: K�hne & Nagel A.G., Sitz:
Contern/LuxemburgGesch�ftsf�hrender Verwaltungsrat:
Klaus-Michael K�hne


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


Best regards, Ruslan.


Best regards, Ruslan.



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

To all,

"It would be great if, in future versions, you could specify mandatory 

for ticket creation and mandatory for ticket resolution."
Here Here! That is an excellent suggestion.

Kenn
LBNL

Forrest Blount wrote: