Adding createdon/createdby/publishedby/etc. to settings

[pepebe]

This has been a frequent topic for a while.

• Add publishedby as a Standard Field / https://github.com/modxcms/revolution/issues/11299
• createdby Select Field in Standard Resource Type / https://github.com/modxcms/revolution/issues/11766
• Add publishedby / createdby to Form Customization / https://github.com/modxcms/revolution/issues/7553

I think createdon/createdby and publishedby should be added to the right side of the resource settings tab

Adding these fields is quite easy. Its just a few lines in https://github.com/modxcms/revolution/blob/14a60cc7d68c7b833cb97dd4c895dd77ccc12fd6/manager/assets/modext/widgets/resource/modx.panel.resource.js

The only question left is if there should be permissions available regulating if these fields are hidden,readonly or editable (might be overkill).

Cheers,

pepebe

[pepebe]

Update: It seem that changes to publishedby are overwritten by https://github.com/modxcms/revolution/blob/14a60cc7d68c7b833cb97dd4c895dd77ccc12fd6/core/model/modx/processors/resource/update.class.php. Got to fix that too.

[jaygilmore]

The argument against this is that these fields might be reserved as audit data. I.e. if people can change this data with the content there would no longer be authoritative information about the content. People could just change it whenever they'd like. This would be very important to have uneditable authoritative data about content where workflow was introduced. Though one could argue that you could use permissions to prevent those with lower authority from changing it.

Specifically what problem are you seeking to overcome? Is this about the values that get presented in the content views and wanting to make sure it can be altered for the purpose of presentation?

[pepebe]

Some examples:

• When you move legacy content from a new project into a modx project, createdby and createdon most likely have to be edited.
• publishedon is a bad choice for blog-like content because it will change the time context whenever a resource is unpublished. Createdon on the other hand is much better suited for this, because it will only change its value if it is specifically changed by the editor of a resource. Anyone who ever accidentally unpublished a resource and had a hard time to recover that date will surely agree.
• createdby is an important field for blog-like resources, especially when you are working in a team. For this reason it is editable in Articles.

Its difficult for me to see how these fields are useful for auditing data. They only tells us when and by whom a resource was created. They don't give any information about the content.

If it is necessary to define an "owner" of a resource or to store a history of changes to a resource, both fields don't meet the necessary requirements. This has to be covered by a plugin.

I guess there will be use cases, where those fields are off-limits. In this case they could be hidden from view by form customization and a clever formulated constrain (not sure about this).

[jaygilmore]

I don't think we should be using the createdby field (the user who created the resource) for the content author (the person to whom the content is attributed). I know this seems to be the common use and is the default way that Articles works but I personally think it's bad practice. IMO, the person who created a Resource should be part of the Resource record and most certainly may not be the person who authored the content.

createdon to me is again a historical record of when a resource was created within the context of the application. When time based content is published is metadata of the content not metadata of the Resource and therefore, I think it's again suited as a TV and can inherit the value of publishedon/created on if empty.

I will say, in your defense that Resource and content metadata are intermingled in MODX quite badly and therefore, your desire to use the fields in this way makes sense. I am not going to argue against them being editable so long as there are permissions attributes associated that can allow policies to prevent users from altering the fields.

I will also say that we're using these fields exactly as you suggest on modx.com for the blog. I don't agree with it but it's not harmful usage if you know what you're doing. I just would prefer a different approach.

[rtripault]

I'll follow Jay on that one (while understanding the need). If those fields become editable as default, i would have to hide those on most (if not every) project (but i see other doing the opposite, and requiring those fields as editable on most/every project) :smile:

[joeaugie]

I understand the desire to have those, but I have to agree with Jay that what you are after are best handled as TVs. It's a bit too presumptious, as Jay mentioned, to equate createdon with an original publish date and createdby as an author.

"I will say, in your defense that Resource and content metadata are intermingled in MODX quite badly and therefore, your desire to use the fields in this way makes sense."

I also agree with the statement above as well. So for now, a creative solution utilizing TVs might be best, but perhaps the type of thing you are looking for might eventually best be handled as an extra/snippet, which can store information such as "original publish date", "author", etc.

