Remove LastEdited from summary fields
Closed this issue · 7 comments
I am seeing this in the summary fields:
I would recommend to change "Created" to "Created.Ago", add LastEdited and Created as readonly fields in the getCMSFields for the individual records and then show any Email and "Name" fields in the summary fields by default.
I would recommend to change "Created" to "Created.Ago",
I would rather like to propose to drop the LastEdited-column. I don't know when this is different from Created in standard situations? Furthermore I not to keen about the change from Created to Created.Ago... Makes it harder to scan the rows quickly.
Would it be okay to just drop the last-edited column, and make it use the default summary_fields from SubmittedForm (instead of the hard-coded fields)? Then we both would be able to change it to your desired behavior via _config.php
SubmittedForm::config()->update('summary_fields', ['ID'=>'ID', 'Created.Ago'=>'Created']);
add LastEdited and Created as readonly fields in the getCMSFields for the individual records
Good point, but again: in what scenario the edit-date differs from the created-date?
show any Email and "Name" fields in the summary fields by default
Not to keen about this part either. It is already configurable via the CMS interface, it would become more inpreditable if Email-fields and Text-fields with the label name would automatically appear in the overview. Although this is what makes the overview usable, I don't see how we could automate this.
Awesome replies!
I would rather like to propose to drop the LastEdited-column. I don't know when this is different from Created in standard situations?
DEFINITELY, remove last edited altogether.
Furthermore I not to keen about the change from Created to Created.Ago... Makes it harder to scan the rows quickly.
Agreed, but it should be a human readable form. @baukezwaan - the way you read these things as a developer is not the same as people read it in everyday life I feel. For example, we should remove the seconds. Ideally the format should follow the localisation set for the CMS Editor and be something like this for NZ:
15:23 - 12 Dec 2033
show any Email and "Name" fields in the summary fields by default
The point is that without a unique identifier the data is basically useless, why don't we, by default, just show the first email field. You can, of course, remove it as per the standard customisation options that we have in the CMS now. We just set the "show in summary" to TRUE for email fields. Or something like this.
The reason I recommend this is that this is that both developers and users do not realise that you can set this (where you set it is not the same place as where you see it).
What do you think?
Agreed, but it should be a human readable form.
That's a good idea. I've changed it in the PR to Created.Nice
The point is that without a unique identifier the data is basically useless, why don't we, by default, just show the first email field. You can, of course, remove it as per the standard customisation options that we have in the CMS now. We just set the "show in summary" to TRUE for email fields. Or something like this. The reason I recommend this is that this is that both developers and users do not realise that you can set this (where you set it is not the same place as where you see it).
In 90% of the scenario's we (the developers) are the ones setting up the initial form. But you are totally right, since it is called UserForms, the client should also be able to easily set up a new form. Plus get sane defaults to get a comprehendable overview of submissions.
I've updated the pull request, fingers crossed 🤞
Hmm... that doesn't seem to work ,with the way now fields are added.
private static $defaults only is triggered for new records. But a formfield is always added via the gridfield as a EditableTextField, and created in the database. In the next step this is changed to the approriate field (EditableEmailField in this case), but the populateDefaults() is no longer triggered, since the record already exists.
I've moved the logic to onAfterWrite on the EditableTextField, since that is the default field which is created.
In 90% of the scenario's
How do you know that. I think the whole idea is that the content editor can do it.
I've moved the logic to onAfterWrite on the EditableTextField, since that is the default field which is created.
I would do that on write for the EditableForm, not the fields. Check if the form has a UID field in the summary fields and if not, add one.
In 90% of the scenario's
How do you know that. I think the whole idea is that the content editor can do it.
True, they cán. But in our experience the agency sets it up most of the times, and the editor changes minor details such as thankyou-texts. But I totally agree on having an Email-field in the summary, either way.
I would do that on write for the EditableForm, not the fields. Check if the form has a UID field in the summary fields and if not, add one.
Nice approach. But how would you define a UID field? Any field that is shown-in-summary, or only e-mailfields?
Downside is the you take away te possibility to not have fields in the summary. Since we would force it to have at least one.
In the current approach it is only set as a default, and can be turned off if desired.