Hi @TL_Robinson
Let’s take another look at your issue.
You’re asking why the SupporterPostParentID column in the SupporterChat table contains the same value as the ownerId, while you expected it to contain the value from the objectId column.
Since SupporterPostParentID is a plain text column, it simply stores whatever value is assigned to it.
Looking at the logic behind the Submit button on the SupporterChatNewPost page, I found the following:
As you can see, the value being saved into the SupporterPostParentID column is coming from the LoggedInUserobjectId field.
The LoggedInUserobjectId variable, in turn, contains the objectId of the currently logged-in user:
Checking the Users table, we can see that for this user, the objectId and ownerId happen to be the same:
Regards,
Viktor
Thanks for this, Viktor. I’m concerned because it was the exact same for all three tests that I ran. However, I don’t see that in the data set that you sent over.
Per your email, are you claiming to have fixed the issue? If not, how come your results are different than the ones that I have via my screen shot? I want to make sure we move away from false communications and manufactured accurate functionality of your product.
Hello TL,
Let’s try starting from the beginning so we can assist you more effectively.
If recording a video demonstration isn’t possible, could you please describe the steps I can follow to reproduce the issue?
Regards,
Alexander
Alexander, I am tremendously frustrated by the fact that this issue has yet to be resolved, especially since so many of you have been involved. And, I’m even more frustrated by the fact that I’ve had to repeat this issue to so many of you.
The longer this takes the longer it takes me to launch. This very basic defect is negatively impacting my credibility.
Per the images in this thread, the “ownerId” is showing up where I expect the “objectId” to show up in a table column. See the images from Viktor’s message from 3d ago. The first image is the logic on the button on the “submit” button on the “SupporterChatNewPost” page. The second image is the logic on the “Supporter Chat” page. The third image is the data that shows in the “Supporter Chat” table. This table is updated when a person submits on post on the “SupporterChatNewPost” page and is displayed on the “Supporter Chat” page.
As you can see per the logic that I have called the “objectId”; however, the “ownerId” is showing in the “SupporterPostParentID” column of the “SupporterChat” table. This is the error. The “objectId” needs to show in the column.
Tl,
I understand your frustration and we would love nothing more than resolving the issue. However, we have asked multiple times to provide simple steps by step instructions that would help us understand how to reproduce the issue. In order to fix it, we need to understand how to experience it.
Unfortunately, we have yet to receive these instructions from you. They can be as simple as:
- Do this
- Do that
- See the problem here, etc
Or as I asked before, a simple video recording that shows the same steps you followed that resulted in the problem would go a long way for us to help you.
Regards,
Mark
Hi @TL_Robinson
As you can see per the logic that I have called the “objectId”; however, the “ownerId” is showing in the “SupporterPostParentID” column of the “SupporterChat” table. This is the error. The “objectId” needs to show in the column.
We haven’t made any changes on our side because there was no issue to begin with. In this case, the value saved into the SupporterPostParentID column is exactly what your logic sends — specifically, the objectId of the logged-in user.
The fact that, for a particular user, the ownerId and objectId happen to be identical should not be a concern. You can rest assured that the value passed and saved is indeed the objectId.
If you’d like to verify this, you can log in with a user where ownerId and objectId are different, perform the same operation, and observe the value stored.
However, if you believe there is still a bug, please provide clear reproduction steps — for example:
- Log in with a test user whose
ownerId and objectId are different,
- Navigate to [page name],
- Click [button name],
- Check the [table name] table,
- You will see [actual result], while you expect to see [expected result].
This will help us investigate the issue more effectively.
Best regards,
Viktor
Mark, that is incorrect. You have received instructions per your multiple requests. I’ve sent over multiple screen shots and step-by-step actions on how to recreate the issue. Due to compatibility, video isn’t an option. This is why I asked you to have a video conference chat to expedite the resolution, but you were flying. No other opportunity to meet (with anyone else) was provided. The repeated provision of screenshots show the journey and the accompanying verbiage details how to recreate the issue.
This is incorrect. The issue still persists. The columns that you referenced are system generated columns. The issue lays in the “SupporterPostParentID” column, that as of today, still populates with the “ownerId”.
I’ve already provided step by step instructions. This information is provided in my message to you at 22h. Please utilize that information to resolve the issue. If written text does not work for you, provide a link where we can video chat.
Hello @TL_Robinson
Still, we do not fully understand the instructions you provided. Several members of our team have already tried to reproduce and analyze the problem based on your messages, but so far without success.
It is in both your and our interest to solve this issue as soon as possible. Therefore, I will ask you once again to send CLEAR and DETAILED steps to reproduce the problem, using the following format:
- Go to [exact URL or screen]
- Perform [specific action #1]
- Perform [specific action #2]
- Observe [specific unexpected result — what you see, what is wrong]
Please avoid general descriptions or screenshots alone — they do not help us fully understand the flow that leads to the issue.
Once we have this clear step-by-step flow, we will be happy to investigate further and assist.
Regards,
Inna
Inna. If screenshots don’t work for your team, then you’ll need to ease the file acceptance criteria that your company has in place. I’ve attempted to send video files and both have been rejected. If that can’t be done, then the screen shots will have to suffice. To be honest, we’re only talking about one page and the respective backend table where the wrong data is currently housed. So, a video vs. a screenshot won’t make material difference.
Per the issue, it’s simple:
On the SupporterChatNewPost page
- Input test verbiage for the “Title”
- Input test verbiage for the “Post”
- Click the “Submit” button - The logic lives here in the puzzle piece
In the backend table “Supporter Chat”
- Check to confirm that the row exists for the test verbiage that was input per the above steps
- Check the “SupporterPostParentID” column -this is where the error lives - it should match the “objectId” for the same row but it doesn’t.
ASK: Backendless needs to correct the defect that shows the “ownerId” instead of the “objectId” when the “objectId” is called
Hi @TL_Robinson,
Am I understanding correctly that you expect the objectId and SupporterPostParentID fields in the SupporterChat table to be equal?
However, why should the objectId (a unique identifier for a specific post) be equal to the SupporterPostParentID (a unique value associated with the user who created the post) when a new record is created for a post?
Let me know if you’d like any further adjustments.
Regards,
Sergey
Yes, the objectId and SupporterPostParentID should be equal.
I expect them to be equal because I created logic to call the objectId. Since the incorrect information isn’t be called, per the logic, it should be corrected.
Hi, Sergey. Is there any update on this?
Hi @TL_Robinson
Each record in every table has a unique identifier — in our case, this is the objectId column.
In the Users table, every user has their own objectId.
LoggedInUser Variable
In your On Before Page Enter logic, you’re storing all the data for the currently logged-in user into the LoggedInUser variable. This variable contains a map of key-value pairs representing columns from the system Users table — both custom columns (like Profile_UserName, Profile_UserType, etc.) and system columns (including objectId).
At this point, LoggedInUser["objectId"] holds the current user’s unique identifier.
Page Data Assignments
You’re then assigning values from LoggedInUser into Page Data, such as:
LoggedInUserProfile_UserName → holds LoggedInUser["Profile_UserName"]LoggedInUserobjectId → holds LoggedInUser["objectId"] (i.e., the current user’s objectId)
So, by the time we get to the On Click Event, Page Data includes the current user’s objectId under the key LoggedInUserobjectId.
Saving to the SupporterChat Table
In the On Click Event, you’re saving a new record to the SupporterChat table. Among other values, you’re assigning:
SupporterPostParentID = PageData["LoggedInUserobjectId"]
This means the SupporterPostParentID field in the SupporterChat record will contain the current user’s objectId from the Users table.
You’re not assigning a value to the objectId field of the new SupporterChat record — which is perfectly fine. Backendless will automatically generate a unique objectId for that new record.
Summary
Everything is working as expected. There is no bug here.
- You’re correctly referencing the current user’s
objectId.
- You’re saving it as the parent ID in your
SupporterChat record.
- And a new record is being created with its own unique
objectId.
Regards,
Viktor
If the “ownerId” is actually the “objectId” what is the name that I should reference to populate the field with what is actually the “objectId”?
And, Viktorl
I read through your explanation again and looked at the user tables and your explanation doesn’t make sense. The user tables also have an “objectId” and “ownerId” and if my logic pulls from the user table, the outputs don’t match. To be more specific, the “objectId” called from the user table isn’t what’s populating in the “SupporterChat” table. The “ownerId” is what’s populating. So, per your explanation, a defect does exist. Even if the system operates the way that you desire, the inconsistency in naming convention is a defect from the perspective of the end user. Because the wrong information is populating due to inconsistency; this issue doesn’t exist for any other variable.
Hello TL,
I’ve just double-checked and was not able to reproduce the issue you described. It is the objectId — not the ownerId from the Users table — that is being added to SupporterChat as the SupporterPostParentID.
Would you be able to record a short video (for example, using Loom) to visually demonstrate the issue?
That would really help us assist you more effectively.
Regards,
Alexander
Hello, Alexander.
The “ownerId” is populating from the SupprterChat and the “objectId” needs to populate in the “SupporterPostParentID” column.
I have provided step-by-step instructions and screen shots through the chat. Please use them.
My specific ask is that your team check the attribute (and metric) mapping to ensure that each has the correct labeling. I’m sure this is the cause of the wrong data coming through.
Also, my company won’t use Loom per issues with the T&Cs.
Hello @TL_Robinson ,
I’ve added a user named supportUser to your application.
Login credentials: supportUser / supportUser
Please try logging in with this user, run your logic, and check the results you get.
Regards,
Viktor
Hi, Viktor. I’m getting an error message that says the ID you provided is still logged in from another device. So, I created a new ID and ran the test. The issue I originally reported still persists.
And, there is another issue with my app that wasn’t there before. The user name used to show up on each comment and now it doesn’t. Previous chats detail that it was the functionality. Did you change my logic?
The username is pivotal to getting the correct information. Users need to be authenticated and emails confirmed in order for the information to fee into the “survivor chat” table. Without the Profile_UserName functionality working as it previously did, the app is essentially broken and the defect can’t be recreated.
