Consider job permissions in UI #346
Conversation
✅ Deploy Preview for ami-web ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for ami-storybook ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| @@ -14,6 +15,10 @@ export class CaptureDetails extends Capture { | |||
| } | |||
| } | |||
|
|
|||
| get canUpdate(): boolean { | |||
There was a problem hiding this comment.
@mihow I felt a bit weird checking for update permission on capture, we should perhaps check for create permission on jobs? Although I rather avoid fetch a list of jobs, just to get this info.
Let me know if this solutions is fine or if you have thoughts :)
There was a problem hiding this comment.
This is for "Process now" in session detail view
|
Ah yes create job makes more sense!
We are not modifying the capture.
Thank you!
…On Sat, Feb 10, 2024 at 2:07 AM Anna Viklund ***@***.***> wrote:
@annavik <https://github.com/annavik> requested your review on: #346
<#346> Consider job
permissions in UI.
—
Reply to this email directly, view it on GitHub
<#346 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABGTX25FS3KF6PI4GJMWVDYS5BGNAVCNFSM6AAAAABDCSK7G6VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRG43DINJTHE3TOMQ>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
I agree, but thing is I get the "create job" permission when fetching a list of jobs and it doesn't really make sense to do so in this this context... Can we make this permissions available in a different way? We have the same situation for "starred", I would prefer to check update permission for this collection, but I need to fetch extra stuff that is not really needed in order to do so. |
|
Ah okay I will look into making those available.
Is the update permission for the active project currently available?
We can use that permission we can use for multiple features.
Also I might have to prefix all URLs with the current project ID. To help
with query speed and permission checking for private projects. So just a
heads up about that.
On Sun, Feb 11, 2024 at 4:29 AM Anna Viklund ***@***.***>
wrote:
… Ah yes create job makes more sense! We are not modifying the capture.
Thank you!
… <#m_-6256968134272742576_>
On Sat, Feb 10, 2024 at 2:07 AM Anna Viklund *@*.*> wrote: @annavik
<https://github.com/annavik> https://github.com/annavik
<https://github.com/annavik> requested your review on: #346
<#346> <#346
<#346>> Consider job
permissions in UI. — Reply to this email directly, view it on GitHub <#346
(comment)
<#346 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABGTX25FS3KF6PI4GJMWVDYS5BGNAVCNFSM6AAAAABDCSK7G6VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRG43DINJTHE3TOMQ
<https://github.com/notifications/unsubscribe-auth/AABGTX25FS3KF6PI4GJMWVDYS5BGNAVCNFSM6AAAAABDCSK7G6VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRG43DINJTHE3TOMQ>
. You are receiving this because your review was requested.Message ID: @.*
>
I agree, but thing is I get the "create job" permission when fetching a
list of jobs and it doesn't really make sense to do so in this this
context... Can we make this permissions available in a different way? We
have the same situation for "starred", I would prefer to check update
permission for this collection, but I need to fetch extra stuff that is not
really needed in order to do so.
—
Reply to this email directly, view it on GitHub
<#346 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABGTX5RECE7Q2W3BA5JX6DYTC2TLAVCNFSM6AAAAABDCSK7G6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXGY4DKOBRHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Yes, that we can absolutely do! Project details we fetch from a wrapper component and all the child components can access this data without us having to do a new fetch. PR is updated to check project permissions for "star" and "process now" :) In future, for more detailed permissions, I wonder if it would make sense to put them on the user object? |
Fixes #328
Also added some info in UI about what is going on: