So I am just getting started with wix code but one of the things I am running into involves the owner value. So I have laid out the scenario below and what I believe to be my options for solutions (honestly don’t care which one works as long as one can work), but don’t know if they are possible or how to accomplish them.
I want to add data to a collection on the behalf of my memebers, ie it is a list of items they have sent to us. I don’t want them to have to add this data as the number of items could be in the hundreds (very time consuming for them and a lot of the data that needs to be added needs to be of a certain nomenclature). However, if I add the data to the database myself using the database app, all the data is tied to me as the owner which means I can’t easily filter the dataset on a member only page to only show data for the logged in user.
Is there a way to change the owner value or manually set the value when say submitting a form even if I am logged in as myself?
Or is there a way to filter the data in a query using something like the logged in users email (which as far as I can tell wouldn’t be hard to make a unique value in one of my collections)?
Came up with a potential 3rd solution
3) Have access to the members collection (assuming one exists when using the built in members section) which would allow me to filter my list on a members dataset where I could put my unique identifier all in the members collection or create a memebers section from scratch (in which case I would be curious about how to approach this since wix recently added the members section app).
I have this same issue. I really want to just update the database monthly from a csv file, but as soon as I upload it, I become the owner and now noone can see their own personal data. Did you figure out a solution by chance?
The 2nd option would be the best one for you.
If I understand correctly, you’ll have the email of the users next to every item in the collection.
So now you need to understand, when a user gets to the site, who’s the user.
You should allow them registration to the site (so they will be members). Then, use ’ wix-users ’ API to get the current logged in users email and filter the data by code.
I’m facing the same issue here, and I’m using 2nd solution as well. However, this is still not ideal as I had to loosen the read permission on my database collection, from ‘Site member author’ to ‘Site member’ (and since new members are auto-approved, this might as well be ‘Anyone’). This removes the guarantee that no visitor of my site can read other visitor’s data, which makes me a bit uncomfortable.
Also, if some user would change their e-mail address, the 2nd solution would fail.
So, I would rather as an admin be able to manually change the ‘Owner’ field, but this field is read-only. Can you tell me the reason why it is read-only, and if there is really no way of changing it?
I am facing the same issue. I was about to buy the wix premium for my business untilI found this problem.
My business relies on limited contracts with my customers, so I cannot let them store as many entries as they want because those are paid separately. I need to let them see only the items that they paid for, but I can’t let them see the items of other customers to avoid sensitive data to be leaked.
Everything goes right until I set the dynamic dataset to filter by “logged in user”, because it filters the repeater using the owner ID of the database and I am the only person who created theitem, so they all will see everything because the ID is always the same no matter what.
I really need to filter the repeaters to show ONLY the items of the currently logged in member. I should be able to assign the owne ID at my will.
Summerset, it´s clear what you are trying to achieve. But unless I am very much mistaken, Wix is not going to offer this possibility. Main reason is, that want you want can already be done, just like Liram said. But … you have to code a bit. It´s called “Wix Code” after all, not Wix Click-and-Run. With this, I mean that no environment can foresee every possible use case that is out there. I have been in this business for decades and I have seen many “environments” pop up that promised easy, full fledged development possibilities. But if you really want/wanted something for your business … you have/had to code.
If you want just a little bit more than run-off-the-mill stuff, you will have to develop some code. Wix offers this possibility, so they have little reason to implement your requested change.
Like Liram said, you need to record a client ref per item (like email address, or his _id) in a 1-n relationship with a user collection. And then, in a repeater, you filter on that particular user. Protecting a row from unauthorized access can be done also: you just check if the current user is the user in the requested row and done, BUt, again, it takes a bit a coding.
If you are not willing to spend the time on learning how to do this, you could hire somebody to do it for you (no, I am not available, I am trying to help you, that´s all).
So in short, Wix offer pretty advanced possibilities for developing working apps, but the “click-and-run” paradigm simply has its limitations.
Hope I made some sense.
Our point is that it is safer and more convenient to use the existing Wix access control functionality, instead of every user that encounters this use case having to implement their own on top of it. That is why we are curious about the design choice of making the Owner ID a locked field.
Maybe there is a security reason for this design choice that we are unaware of? If there is no such reason however, it makes sense to remove this restriction. In the mean time, one could definitely use your approach to get around this restriction.
Thanks for taking some time to reply. I appreciate.
Well, I totally understand. I coded it and is working fine. I set the email address to filter the dataset and works. The only concern is that even if I used the “.onReady” statement, the published site shows the whole information for a while and then the filtered version.
Ah ok, I think this can be prevented by using the wix-router stuff: this will filter out the data on the server, before it is even send to the user. Then, the data that the user has no access to never leaves the server (and never reaches his computer).
In fact, it is pretty critical to do this, because even if the sensitive data is there on screen for just a millisecond, anyone with some technical skill can retrieve it very easily because it was in his browser at some point! Just because you don’t see it on the page, doesn’t mean it isn’t somewhere on the computer…
@hbierlee About that full display and then the correct one: do you have a dataset that is both attached to the result by the (graphical) property settings of the dataset AND in code? It happened to me to in the beginning and when I disconnected the screen result from the interface part and did everything in code, then result became reliable. To me it looked like first the query from the dataset´s properties was executed (displaying unwanted results) and directly after that the one in code, displaying the correct query result.
Did I make myself clear? If not, let me know.
The important part is that this code is only ever run on the server side. So the filtering is done before the data is send to the user. If the filter is in a script that runs on some page instead, someone could just disable or tweak the script, and then they will get all your data, unfiltered.
This is why the Owner ID plus the ‘Site member author’ access rule is so safe: it’s impossible to screw up, because users only ever get access to their own data, everything else gets filtered out before it even leaves the database. However, in some cases, wix code users are forced to use less secure rules because the Owner ID field is frozen.
@weiss0789 This has been my observation as well. The data appears on screen then in about 2-3 seconds finally filters. for example if i have a format to the date i want shown, the original fomatting shows first then in about 2 seconds converts to the new formatting. Same thing with limiting records in the list. The whole list shows…then filters. The process shown to customer is not very professional looking. Is there something we are missing. I too am filtering at the .onready.
There is a better solution that allows you to set the real _owner field of the record.
Indeed, you can’t set the owner field when you call insert or update. However, you can do that when you use data hooks. Data hooks are functions that are being called before or after doing some action with your collection. To add one click the “Hooks” button in the toolbar in your content manager view (the db itself).
A file named data.js will be created. Add a function like this:
export function CollectionName_beforeInsert(item, context) {
if (item.owner_override) {
item._owner = item.owner_override;
delete item.owner_override;
}
return item;
}
In the code that you insert the data just make sure to include a field named owner_override with the id that you want to have as owner. You don’t have to have this field in your collection’s schema.
Very nice and elegant solution! This should already take care of most use cases.
Is it also possible to change the _owner field in an update hook? Because if that’s possible, then we can just add owner_override to the schema and then anyone can update the _owner field via the db data editor page.
I understand the logic that matching to Owner provides in securing changes to be only by the person who submitted the initial data. But another option for filtering the data collection would be to match the logged in user’s email address to an email address in the data collection. This would solve the problem of our data collections being imported via CSV and then allowing a member to submit updates to the information (with read/write capability). This would allow us to easily extend member information to our custom fields.
We have a lot of fields already populated in our FileMaker database that have been imported via CSV into Wix that we want our members to be able to keep up to date, but we don’t want them to have to manually enter all of these fields when they become members of the new website. We already have their data and are trying to minimize the change that our new website is already imposing.
I will need to get help to implement the hooks approach in the meantime with our designer or a Wix developer, but if any Wix product managers are monitoring this forum, my suggestion would make a great product enhancement.
I understand the logic that matching to Owner provides in securing changes to be only by the person who submitted the initial data. But another option for filtering the data collection would be to match the logged in user’s email address to an email address in the data collection. This would solve the problem of our data collections being imported via CSV and then allowing a member to submit updates to the information (with read/write capability). This would allow us to easily extend member information to our custom fields.
We have a lot of fields already populated in our FileMaker database that have been imported via CSV into Wix that we want our members to be able to keep up to date, but we don’t want them to have to manually enter all of these fields when they become members of the new website. We already have their data and are trying to minimize the change that our new website is already imposing.
I will need to get help to implement the hooks approach in the meantime with our designer or a Wix developer, but if any Wix product managers are monitoring this forum, my suggestion would make a great product enhancement.
This would be highly unrecommended unless you fully understand how to secure this flow.
For example, someone might create records with someone else’s email and effectively “injecting” more data to that other user. There are other more complicated-to-explain flows that could break this.
Using the built-in security mechanism ensures that your data stays secure and no user can get to other user’s data
@_dan-1 Thanks for your comments, Dan. I see your point!
Here is the problem I am trying to solve.
We have a backend app in FileMaker with all of our docent data including scheduling docents, reporting their activity, and keeping track of their preferences. We do not want users to update their own information directly for a variety of reasons. The cost to add them, would be prohibitive to our non-profit which operates on membership dues.
Today, we collect their preferences and any demographic changes (address, phone, email) through a printed form they scan and email to us. We print the form with their current information and all they need to do is mark what has changed. This is what we are trying to use the member website for: Let them see their current information, let them submit changes for any of the fields, and then on the backend, we will collect the data and import the changes to FileMaker.
I have tried a number of methods to do this and have been unsuccessful linking a member to a data collection. Since Wix doesn’t allow us to add custom fields to the member data that can be exposed on the website, I resorted to creating a data collection with all of the docent data, including their email address.
We preload their information using the Wix import facility which marks the record’s owner ID with my webmaster owner ID. Which will not allow me to use the Owner filter on the data collection. There are too many fields for us to force our members (many in their late 60’s and 70’s) to enter the initial data themselves.
If there is a better way to allow members to update (or add for new, younger members) their information securely (even if it is with Wix code that we’ll have a developer create), I’d love to hear what we should do instead.
@barb First of all if all of the data collection access is managed using backend code you are in a pretty secure place.
If you are taking responsibility for keeping the docent lists up to date in your data collections based on email addresses this should be fine.
When a user has logged into the Wix Site the backend code, as well as front end code, can determine who is logged in using the wix-users-backend currentUser property and from here you can get their email and manage the data accordingly.
Now each Site Member has a unique ID which is in currentUser.id. When you are working in back end you could do as dan suggests and update the _owner information using this value but you would have to suppress authentication in the wix-data option argument.
This again is safe when done in the back-end so long as front end code can’t execute the back-end code without being signed in and having an Admin role for example.
Now one other thing you can also do, since these are Site Members, is use the email address to get the User Id from the Members - PrivateMemberData collection that is created for you when you add the Members App…
This will give you the User Id to email mapping from the CRM and you can use the ID for the _owner property.
