Custom fields more flexible

A (supported) way to make custom fields read-only.
Or more generally - finer-grained permissions.

My case occurs because we're doing an integration and displaying the
sourceid (the changing of which would unlink a crm item from its source).

savage
Fri Nov 26 15:42:39 CST 2004

not possible with the current crm version...but you can try putting the field
into a tab thats not used very often...like the 'Administration' tab

"Nick Doyle" wrote:

> A (supported) way to make custom fields read-only.
> Or more generally - finer-grained permissions.
>
> My case occurs because we're doing an integration and displaying the
> sourceid (the changing of which would unlink a crm item from its source).

Jason
Sat Nov 27 13:11:02 CST 2004

The User interface does not provide a way to mark the custom field as read
only, however there is a very simple edit that you can make to the METABASE
database for your custom field that will make it read only. If you are
interested in the details of how to do it, let me know and I can post SQL
scripts to get this accomplished.

Please note that it is not officially supported by Microsoft but I have benn
using this technique in our production environment for over 6 months with no
issues.

Jason

"savage" wrote:

> not possible with the current crm version...but you can try putting the field
> into a tab thats not used very often...like the 'Administration' tab
>
> "Nick Doyle" wrote:
>
> > A (supported) way to make custom fields read-only.
> > Or more generally - finer-grained permissions.
> >
> > My case occurs because we're doing an integration and displaying the
> > sourceid (the changing of which would unlink a crm item from its source).

Rick
Sun Nov 28 06:43:05 CST 2004

Yea we need readonly fields ! pls paste your code
thanks
Rick

"Jason" wrote:

> The User interface does not provide a way to mark the custom field as read
> only, however there is a very simple edit that you can make to the METABASE
> database for your custom field that will make it read only. If you are
> interested in the details of how to do it, let me know and I can post SQL
> scripts to get this accomplished.
>
> Please note that it is not officially supported by Microsoft but I have benn
> using this technique in our production environment for over 6 months with no
> issues.
>
> Jason
>
> "savage" wrote:
>
> > not possible with the current crm version...but you can try putting the field
> > into a tab thats not used very often...like the 'Administration' tab
> >
> > "Nick Doyle" wrote:
> >
> > > A (supported) way to make custom fields read-only.
> > > Or more generally - finer-grained permissions.
> > >
> > > My case occurs because we're doing an integration and displaying the
> > > sourceid (the changing of which would unlink a crm item from its source).

Hendri
Sun Nov 28 23:01:01 CST 2004

the information below is UNSUPPORTED by Microsoft
check the metabase database
find table attribute
look at fields ValidForCreateAPI, ValidForUpdateAPI, ValidForReadAPI
those are flags to indicate user access to the attribute
ValidForCreateAPI ---> enable/disable user to edit the field/attribute upon
creation of new record
ValidForUpdateAPI ----> enable/disable user to edit the field/attribute upon
editting record
ValidForReadAPI ----> enable/disable user to view the field/attribute

Note: this three flags has direct consequences to ALL FIELDS, so use them
wisely

henyung

SteveChambers
Mon Nov 29 12:09:48 CST 2004

I would recommend in the strongest possible terms that you not do this. It
is totally unsupported, which means, among other things, that if you have
problems with your system, that MS will not support you.

Also, when the next version of CRM comes along, your upgrade will be a
nightmare.
There is some likliehood that this issue will be addressed in future versions.

Steve C.

"Hendri Irawan" wrote:

> the information below is UNSUPPORTED by Microsoft
> check the metabase database
> find table attribute
> look at fields ValidForCreateAPI, ValidForUpdateAPI, ValidForReadAPI
> those are flags to indicate user access to the attribute
> ValidForCreateAPI ---> enable/disable user to edit the field/attribute upon
> creation of new record
> ValidForUpdateAPI ----> enable/disable user to edit the field/attribute upon
> editting record
> ValidForReadAPI ----> enable/disable user to view the field/attribute
>
> Note: this three flags has direct consequences to ALL FIELDS, so use them
> wisely
>
> henyung
>
>
>

Matt
Mon Nov 29 13:11:06 CST 2004

While it's true that support may be an issue, it does NOT mean that MS will not
support you. They will do their best, but if they decide that the change you
made is the cause of the problem, then they may decide they can't help.

Matt Parks
MVP - Microsoft CRM

----------------------------------------
----------------------------------------
On Mon, 29 Nov 2004 10:09:48 -0800, "Steve Chambers"
<SteveChambers@discussions.microsoft.com> wrote:

I would recommend in the strongest possible terms that you not do this. It
is totally unsupported, which means, among other things, that if you have
problems with your system, that MS will not support you.

Also, when the next version of CRM comes along, your upgrade will be a
nightmare.
There is some likliehood that this issue will be addressed in future versions.

Steve C.

"Hendri Irawan" wrote:

> the information below is UNSUPPORTED by Microsoft
> check the metabase database
> find table attribute
> look at fields ValidForCreateAPI, ValidForUpdateAPI, ValidForReadAPI
> those are flags to indicate user access to the attribute
> ValidForCreateAPI ---> enable/disable user to edit the field/attribute upon
> creation of new record
> ValidForUpdateAPI ----> enable/disable user to edit the field/attribute upon
> editting record
> ValidForReadAPI ----> enable/disable user to view the field/attribute
>
> Note: this three flags has direct consequences to ALL FIELDS, so use them
> wisely
>
> henyung
>
>
>