Customisable timestamp fields

To ease migration the project I’m working on uses created and modified field names instead of created_at and modified_at fields.

In PanelTraits/Autoset.php getDbColumnNames, the fields are hard coded as created_at and modified_at:

return array_values(array_diff($columns, [$this->model->getKeyName(), 'created_at', 'updated_at', 'deleted_at']));

This can be changed to:

return array_values(array_diff($columns, [$this->model->getKeyName(), $this->model::CREATED_AT, $this->model::UPDATED_AT, 'deleted_at']));

This will allow users to define their own timestamp fields, rather than assuming the defaults which may not be the case

[tabacitu]

😃) well this got a little steamy. Guys, please, relax. We all want the same thing here - Backpack to be as useful as possible, for all of us. It’s normal to have different opinions, but in the end - we want the same thing.

@indra1 - in this case I think @Spodnet is right.

@Spodnet - I wasn’t aware of those constants - I never used different column names for created_at and updated_at in Laravel. But if Laravel supports changing them, so should Backpack, I agree. And it’s such a simple change, and backwards-compatible. No reason not to do it. It’s done, just pushed it on the dev branch. It will be available in the next patch release (today or tomorrow), bundled with other backward-compatible updates.

Cheers!

[Spodnet]

It’s a 15 second change, to keep within the eloquent standard, the standard method for finding what those fields are named, should be to call the methods or use the constant much the same as you do for primary key name, otherwise why not hard code ‘id’ which by your argument is “standard”

The next developer or other developers in the team, can quite easily see the const definition in the models (all several hundred of them) at the top of the model class, and they can refer to the documentation for the project, so wouldn’t spend hours looking at code.

A crud library needs to be as flexible as possible, I see this as an improvement by keeping to standard methods, and would not cause unexpected issues if another user comes along using different field names for whatever reason.