🚀 Feature: $createdBy and updatedBy

[prooshani]

🔖 Feature description

Hope to see more additional info about database Documents like what you already did ($createdAt, $updatedAt).

It is much appreciated to have the extra info about the user/team which created or updated a document for further investigations and I think it is good to have this info besides dates of creation and update.

Thanks everyone participating this wonderful repo.

🎤 Pitch

I have a lot of users and teams entering data into the database collections and need to show extra info for these database rows for admins and/or the end-user to help them find which data collected/edited by which team/user. Therefore, having information about creator and updater would help me a lot!
$createdBy
$lastUpdatedBy

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[stnguyen90]

@prooshani, thank you for raising this issue! 🙏. Since adding a system createdBy attribute wouldn't be helpful in every use case/collection, this might be better tackled using an Appwrite Function. The function can execute on document creation and set a createdBy attribute to the user. You may also limit editing on the document, use a separate document to store the read only attributes, or expose editing only via functions so that the user can't edit the attribute.

Closing for now since Appwrite Function would be the best way to handle this.

[prooshani]

Not agree.
Your resolution is kinda inappropriate and not professional.
system/User level information should be supplied by the server and keeping this extra info inside tables increases the size and decrease the security/reliability of the database.

In addition, it looks funny that having createdAt and updatedAt attributes are OK and should be supplied by the server-side BUT, knowing who created and who updated (userID) is NOT OK at the same time!

I am already doing this inside my tables using extra attributes while using server-side attributes could save me (and maybe many others) a lot of time and reduces the inaccuracy and number of lines of code.

Thanks and NO, I think you should not close this issue this fast without even a reasonable answer. To be honest, I know your team may have higher priorities right now but, your answer is just a shrugging the shoulder.

All yours,
Hamed

[stnguyen90]

@prooshani, I'm sorry you feel that way. I'll re-open this issue to let others comment and upvote as needed.

[eldadfux]

When adding $createdAt and $updatedAt we had a similar discussion around how much should we abstract and how much we shouldn't. It is impossible for us to draw the right line for what would fit all use cases and what just for some. Obviously more attributes might be required and requested, but how many can we support?

I think the best approach for now is to use Cloud Functions, to update the relevant attribute and enforce data integrity on document create and update events. in the future, I strongly believe server side vars that will allow you to use server data like time, user info and other metadata would be the best balance between flexibility and good abstraction for most use cases.

Would love to hear more feedback, especially more ideas on what can be a good formula for knowing how to strike the right balance here.

[prooshani]

When adding $createdAt and $updatedAt we had a similar discussion around how much should we abstract and how much we shouldn't. It is impossible for us to draw the right line for what would fit all use cases and what just for some. Obviously more attributes might be required and requested, but how many can we support?

I think the best approach for now is to use Cloud Functions, to update the relevant attribute and enforce data integrity on document create and update events. in the future, I strongly believe server side vars that will allow you to use server data like time, user info and other metadata would be the best balance between flexibility and good abstraction for most use cases.

Would love to hear more feedback, especially more ideas on what can be a good formula for knowing how to strike the right balance here.

You are right Eldad,
It is difficult to manage how many metadata the server should return upon the end-user's requests at the moment.
In my perspective, you have very specific rules about the user's permission to read/write (it is mandatory to specify the permission to read/write a document/collection). Therefore, having these info about WHO created/updated a document/collection would not be very far from the philosophy of the server's responding metadata.
In addition, your justification for limiting the metadata attached to the returned server's responses is the frequency of the day usage and use cases but, who can precisely determine which metadata or attribute would be used by the developers and applications in the long run? It looks not very straight forward to limit the attributes by the demands because no one can claim that every body would/should use very restricted attributes at this stage! This may also become a bottleneck of the project later on.

Therefore, in my opinion, returning a proper feedback from who/when a collection/document created is not violating your limitation rules.

As I told before, at the moment I am doing this manually but, I am trying to participate and improve this precious project by declaring my experience and demands from the project.

Thanks again to all of you.

[eldadfux]

Appwrite also maintains audit logs for most of the write events in the server. I wonder if it would be beneficial for your use case if we would have exposed this logs with an API instead of adding this as metadata.

[yaakov123]

This is, in my opinion, a pretty basic feature request. Currently, the recommended way to create documents is by using the SDK. The issue is, that it's considered very bad practice to allow a client to add "sensitive" information to a document. In my case, I'd like to create a messaging app where each message has a "user_id" property which I use to determine whether or not the current user is the person who sent the message. In order to accomplish this, I can do one of two things.

