What I need is a simple app where people can write down a 'diary'. The entries are only visible for the user itself and maybe for a mentor (role).
How would you take that on?
Is there a filter ‘show only own entries’?
Cheers
Tycho
BTW: You can also set content-type permissions so
1. registered users can create new items
2. owners (the people who created it) can also edit the items
This allows for building all kinds of solutions like the one above ;)
I just discovered the Ownerfilter in the querydesigner. And that does exactly what I need.
Related
Stack is symf 5 and EA 3.
I have a problem with showing different data for one AssociationField.
I want to show different values of that field for different roles. Something that query builder do in Symfony forms. Any help?
You probably need to create a switch statement in the CRUD Controller which will render that field differently based on what is the current user role. Remember, that one user can have multiple roles by default, so You need to specify which role index should it take to statement as a parameter.
But the true question is: Do You really need that functionality? If so, You probably should consider giving Your user class additionally a configuration array, where You will store the config of the preferred way for data presentation.
You do not tell much about the background of Your problem, so I hope my answer address it correctly.
In a handful of circumstances, I'd like to allow the Current User to be able view a list of records filtered by Owners of each record that are Direct Reports that they manage or even by the Manager they report to via our global directory.
I'm comfortable making a new Datasource for CurrentUser in a Directory model. However, I'm tripping over myself trying to find the best way to match an Ownership (email) field from a record, with an array of the direct reports associated with the current user.
A specific example would be on the Travel Approval template. The table on the Dashboard page has a filter for "My Requests | All" and I'd love to add a third option for "Direct Report Requests".
My assumption is that I would adjust the onClick event to filter results accordingly:
widget.datasource.query.pageIndex = 1;
widget.datasource.query.filters.Owner._equals = app.user.email;
widget.datasource.query.filters.Owner._in = null;
widget.datasource.load();
updateUrlForDashboard();
That's one small example, but more importantly, I'd like to get a better understanding of how best to reference/store those additional relationships about the Current User.
Ideally, a current user is able to have greater ability to manage (approve/deny/comment on) resources tied to their Direct Reports and generate records that provide a similar level of control to the Users that Manage them.
I'm not sure if that's best handle by some use of Roles or another approach. Any advice on how best to plan out that kind of setup would be much appreciated.
funny thing ... I had the same question a couple of months ago. I think you will find Pavel's solution on this very interesting. You can find it here.
I am implementing something like Facebook posts, but I only want to limit it for users Alice and Bob to see, but John can't see it. May I know what is the proper way to implement this ? I tried googling but all I found is user based authorization, for IIS.
What I had in mind is to implement another table to add allow list, so if the allow list is empty I assume all users' friends are allow to see, but if there are users in the allowed list then only allowed users can see. However I think this might heavily increase the load of my db?
Whenever we assign an Account to a different owner in CRM2013 Online, the timestamps for the notes change, to match the time the account was assigned and who assigned the account. Is it possible to change this, so the timestamp only shows, when the note was created? And show who originally created the note?
I see the logic in the way is works now. It updates to show when it was last changed and who changed it - but I would LOVE to change it, so it would show WHO created the note and WHEN it was created.
Is this a thing you can change in the current iteration of CRM2013?
I don't think that it would be possible. But anyway try to leave your suggestion on Connect.
It's an impact of the Cascade for Assign action on Account.
You can switch off that Cascading from the relationship between Account and Note.
However it's necessary to check if new owner has access to related Notes accordingly to his role permissions.
I am currently building a very small/simple web application in ASP.NET MVC with ADO.NET Entity Framework. I hit the wall doing an edit of one record in the database where I had to include the unique id (primary key) inside the html as a hidden field. This was One Possible Solution based on a question I asked here.
I am afraid this might open my database for other people editing other records of that table.
Will MVC take care of this security risk internally?
Tampering with the ID can occur on the client-side no matter what server-side technology you use. As others have suggested, some form of authentication/authorization scheme can be used to check privileges prior to user actions.
If you don't forward the ID back to the server for your action to use, you won't be able to tie user actions to server code.
Nope, that's something you have to take care of. But this isn't really a "secruity" issue if you check the user's rights
before he sees the View the first time
and before the DB Update is invoked
A "hacker" could then still edit the hidden-field "id of X" to "id of Y". The check should forbid this if he isn't able to edit "Y". If he could edit Y initially he can just claim "I changed X by using the view of Y - although I could have used he view for X, too".
As others have said, item ID's are not in themselves a security risk.
But to answer your question as stated, hidden fields pose the same security risks as visible ones.
Coming from webforms I was thinking the same thing as you. You always need to build in some server-side code to check edit and delete. The problem I had was that users could delete items from other users just by changing the source code. To prevent it I just had to check if the user was deleting items that belonged to him.
Hidden fields are often used to include an ID for editing. Just check to make sure the user is allowed to edit the row in question when the post is received server-side.
my suggestion for that is use uid which is a unique 32 bit unique identification number for a record . so your database is guarded because if a user see that uuid in hidden field . he can not guess the other id of that table as they are unique and random
The MVC framework will NOT clean up after your hidden field. Your ID is not a huge risk, having things like delete links would be.
Carry on, I'd say.
Kindness,
Dan