Fields can be hidden from the listing table, hidden or removed from the form, made readonly, or changed per permission and in the administration only.

Listing columns

The column is not loaded into the listing table. Users can still enable it in the column chooser, and the field stays in the form. Fields of type editor, longeditor, password and json are hidden by default.Combine it with column_visible to show the column anyway, or with column_present to load the value for your own column component without showing the column.
The column is removed from the listing and from the column chooser. The field stays in the form and its value is saved.

Hiding fields in the form

The field is rendered but hidden. Its current value is still submitted and saved, which makes it useful for values set by another field or by a custom component.hideField is an alias.
The opposite of hideFromForm, mostly used with a condition: visibleFieldIf:type,company shows the field only for companies.
Hides the field only when creating, or only when editing a record. The value is still submitted. ifDoesntExists is an alias of hideOnUpdate.Hidden fields are still validated, so hideOnCreate|required cannot be submitted when creating a record.

Removing fields from the form

The field is not rendered in the form. By default, any submitted value is ignored and its required rule is skipped. Set the value in your code, for example in onCreate() or setAdminAttributes(), or add allowInput to accept a value submitted by your own component:
You can also use the removeField alias.A required column is created as NOT NULL. Give such a field a default, or set the value in a model event, otherwise creating a record fails.
Removes the field from the form and from the listing. It is a shortcut for hidden|removeFromForm.
Like invisible, and the column is also removed from the column chooser and from the search. Its value is not sent to the administration. Use it for technical columns an administrator should never work with.
Allows a submitted value to be processed even when the field has removeFromForm, invisible or disabled. Applies when creating and updating records. It does not render an input or submit a value automatically; your component must send it. Normal validation still applies.

Readonly and disabled fields

Renders a readonly input. When a record is created the value is submitted, so a default value is saved. When a record is updated, a posted value is ignored.
Renders a disabled input. The posted value is ignored, required is skipped and changes are not written into the history.

Conditional parameters

Parameters hideFromForm, visibleField, removeFromForm, invisible, inaccessible, inaccessible_column, readonly and disabled accept a condition evaluated live in the form while the user edits it. Add one of the postfixes: The first argument selects the value to compare: Values NULL (or an empty value), TRUE and FALSE are converted to null and booleans. id,NULL matches a record which is being created:
Conditions are evaluated in the browser only. The backend does not check them, a posted value is always saved. Validate dependent values with rules like required_if or prohibited_if, or in the model.
Whole groups and tabs can be hidden by a condition too, see conditional visibility of groups.

Permissions

With administrator groups enabled, parameters can depend on the permissions of the logged administrator. The first argument is the permission, the rest are parameters applied when the administrator has it (hasAccess) or does not have it (hasNotAccess).
  • Super administrators have every permission, and every administrator has access when administrator groups are disabled.
  • Permission parameters are applied only in the administration and the REST API, for the authenticated administrator. Outside of it (frontend, console, migrations) they are ignored, the field keeps only its own parameters. Model::validator() on the frontend is not affected by them.
  • Do not change the database schema or relations this way (locale, multiple, belongsTo, belongsToMany).
  • Parameters written directly on the field win over the permission parameters.

Full access

hasFullAccess and hasNotFullAccess apply parameters by whether the logged administrator is a super administrator. Every parameter is listed after the colon.

When permissions are applied

Fields are built once and cached, in the process and by php artisan admin:cache, the same for everybody. After the administrator is authenticated in the administration, permission parameters and inAdmin are applied on top of the cached fields for him, once per request. Do not read the logged administrator in fields(), use the permission parameters instead:
The rules work also in attributes of groups and tabs:
Avoid admin() and admin()->hasAdminAccess() in model definitions. A model whose fields() call admin() still works: CrudAdmin detects it and builds its fields again for the authenticated administrator in every administration request, which is slower. The compiled cache holds its fields as without the administrator. admin() returns null while fields are cached (relations tree, admin:cache, model boot). The administrator read in another way (auth()->user(), request()->user()) is not detected.

Administration scoped parameters

Applies the parameter only in the administration, e.g. a field required in the admin form but optional in your frontend form validated by Model::validator().
String notation accepts one parameter, use the array notation for more:
Parameters written directly on the field, and the default rules of the type like max:255 for strings, win over inAdmin parameters. Like permissions, inAdmin is applied only for the authenticated administrator, it does not change the database schema.