Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] The page/list command only shows you pages you have sent #3528

Open
chiizujin opened this issue May 1, 2024 · 2 comments · May be fixed by #3529
Open

[BUG] The page/list command only shows you pages you have sent #3528

chiizujin opened this issue May 1, 2024 · 2 comments · May be fixed by #3529
Labels
bug An actual error or unwanted behavior. needs-triage Yet to be looked at and verified as an a real issue/feature that could be worked on

Comments

@chiizujin
Copy link
Contributor

Describe the bug

The page[/list] command only show pages you have sent (or sent to yourself), not those you have received.

Pages on Jazri account:

15:06:24 to Chiizujin:> test
15:11:38 to Chiizujin:> another test
15:23:17 to Jazri:> self test
15:23:17 from Jazri:< self test

The Msg is being created with only the sender (and Admin) having read permissions, not all of the receivers:

locks=(
    f"read:id({caller.id}) or perm(Admin);"
    f"delete:id({caller.id}) or perm(Admin);"
    f"edit:id({caller.id}) or perm(Admin)"
),

Which means that they get filtered out here in the page command:
pages_we_got = [msg for msg in pages_we_got if msg.access(caller, "read", default=True)]

I'm fine with fixing this but I just want to make sure this isn't the intended behaviour first, though I suspect this isn't intended because of:

rstrings.append(
    f"{received[-1]} is offline. They will see your message "
    "if they list their pages later."
)

Expected behavior

I expect (possibly mistakenly) that page should show pages I have received as well as those I have sent.

@chiizujin chiizujin added bug An actual error or unwanted behavior. needs-triage Yet to be looked at and verified as an a real issue/feature that could be worked on labels May 1, 2024
@InspectorCaracal
Copy link
Contributor

The page system had previously completely ignored the locks system, so I think this is most likely just an oversight when fixing that.

@chiizujin chiizujin linked a pull request May 1, 2024 that will close this issue
@chiizujin
Copy link
Contributor Author

Submitted PR to resolve this (#3529).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An actual error or unwanted behavior. needs-triage Yet to be looked at and verified as an a real issue/feature that could be worked on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants