I have:
a custom content type: FooBar (folderish)
a list of users subscribed to a FooBar item (so a list of users ids for each FooBar item) - FooBar members
I need to have the possibility to allow access to FooBar contents (child items) only for FooBar members (subscribed users in FooBar item's context).
The list of subscribed users is changed multiple times (when a user is approved, rejected, deleted etc).
So, the permissions will be automatically updated in order to give access to particular files only to FooBar members.
Also a member of FooBar item A will not see the contents of FooBar item B only if he subscribes to B, too.
What is the best solution in this case? Will I create a plone group of users for each FooBar item or is there a simpler solution?
Related
I like to include the entities in the paths generated by ApiPlatform.
In practice, I want the build URL contains the IDs of the "parent" entities, the ones to which belong the entity I'm retrieving.
As in the object, I'd like URLs like those:
/{account_id}/channels: here the Channel entity has a property Account $account with a many-to-one relation (one Channel can have only one Account but one Account can have multiple Channels)
/{account_id}/{channel_id}/another_entity: here I want to retrieve AnotherEntity that have property Channel $channel (it may have also the property Account $account, but it may not have it).
How to build those URLs?
The idea is to permit the User to have multiple tabs open with different accounts, without force him/her to see one account a time: I want the User be able to open at the same type Account 1 and Account 2.
Ideally, on each {account_id} should be a check that confirms the User has access to the Account in the URL (starting from its ID).
Understanding the speed of Firestore reads, I'm curious what others Firestore users do when they need to take a current object (in my case a user) and see how that user relates to many other objects (other documents).
My use case currently is a user signs in and goes to see a list of items (5 items on initial page load). Each item has many options like "Liked" or "Favorited."
To see if a user has liked each item, I can either store a single document containing a list of all items a user liked for each category of items, or I can make a call to fetch the document storing the "user A liked item X" which would be numberOfItems * numberOfValues (e.g. 5 items, each item has 3 different boolean options).
Curious what others do in this case to keep document read count tamed.
Let's say I have the following structure: Users have Companies which have Products. To determine if a Product is available, I need to check if the Product, Company and User are all active (and likely other checks).
If I'm working on the voter for Products, should it check to see if the Company and User are active or stick to just checking if Product is active (thus I'd have to do 3 checks in the controller)? If the first option is better, how would you go about doing that – is it possible to call a voter inside a voter?
I have SharePoint O365 subscription in which there is a private site collection. In that site collection there is a site with a list named xxx with columns (a,b,c)
I want to enable any user ,with anonymous access to a page (like in the public site of O365), to search with a column "c" and be able to update all the columns (a,b & c) and save that record.
What is the best way to achieve this?
Suppose I have chatrooms as part of a Meteor app, and inside each chatroom the users should see who else is in the chatroom, as well as the number of users in all other chatrooms.
Where should I store the chatroom that each user is in? Should it be
in the provided Meteor.users collection, as a property under each user?
in the Chatrooms collection, as a list of users inside each chatroom?
What's the right way to denormalize the data so that a user can see the number of people in other chatrooms without needing to get pushed all of those user records as well?
A related question: when should I store things in Meteor.users() as opposed to a separate collection containing documents of user IDs and rooms, such as ChatroomParticipants? i.e.:
{ user: "foo", room: "room 1" }
{ user: "bar", room: "room 2" }
Additionally, is there a way to set this up so that a user can be logged in to the same app from multiple windows and be in different rooms? That is, the rendering for a particular user does not depend on some global state that makes everything change across sessions.
You should make it write on Meteor.users document in that case. The less you centralize read/write in only one document, the better, so it won't be a bottleneck. See how meteor-presence make it on the Advanced Usage.