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?
