Design how and when the users could see and star/like expressions

[NanezX]

There are missing scenarios that we still need to cover related to the visibility of the draft expressions and how the user can interact with them. The main scenarios that have been considered so far with Josh:

• Scenario 1: I have a private expression and I share it with you via a sharable link. You star it. Now, I replace the sharable link (as you described above). So, I don’t want it to appear in your starred expressions anymore either. Scenario 1 is maybe only possible if you starred the sharable slug, not the actual draft_expression id. Because even if I replace the sharable slug, it won’t change the id.

• Scenario 2: I made an expression public and you discovered it in some public feed/community showcase/elsewhere. You starred it. Now, I want to make it private again, so I don’t want it to appear in your starred expressions. Scenario 2 seems easy on its own. You just never return private expressions when a user queries their starred expressions. But it’s more complicated when you consider the above.

• Scenario 3: you share me a private expression via sharable link, i star it. Then you make it public. THEN, you replace the sharable link. So even though I starred it via sharable link and that link doesn’t exist anymore, I should still have it starred because now it’s public anyway.

Probably there’s other scenarios that are a mix of all of the above.

[NanezX]

For now, I have thought of adding a new column on the draft_expressions table that work as a flag isShareable. We can combine this flag with the public flag to make the above work.

• In scenario 1: The User1 shared a private expression toi an User2 via link. This turn to true the isShareable flag in DB and the public flag still false . The User2 start it and saved the reference to starred table changing the constraint to only allow to insert if isShareable or public are true. The User2 will be able to query/get his draft expressions starred if they are public OR if they are private AND shareables. Later, when the User1 does not want to shared the expression anymore, he change the isShareable flag to false. The expression become non shareable and non public, so is not retrieve it again.

• In scenario 2: The User1 have a draft expression that is public and the User2 star it, so we can star it normally. But if later the User1 make it privated, ther User2 will not be able to get this starred expression since is non-public. This does not have issue with the above if I'm not wrong.

• In scenario 3: User1 shared a privated draft expression via link, the User2 star it. Up to this point, same as scenario 1, turn to true the isShareable flag in DB and the public flag still false. The User2 can get this starred expression since is shareable. If later the User1 make it public, then User2 is still able to get this starred expression.

With this way we don't need to change the sharable_slug, at least we want to completely delete the starred from an expression when we change the isShareable flag.

It should be noted that this flag could work to valid/invalid already generated links. If the isShareable is true, the data should not be retrieve on the server side in the app.

[NanezX]

Also I need to know, PostgresSQL relationships with foreign keys are not updated if we update any ID to which they are related?

Or being clear, even if we change the shareable_slug, the default constraint when we use this uuid like foreign key in starred table is update the relation too.

I'm really sure that work something like this. If I am right, then we can also use this to our favour to generate/invalid old shareable links