1. To add the message.user_id property on the client using the SDK (this is not great since the client could modify the request to make it seem as if they didn't send the message)
2. Create a function which accepts the message contents and adds the user_id property in the backend.

Option 2 is very clunky and it kind of defeats the purpose of having an SDK in the first place since it's essentially requiring me to create a CREATE endpoint for my messages.

It seems to me, that just like Appwrite functions have metadata about who triggered them (the user_id), each document should also have the additional metadata.

[netapy]

Have any decisions been taken on this feature ?
Functions are not a reliable option in my case (#4626) so this would be very useful.
It's an essential feature imo.

[slysiou]

Hi,

I just discover this discussion and I agree. It is essential need to be able to know who is doing what.
And this must be also added to activity tab, logs...

I am also looking for an option to keep tracking of the document change in a collection.
#4901

Update:
In Function, on event "create" for a document, APPWRITE_FUNCTION_USER_ID is empty.
So, I don't see any solution to find and store the author of a change.

[eldadfux]

Hi,

I just discover this discussion and I agree. It is essential need to be able to know who is doing what. And this must be also added to activity tab, logs...

I am also looking for an option to keep tracking of the document change in a collection. #4901

Update: In Function, on event "create" for a document, APPWRITE_FUNCTION_USER_ID is empty. So, I don't see any solution to find and store the author of a change.

We do have an internal activity API that might become public if we see demand for it.

[Meldiron]

I personally built multiple demo apps where I needed to create a public profile for each user that registers. I always did it in Appwrite Function to make sure the user cannot create profile for userId that is not him.

Having $createdBy could solve my issue as then I could find a profile for specific user by using this attribute. Problem tho would be that it would be listDocuments query which performs much worse than getDocument. What I usually do with function to create profile is to give profile document custom ID that is exactly the same as user ID. That way if I want to get profile of user abcd, I can just get document from profiles collection with ID abcd.

So for me the way how such attribute would be used is a bit concerning.

[Meldiron]

Hi,

I just discover this discussion and I agree. It is essential need to be able to know who is doing what. And this must be also added to activity tab, logs...

I am also looking for an option to keep tracking of the document change in a collection. #4901

Update: In Function, on event "create" for a document, APPWRITE_FUNCTION_USER_ID is empty. So, I don't see any solution to find and store the author of a change.

Hmm can you double-check if APPWRITE_FUNCTION_USER_ID is still missing? If so, I wold say that is a bug. I remember relaying on USER_ID when validating document creation in my function. What you wrote sounds like a great solution that I would even suggest.

[netapy]

I personally built multiple demo apps where I needed to create a public profile for each user that registers. I always did it in Appwrite Function to make sure the user cannot create profile for userId that is not him.

Having $createdBy could solve my issue as then I could find a profile for specific user by using this attribute. Problem tho would be that it would be listDocuments query which performs much worse than getDocument. What I usually do with function to create profile is to give profile document custom ID that is exactly the same as user ID. That way if I want to get profile of user abcd, I can just get document from profiles collection with ID abcd.

So for me the way how such attribute would be used is a bit concerning.

Your solution is good for a "public profile" table and the Appwrite function is in fact the best way to create profile lines. (I also implemented that in my project)

But the request for a $createdBy attribute concerns documents produced by the user -- not his profile.

If the users posts pictures, you'd want to easily query all the user's pictures on his profile, without anyone being able to add their own picture by editing the custom "owner" attribute in the request.

Appwrite makes it hard to develop a secure environment as soon as the project involves public document creation.

How impactful would that simple attribute be ? It doesn't feel like much 🤔

[pchasco]

I agree that having the option to include these attributes is essential, and the only way for them to be trusted as accurate is if they are populated by Appwrite itself.

[abnegate]

I think a server supported string could work well here, along with a new method in the ID SDK helper. We could support a custom string like "me()" and method ID.me() that is replaced with the current user's ID server side. Then you could have a custom createdBy attribute and safely populate it from client side.

It could also be useful for setting permissions for yourself without a reference to your user object.

Would love any feedback

[ZeroAurora]

I think a server supported string could work well here, along with a new method in the ID SDK helper. We could support a custom string like "me()" and method ID.me() that is replaced with the current user's ID server side. Then you could have a custom createdBy attribute and safely populate it from client side.

It could also be useful for setting permissions for yourself without a reference to your user object.

Would love any feedback

NEVER populate a createdBy from client side, since almost everyone can fake a web request and thus fake others' identity.
Using a server-side interpreted string function won't help. It is, in the end, an HTTP request containing a string that can be easily changed. I can intercept it and change it as if modifying other document objects. For example, I can just change me() to any other user id while the server won't notice any difference.

[moshOntong-IT]

I love the scene when between programmers argue on something. But anyways I totally agree that we should have $createdBy and $updatedBy as internal attributes.

[ZeroAurora]

Perhaps there can be something like an auto-function field? These fields can be computed on-the-fly on document creation/update, just like edge functions but for the document database.

[ggcaponetto]

I would need this too and i think it totally makes sense to have a $createdBy attribute.