It's tricky business trying to separate all this out, but I don't think adding those fields to the settings tab makes things any easier. What might make sense to you, may also confuse others and it does begin to bloat things a bit.

Great topic though.

[pepebe]

A big thank you to all people involved in this discussion.

As this topic pops up every once in a while I thought it would be good to have a collection of arguments for and against including those values.

I don't totally agree with all the points stated above, but I can see that making those fields editable by default might be causing more trouble for some people than its worth.

What I've learned from this thread is that there is an important gap that has to be filled.

For most resources, we need reliable information about the author and the "authored" date.

Both variables are important criteria for queries:

• All posts by author XXX
• All posts "authored" in 2015 or June 2015, etc.

Lets have a look what we already have to work with.

createdon/createdby

• These fields only tell us something about the date a resource was created and the name of the user that added it to the database. For obvious reasons this is not giving us any reliable information about the author or the temporal context of the resource. Some of us see this field as important meta data, that should not be editable.

publishedon/publishedby

• Its just information related to the user/date the moment a resource was published. In most cases these values don't tell us anything about the author of a resource or its temporal context.

editedby/editedon

• useful to find out who was the last person messing with a resource. For this use case it does what it is supposed to do. If its not important to know about this, this field is a good candidate for "abuse" (see below).

Conclusion

None of the variables above can give us reliable information about the author of a resource or its temporal context.

Available solutions

Right now we have to make a choice between different kinds of evil. We either:

• use TVs to store this information and use them for queries (slower).
• use TVs to enter this information an copy it onDocFormSave into one of the regular content fields and use those for queries instead (faster).
• use/create a new resourceType better suited to our needs (Articles, etc).

There are pros and cons for all of these solutions.

I believe we shouldn't have to make this choice in the first place. There should be a standard way to solve this problem.

So how would you solve this?

[rthrash]

Great summary, thank you!

There is the option of having an additional author/content-date added to the model. Not saying it's the best, but it is an option. Perhaps another Resource type for this purpose (modArticle)?

[OptimusCrime]

Can this be closed as a "good idea, but use an extra for this"? @rthrash @pepebe

[devlanda]

For the user experience I think there should be a field to change the author of a Resource. Maybe it can be hidden by default, so in case of audit-reasons it will be no problem. Make the fields only visible if the System Settings does allow it.

In case of a service-contract where a client needs help to post a blog article. In the current situation it is inconvenient to change the the author from e.g. admin to clients' name.

Maybe not the best example.. but WordPress users can do that by default.

[rtripault]

Still against this idea since i almost never had the use of this.

But since i had the need for it lately, here is a sample plugin, in case that could be useful to anyone : https://gist.github.com/rtripault/7306c8487a39fd1ce0db5f334c99be57

[pepebe]

@rtripault Thanks for sharing your plugin. Nice piece of code! Its great how easy it is to tweak the manager if you know what you are doing.

To everyone else:

It would be great to get some solid arguments against this idea.

Whats so bad about adding these fields to the settings page and wrapping them up with some solid permissons?

• edit_createdby
• edit_createdon
• edit_publishedby

It could be on by default for Administrators and off for everybody else.

It would be very helpful at the beginning of most migrations and even afterwards, there are so many use cases.

[pepebe]

For anyone who wants to add createdon and createdby to the settings tab, here is a solution with customizable date/time format:

https://gist.github.com/pepebe/20a6b971892a4071be80410b42f2d369

[matdave]

additionally, if you use right.insert(0,{... instead of right.add({.. you can control the position where 0 represents the order. (I didn't like it at the bottom!)

[alroniks]

In 3.x fields order was changed and providing this feature for 2.x does not make sense because it will cause issues during the merging. So I tagged it for 3.x version.

[rthrash]

This issue has been mentioned on MODX Community. There might be relevant details there:

https://community.modx.com/t/modx-2-8-4-cmp-resource-form-how-to-show-createdby-info/6167/2

[modxcommunity]

This issue has been mentioned on MODX Community. There might be relevant details there:

https://community.modx.com/t/user-name-not-shown-publishedby-userinfo-fullname/6852/18