I have a share-point list with which I want to implement three things:
Freeze some columns so that their data can be edited by specific people only like the ones within site owners group with full privileges.
Hide some columns according to some user groups. Earlier I did this by creating two views, one with limited columns selected and visible to all and one with all columns with filter Restricted_user = [Me] and I have put all users' names from active directory in that field, but I guess it has security loopholes like someone could see all row data by selecting view item and everything in that row will be visible to him.
2.1. If my own second option approach is selected can I implement this comparison with group aliases, rather than individuals so that I have to put only group aliases in that column field, rather that all names in that group aliases.
Last but not the least can i break up list rows into two categories so that two different groups can access and edit their own data only.Eg. 20 rows are there 5 accessible to group1 and 15 accessible to group2 but they cant access each others data rows.
Apologies for long question.
The most secure way to accomplish #3 is using item level permissions. Less secure ways include custom views and audiences.
For #1 and #2, you will need to create custom field types. Out of the box SharePoint list columns do not support column based security.
Related
This is complicated and difficult to explain, but here it goes. I have created a db that works just fine. It is a time saver, but not efficient for the user. I have a form for the merchandise where the user selects a paper type from a combobox. They are presented with two choices. They must also select a print size from another combobox. They are presented with 5 choices. I have VBA code that creates a SKU number based on these selections.
An art piece can use both paper types and be available in all 5 sizes. What I am trying to figure out is how I can offer all the possible choices on this form, allow the user to select options for that piece. As an example, the user chooses both paper types and all print sizes. This would create 10 SKU numbers for one art piece. Below is a copy of the form in it's current view:
Is this possible to do from one form? If so, how can this be accomplished in the most efficient way? I feel that it can. In VBA, this would be an IF nest nightmare, especially when concatenating the SKU variables. Either Select statements or another method that I am unaware of, could be the solution.
Thanks in advance for any and all suggestions and assistance.
EDIT: I hope this helps clarify. I would prefer to use this form
to complete the task. The checkboxes are not in an option group so they could all be checked if the user requires it. For the purposes of this question, let's assume the user has checked all the boxes. This would equal 10 total combinations.
I run this sub to generate a SKU based on the paper type and the print size:
Private Function UpdateArtwork()
Me.MerchandiseSKU = Me.cboArtworkID_A5A.Column(5) & _
Me.cboPrintTypeID_A5A.Column(2) & Me.cboPaperTypeID_A5A.Column(0) & _
Format(Me.cboPrintSizeID_A5A.Column(0), "00")
Call UpdateArtworkPic
End Function
I am trying to figure out how to write the code for the new form that allows all 10 SKU numbers to be generated and create 10 new records for Artwork_ID (Artwork table).
I think that the best way of doing this would be to create a new table, called tblArtworkSKU, which has the following fields:
ArtworkSKU_ID - Autonumber, primary key;
Artwork_ID - number, foreign key from the Artwork table;
PrintSize_ID - foreign key from the PrintSize table;
PrintType_ID - foreign key from the PrintType table;
ArtworkSKU - text.
You would then create a small continuous form based on this table, with PrintSize_ID and PrintType_ID selected through combo boxes. When you place this form onto the main form that you have, Access should automatically let you join on Artwork_ID to create a one-to-many relationship.
You could then use the AfterUpdate events of each combo box to create the SKU.
Regards,
Essentially I am trying to model a character holding a backpack with items from a pre-determined list. So far I have come up with this.
My main issue is in understanding how core data handles Arrays/Lists etc. From what I have read that is determined by the relationship, a simple character - item relationship is what I first came up with but I wanted to be able to add custom descriptions per item selected from the pre-determined items (which can be added to by the user at runtime). Each character would have only one "backpack" with a list of items with custom descriptions and custom "amounts" or count.
That backpack could theoretically have 2 of the same items but with different descriptions hence having a count of 2 for the one item wouldn't always be appropriate.
Also, there is the option for multiple character profiles, so therefore the items could belong to multiple different backpacks, but again with difference in description/count etc.
So I guess my main issue is understanding how Core Data handles lists. And how i could properly address this issue to allow for a "character-backpack-item" relationship.
Thanks!
Short and quick clean-up:
1: Add the properties from item to your BackPackItem
2: Remove the itementity
That backpack could theoretically have 2 of the same items but with
different descriptions
3: Add a property backpackItemID to your BackPackItem and assign a unique ID to it each time you create a BackPackItem entity. That way you can have multiple items with same information but with different ID's. (Not needed , but keeps things more clean in my opinion, do as you wish here)
Finally:
Now all you need to do when you fetch is to fetch the Character entity by it's name for example. And in your NSFetchRequest you add the BackPackItem (associatedBackPackItems as the relation is named) as relationshipKeyPathsForPrefetching, and all the associatedBackPackItems will be fetched for you automatically.
Now let's say you have fetched a Character , and you want to access its BackPackItem --> character.associatedBackpackItems gives you all the items connected to that character.
I am aware that I can use "when" clauses in the allowed/suggested values of the field.
My question is : how do I get the group(s) that the current user is in and how do use this to select different lists?
Put a for="GroupName" or not="GroupName" in the <AllowedValues> rule(s).
You can have multiple <AllowdValues> rules. All "permitted" rules will be combined into one set of items.
I'm really struggling with this problem, would love some additional thoughts. Here's the basic context:
Users can both list items to be lent out, and make requests for items to borrow
Requests are posted by users who want to borrow something. Each request may contain several items
Items are predefined (i.e., POST form is a checkbox) and listed by users who want to lend them out, and are in turn borrowed by other users who have submitted a request
Workflow:
John is a user and submits a request for a tent from 6/5 to 6/8
The controller looks for all users (besides John) who own tents that are available from 6/5 to 6/8
This list of users are contacted to see who wants to provide a tent for John
Whoever responds affirmative to John first has their item in the table automatically updated to be no longer available from 6/5 to 6/8
John and the other user are connected to make the exchange happen
So far my thinking:
Users table has_many :items and has_many :requests
Requests table belongs_to :users
Items table belongs_to :users
Additional complexities that my brain can't seem to process:
One request can contain multiple items, and I've been told against accepting items as a serialized array in one cell, so then I'm not sure how to relate request and item. In the tables above, should items also belong_to requests? And if yes, this seems to imply that a user has to make a request for a specific item whereas I want the user to be able to search for tent, and see a list of all the users who have tents that are available
Requests contain start_date and end_date attributes, that somehow need to be compared to when the item is available. Right now I'm thinking in the items table, there needs to be a column that stores the dates when the item will be in use (i.e., not available). But then this data will be an array again. For example, a tent might be requested (and the user responds OK) from 6/5 to 6/8 and then again from 6/10 to 6/15, and then again from 7/8 to 7/9. So do I need a fourth table??
Items will be a predefined list, e.g., tent, sleeping bag, sleeping pad. In this way, I'm wondering do I actually need a has_and_belongs_to_many relationship with users, since a tent could belong to many users, and a user could have many tents.
Sorry if this sounds like a ramble... I've been sitting here for 4 hours with many sheets of paper and scribbles and this is not getting any clearer...
You need to understand the basic way of recording information relationally ie in tables.
Finding sufficient tables
Just have a base table for every statement you need to describe a business situation:
User(user_id,name,...)
// User [user_id] is named [name]
Contacted(contact_id,item,offer_id)
// user [contact_id] was contacted re item [item] offered by user [offer_id]
...etc...
The parameters of the statement are the columns of the table.
If you want to talk about the parts of something that you think of as having multiple parts (heterogenous or homogeneous) that just means that some statements will involve a thing and its parts:
table request(request_id,start_date,end_date,...)
// [request_id] goes from [start_date] to [end_date] and ...
table requested(request_id,item_id,person_id,...)
// person [person_id] requested item [item_id] in request [request_id]
What's in a table
A base table's value is the rows that make its statement true. (Every query subexpression also has a statement, and its value is the rows that make its statement true.)
Don't confuse table statements with business rules. Business rules state truths. But a table statement is a statement that some tuple makes true (and goes in the table) or false (is left out of the table). All the true and false statements from the tables tell you everything you need to know about the business. The business rules will never contradict them. (Since they're always true.)
Rearranging to better tables
A key is a set of columns that all other columns are such functions of but none of whose subsets have that property. A table can have more than one key.
To make a database easier to update and query you should break up certain statements that are other statements joined by AND. Break up until each statement consists of a statement only about key columns ANDed with statements of this form:
[my_column]=my_function([key_k_column_1],[key_k_column_2],...)
where key_k_column_1,... are columns of the same key key_n.
(Such a table is "in fifth normal form" and the topic is "normalization".)
I'm programming a website that allows users to post classified ads with detailed fields for different types of items they are selling. However, I have a question about the best database schema.
The site features many categories (eg. Cars, Computers, Cameras) and each category of ads have their own distinct fields. For example, Cars have attributes such as number of doors, make, model, and horsepower while Computers have attributes such as CPU, RAM, Motherboard Model, etc.
Now since they are all listings, I was thinking of a polymorphic approach, creating a parent LISTINGS table and a different child table for each of the different categories (COMPUTERS, CARS, CAMERAS). Each child table will have a listing_id that will link back to the LISTINGS TABLE. So when a listing is fetched, it would fetch a row from LISTINGS joined by the linked row in the associated child table.
LISTINGS
-listing_id
-user_id
-email_address
-date_created
-description
CARS
-car_id
-listing_id
-make
-model
-num_doors
-horsepower
COMPUTERS
-computer_id
-listing_id
-cpu
-ram
-motherboard_model
Now, is this schema a good design pattern or are there better ways to do this?
I considered single inheritance but quickly brushed off the thought because the table will get too large too quickly, but then another dilemma came to mind - if the user does a global search on all the listings, then that means I will have to query each child table separately. What happens if I have over 100 different categories, wouldn't it be inefficient?
I also thought of another approach where there is a master table (meta table) that defines the fields in each category and a field table that stores the field values of each listing, but would that go against database normalization?
How would sites like Kijiji do it?
Your database design is fine. No reason to change what you've got. I've seen the search done a few ways. One is to have your search stored procedure join all the tables you need to search across and index the columns to be searched. The second way I've seen it done which worked pretty well was to have a table that is only used for search which gets a copy of whatever fields that need to be searched. Then you would put triggers on those fields and update the search table.
They both have drawbacks but I preferred the first to the second.
EDIT
You need the following tables.
Categories
- Id
- Description
CategoriesListingsXref
- CategoryId
- ListingId
With this cross reference model you can join all your listings for a given category during search. Then add a little dynamic sql (because it's easier to understand) and build up your query to include the field(s) you want to search against and call execute on your query.
That's it.
EDIT 2
This seems to be a little bigger discussion that we can fin in these comment boxes. But, anything we would discuss can be understood by reading the following post.
http://www.sommarskog.se/dyn-search-2008.html
It is really complete and shows you more than 1 way of doing it with pro's and cons.
Good luck.
I think the design you have chosen will be good for the scenario you just described. Though I'm not sure if the sub class tables should have their own ID. Since a CAR is a Listing, it makes sense that the values are from the same "domain".
In the typical classified ads site, the data for an ad is written once and then is basically read-only. You can exploit this and store the data in a second set of tables that are more optimized for searching in just the way you want the users to search. Also, the search problem only really exists for a "general" search. Once the user picks a certain type of ad, you can switch to the sub class tables in order to do more advanced search (RAM > 4gb, cpu = overpowered).