I ask because I have developed as an extension for AT the ability to
enforce CF value uniqueness for single-valued CFs. This is important
in AT for things like CFs holding serial numbers, MAC addresses etc. I
have had nasty things happen because people added duplicates for
these. I added the ability to be able to enforce single-valued CF
value uniqueness within asset types or across all asset types. If you
try to add a duplicate for such a field, it will fail and tell you
what the conflcting asset is.
However, doing this required modifications to RT - stuff in
CustomField update code (AT calls the RT API for this) and lots of
mods to
/Admin/CustomFields/Modify.html
Is there any interest in including this functionality for RT in
general? I must say it’s not as obviously useful for tickets or other
CFs but I haven’t thought about such use cases much. Another
motivation for asking is that I’d like to have this in AT but it’s
impossible to make it an AT-only thing (without enormous AT mods)
because AT uses RT code and HTML templates for much of its CF stuff.
PK
Dr Philip Kime
I ask because I have developed as an extension for AT the ability to
enforce CF value uniqueness for single-valued CFs. This is important
in AT for things like CFs holding serial numbers, MAC addresses etc. I
have had nasty things happen because people added duplicates for
these. I added the ability to be able to enforce single-valued CF
value uniqueness within asset types or across all asset types. If you
try to add a duplicate for such a field, it will fail and tell you
what the conflcting asset is.
However, doing this required modifications to RT - stuff in
CustomField update code (AT calls the RT API for this) and lots of
mods to
/Admin/CustomFields/Modify.html
Is there any interest in including this functionality for RT in
general? I must say it’s not as obviously useful for tickets or other
CFs but I haven’t thought about such use cases much. Another
motivation for asking is that I’d like to have this in AT but it’s
impossible to make it an AT-only thing (without enormous AT mods)
because AT uses RT code and HTML templates for much of its CF stuff.
It seems like it could be interesting and a lot less invasive than some
of the other very cool CF hacking you’ve been doing. (As mentioned
before, I really dig the concept of strengthening mandatory fields, but
am pretty nervous about the fallout of doing that within a stable
series.
This seems like it could be slipped in pretty cleanly using the existing
validation codepath.
-j
It seems like it could be interesting and a lot less invasive than
some
of the other very cool CF hacking you’ve been doing. (As mentioned
before, I really dig the concept of strengthening mandatory fields,
but
am pretty nervous about the fallout of doing that within a stable
series.
This seems like it could be slipped in pretty cleanly using the
existing
validation codepath.
Yes, it doesn’t really, unlike the mandatory patches, replace anything
so it can be just ignored by those who don’t need it. I might try to
get the patches together against 3.8 - it’s nothing really too
dangerous.
The mandatory stuff is only a little more trouble in terms of fallout
because to avoid confusion, it means removing the Validation calls
currently in RT and removes the regexp-based mandatory approach
completely which may bother some people but not that many I would
think. Pretty easy to move to using a real mandatory field for those
who do. The other thing is that email ticket submission to queues with
mandatory fields will fail without CommandByMail and the ability to
specify CFs by email. But that’s a feature, not a problem - a
mandatory field that can be bypassed by email submission isn’t really
mandatory.
The main push for this is auditing - the last time I was involved in
an audit, the SOX people simply wouldn’t pass RT unless it had this
mandatory code in it because they couldn’t be sure that certain audit
information was guaranteed to be included with tickets in certain
queues. I think that this is a very important thing indeed for RT
personally - you have to have something like this in modern, audited
environments.
PK
Dr Philip Kime
The mandatory stuff is only a little more trouble in terms of fallout
because to avoid confusion, it means removing the Validation calls
currently in RT and removes the regexp-based mandatory approach
completely which may bother some people but not that many I would think.
Pretty easy to move to using a real mandatory field for those who do. The
other thing is that email ticket submission to queues with mandatory
fields will fail without CommandByMail and the ability to specify CFs by
email.
Right. And that’s not an acceptable change in the middle of a stable
series. If it’s optional, that potentially becomes more reasonable.
The mandatory stuff is only a little more trouble in terms of fallout
because to avoid confusion, it means removing the Validation calls
currently in RT and removes the regexp-based mandatory approach
completely which may bother some people but not that many I would think.
Pretty easy to move to using a real mandatory field for those who do. The
other thing is that email ticket submission to queues with mandatory
fields will fail without CommandByMail and the ability to specify CFs by
email.
Right. And that’s not an acceptable change in the middle of a stable
series. If it’s optional, that potentially becomes more reasonable.
+1, there should be something like:
- email mandatory
- web mandatory
IMHO thought 
many installations I know needs only the web part.
Right. And that’s not an acceptable change in the middle of a stable
series. If it’s optional, that potentially becomes more reasonable.
+1, there should be something like:
- email mandatory
- web mandatory
Maybe:
“mandatory at create time”
“mandatory when edited by a privileged users”
“mandatory to resolve”
Right. And that’s not an acceptable change in the middle of a stable
series. If it’s optional, that potentially becomes more reasonable.
+1, there should be something like:
- email mandatory
- web mandatory
Maybe:
“mandatory at create time”
“mandatory when edited by a privileged users”
“mandatory to resolve”
That sounds perfect to me - we have some code here which I might be able
to clean up and push upstream that does more or less what is described
there.
Certainly RT’s validation could do with being more flexible then
“mandatory or not mandatory”.
Jon Wood
Systems Developer, Claranet Ltd
The mandatory stuff is only a little more trouble in terms of fallout
because to avoid confusion, it means removing the Validation calls
currently in RT and removes the regexp-based mandatory approach
completely which may bother some people but not that many I would
think.
Pretty easy to move to using a real mandatory field for those who
do. The
other thing is that email ticket submission to queues with mandatory
fields will fail without CommandByMail and the ability to specify
CFs by
email.
Right. And that’s not an acceptable change in the middle of a stable
series. If it’s optional, that potentially becomes more reasonable.
But it is optional to make a field mandatory. If you never check that
box on a field (and it’s not checked by default), there is no
difference to how RT currently handles CFs.
PK
Dr Philip Kime
Right. And that’s not an acceptable change in the middle of a stable
series. If it’s optional, that potentially becomes more reasonable.
But it is optional to make a field mandatory. If you never check that
box on a field (and it’s not checked by default), there is no difference
to how RT currently handles CFs.
My recollection was that the previous version of the code changed
the existing validation/mandatory functionality in a
non-backwards-compatible way.
Am I misremembering?
and removes the regexp-based mandatory approach
completely which may bother some people but not that many I would
think.
Why remove it? I like the ability to check for integers, etc. Actually,
I was pondering to submit the rules I need to write, at some point.
Think email, IP address, etc.
Fun fact: I recently sent out a wishlist item, asking for a mandatory
alongside the current regexp approach. “May be empty or must match
foo” is a lot more flexible than “Must match foo”
The main push for this is auditing - the last time I was involved in
an audit, the SOX people simply wouldn’t pass RT unless it had this
mandatory code in it because they couldn’t be sure that certain audit
information was guaranteed to be included with tickets in certain
queues. I think that this is a very important thing indeed for RT
personally - you have to have something like this in modern, audited
environments.
Aye.
Richard
and removes the regexp-based mandatory approach
completely which may bother some people but not that many I would
think.
Why remove it? I like the ability to check for integers, etc.
Actually,
I was pondering to submit the rules I need to write, at some point.
Think email, IP address, etc.
Fun fact: I recently sent out a wishlist item, asking for a mandatory
alongside the current regexp approach. “May be empty or must match
foo” is a lot more flexible than “Must match foo”
I meant that my patches just removes the “[mandatory]” pattern from
the list of default regexes as this would be dealt with by a dedicated
option. I agree completely that the regexp validation should stay
alongside, as you say, a separate mandatory status. I like the idea of
being able to say “must be present” completely separately from what
must be present. It’s easier to show to auditors too - you say “look,
this field is mandatory”, rather than “look, this field must match
this pattern and there is a “+” here which means that it can’t be
completely empty, which means it’s effectively mandatory”. They don’t
like that much. I do understand BP can’t just change things to make it
work like this since people will be using the regexp as a virtual
mandatory enforcement.
PK
Dr Philip Kime
Is there any interest in including this functionality for RT in
general?
While you are in there, do you think it would be possible to
access the data of CF.{foo} from CF.{bar}? I tried to make this
work for URL generation (I need to create a link from two
fields), but couldn’t. As I did not (yet?) get any answer to
my mails on -user, I am stuck.
It’s an extremely long shot, but I asking never hurt anyone 
RIchard
Actually, guys, RT 3.8.1 is pretty close to what you want these days.
I’ll to describe what I mean. You all want different things and I’m
unsure we can develop any web interface to manage all those
requirements, but 3.8.1 can return to Update/Create pages when there
are GnuPG or CF checks fail and there are callbacks in both pages. You
can use them to check any conditions you want, setup $checks_failure
reference and push a message for user.
I’m not sure how flexible it is for various rules, but I think we can
try to improve flexibility.On Thu, Oct 23, 2008 at 1:38 AM, Richard Hartmann richih.mailinglist@gmail.com wrote:
2008/10/20 Jesse Vincent jesse@bestpractical.com:
“mandatory at create time”
“mandatory when edited by a privileged users”
“mandatory to resolve”
also:
- mandatory to change owner
- mandatory to change status to foo (replacing your “to resolve” above)
- mandatory if other field is set/filled/changed/emptied
- mandatory if in a certain queue
[…]
Richard
List info: The rt-devel Archives
Best regards, Ruslan.