Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
BooleanItem is used for User->status, Node->published, etc.
However when creating a sample version, it is usually expected that the user not be blocked, that the node be published, etc.
Yet other Boolean fields should still be truly random in their samples.
Proposed resolution
Create a dedicated field type for 'status'.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#4 | 2936864-status-4.patch | 2.16 KB | tim.plunkett |
Comments
Comment #2
Wim LeersDid you mean
@DataType=status
?Comment #3
tim.plunkettNo, I mean
@FieldType
.Alongside
\Drupal\Core\Field\Plugin\Field\FieldType\BooleanItem
Because we specifically want to implement
\Drupal\Core\Field\FieldItemInterface::generateSampleValue()
Comment #4
tim.plunkettSomething like this
Comment #6
Wim LeersOkay.
status
is a very generic name. I don't think theuser
module should claim this. Either it should live outsideuser
module, or it should beuser_status
, to allow contrib/custom and future core to provide a more generic@FieldType=status
Other than that, looks fine :)
Comment #14
joachim CreditAttribution: joachim at Factorial GmbH commented> I don't think the user module should claim this. Either it should live outside user module
That already seems to be the case in the latest patch.
1.
Aren't we going to need some sort of an entity update to change the type of a field?
2.
Other entity types which do
setClass(StatusItem::class);
need updating too -- e.g. Taxonomy term.Comment #18
petiar CreditAttribution: petiar as a volunteer and at Petiar.sk commentedWithin the #2945954: Split “blocked” status into “pending” and “locked-out” it is requested to split the Blocked user status into the Locked out and Pending, so we know exactly why is the user blocked. However, for this purpose the status field type plugin as proposed here would not be sufficient because of it's boolean base. Is it alright if I implement new field type plugin (
user_status
, as suggested above in this thread) for the User entity or was there an intention to create a status field type plugin which would be applicable for any entity type?