I'm not sure where to ask this question, I'm hoping it wont' be closed as "off topic" or "opinion based". If it turns out to be that, can you please suggest where this question can be asked instead?
I have a very specific set of requirements for custom list management tool I'm trying to find:
Custom lists, ability to add new custom fields easily
Ability to use either predefined set of values (combo box) or free form text/numeric/etc fields
Ability to validate entered data via regex
Data in the list is version controlled
Lists are group/role-based permission controlled (only certain lists can be updated by certain people, certain people can only READ data, but not update, etc)
Rest web services to update list data via a script
An example of such tool is SharePoint, but I find it very difficult to work with. Looking for something similar in the Linux world.
Related
I am trying to figure out a way to create a secure data entry process using Microsoft Office (cannot use Azure by the way). The obvious way is to use Microsoft Forms, but the form would be too large as there are over 150 data points that need to be entered.
I have instead created an Excel file that has the ability to load responses to a SharePoint list. This works as long as the list is public and viewers have contribute privileges. The downside to this is that the data is not secure and anyone can view the list. The data has phone numbers, ssn, passports, etc. I tried to make a work around for this by creating a flow that captured any new entries and moved them to my personal private SharePoint list, then deleted the original. This works great, but after testing with my colleague it seems that anyone can join the first team and make an identical flow to that team to capture data themselves.
Is there a way to accept data from anyone internally while also preventing them from accessing the data? I am capable of using SharePoint, Teams, Power Automate, and Access to accomplish this. I am less familiar with access but have used it before. I'm just not sure how secure it is.
I'll be happy to provide further information as needed. Thanks
You could consider Access forms, and then have the tables reside on SharePoint.
You can then say base the form on a query, and in that query you could provide (have) the user name included as part of the query where clause (thus a user removing or changing the forms filter will only provide a view of their own data.). However, such uses if they fired up Access (or even Excel) could wind up with seeing all rows in the table and not what the Access query restricts the data to (the one user).
Unfortantly with Access desktop? And like most desktop software? Well the goal and design and history is that of allowing ease of data editing and viewing. So, just like when you walk into a bank, and wait in line? Well, when you get to the teller, they will fire up a access form based like system and pull up your account information. And any and all tellers can see/view and pull up that data because that is what the software supposed to do, and do well. (get at any customer data).
Now, flip this problem, and create a user web banking system, or even a instant teller. Now the problem is backwards. The software's goal is not ease of editing data in a table, but ONLY allowing the user to see THEIR data. So a very different kind of problem.
It is very (beyond very) to note that web development tools do not out of the blue or automatics restrict data to JUST the one user. It is YOU the developer that makes that choice. So, if we could press a button and have a access form converted to the web? Well, then that access form would do its job in life. That job is to allow you to edit all that data in a table. Not just YOUR data.
For example, have you ever written a Access application that JUST displays each users own data? I am betting not! It is hard to do. (because the roots of Access is ease of editing data). As noted, I cannot stress that web development tools do the SAME thing. They can let you edit data. The editing of data is thus a software issue and development issue. The data system or Access or even SQL server? They just hold data. It is YOUR software that has to decide that ONLY data for the one user is to be displayed.
Now so very often web systems ONLY show YOUR data. But that VERY common case is due to the nature of web systems, and that your not a bank teller, or a company employee, but that of a consumer of that system. And each consumer now is 100% opposite of what most software systems do naturally (that is get data from a table).
So, I can't stress this concept enough. That concept is that web software and systems do NOT make this restricting of data choice for you. It is your developer tools that MUST have this ability and ALSO the choice of how you build such systems.
Web systems can do this data restricting data better for several reasons.
One big reason? Well, most of the time you adopt some kind of security and logon system.
Thus, parts of the web site now are restricted based on your logon system. (hey, maybe you use Facebook logons). So web systems have a very good and wide and broad system of supporting some kind of logon system. For desktop software? not so much.
But EVEN with that very robust and type of security system and logon system?
You the developer STILL have to make the choice of what data they see. Maybe it is traveling salesmen on the road. And thus every user of that web system still has to be able to edit, view and add customers to that system. This common case is not really different then a typical Access form to edit data.
So only SOME types of web applications need that restricting of data to JUST the one logged on user. But, because web systems have that "better" logon system? Then you the developer can thus now use that logon to restrict data with greater ease then what desktop software dev tools often offer (say like access).
So, a lot of this will come down to the web tools used. If you pulling data with Excel, or Access? Then it considerable more difficult to pull JUST data that belongs to a given user. And your software will require designs from day one with these restrictions in mind.
Again, at the risk of repeating myself?
the tools don't' make the data restrictions for you. If you need secure data for ONLY the given user, then you simply have to adopt a set of developer tools that allow this concept in mind. And that tends to mean the tools you use do NOT by default allow users to directly edit or link to some big table of data that contains all users data.
This is also why say a program written in VB6, or now vb.net can be more secure then Access. (because those tools by default don't provide forms that are designed from day one to edit all rows of data). So, the UI does not present default forms and things that gives users the ability to edit all rows. As a result, then the software can now control what records the users sees, and since they don't' have some default form that allows viewing of all rows.
It thus becomes more practical to write software that only dishes out their own data. But again, and I can't stress this:
The choice of what data to display is a choice of the software developer - not the database nor the web development tools.
It thus stands to reason then you have to chose the appropriate tools that will allow you to write software that restricts the data in a manor you require.
General questions on SO in regards to what flavor of ice cream or what dev tools to use tends to be frowned upon, and is quite much against the general rules for solving software and code issues you have and post on SO.
But, if you come from say Access with VBA skills? Then I would suggest adopting the free verison of Visual Studio and go with vb.net + asp.net web forms. Web forms are close to end of life, but they are by far and away the best choice, the least effort (coming from Access) and will give you a robust security model in which you can restrict data on a per user basis.
I would not duck tape and try to cobble together such a system with office tools, since they are not really designed for that type of data restricting you need. So, go with some good quality web tools like Visual Studio (free version is fine) and use SQL server (free version again) is really the way to go here. If you need a truck in place of a car, then get the right kind of truck, and don't try and use a car for that transport of goods, or in this case build a secure web database system.
I have developed a program using curses, everything is cool so far but I was wondering myself if there is a good pattern to split different views/panels of my program into smaller chunks callable by my main loop?
Further informations:
This program is a rather small automation tool/wizard aiming to ease our application for customers requiring the on-premise installation.
This wizard is a 3 steps one and it’s used to grab informations from our customer installation needs depending of it’s chosen architecture.
The first step is requesting the customer to give us its identification informations such has contract number, company name, licence number and preferred contact.
The second step is requesting the customer to give us informations about either he want a standalone installation (All-In-One install) or a N-Tiers installation plus the required informations like the requested custom SSL VHostName or Tiers IP/Credentials.
The third and final step is showing the customer a progress bar and informations of the required services (MySQL/HTTPd/HAProxy/PHP-FPM) and our application.
I know that I do not especially need to use curses library for such a program but our UX Team requested it as it is part of our customer experience with the solution.
You can look at the Forms library. It's a nice extension to ncurses that allows you to better manage input forms like yours. It offers a simple function interface to read the fields, change their properties, etc., as well as many different field types (including regexp-validated fields). In your case, you can simply create three forms, and post/unpost them in succession.
as such way to do things is not really usual, do not expect any framework to be available (like those available for WebUI for instance).
I so decided to create my own "Framework/factory" and so to be able to split every aspect of my app in a logic that would be similar of those used by web applications.
The source-code is dirty and really not pythonic, but it is well working so far and quite easy to maintain.
Thanks everyone for your answers and ideas.
QUESTION: /etc/password has a comment field for the users, which is great because it allows a comma separated list of variables that can be used for other purposes. /etc/group does not, so where can I store a group description and additional information.
BACKGROUND: basically we have a custom file server that can use posix permissions to share out volumes. We also have a custom web based GUI for doing things like deleting volumes, adding users and groups... lots of stuff. This is an appliance (like cisco ACS is an appliance), not a live webpage. I am basically trying make user management for the web based GUI and POSIX one in the same... so I need to store a few additional pieces of information for, say, 'group1 is allowed to delete this volume using the GUI... as log as I have a comma separate list, it should provide what I need (I have this for users, but not groups). I'm going thru these hopes because this is an appliance; as such, everything the appliance actually does for the 'user' is handled via system files, and the GUI just serves up that data and allows the 'admins' to modify it. There is a Database between the GUI and backend, bbut the overall architecture pulls information from the OS and serves it to the DB, which the GUI accesses... 20,000+ lines of code use this philosophy, so I would like to maintain it for user and group management, even for settings that are specific to our GUI.
We're starting to use SharePoint 2013 to manage our department's process documentation and I have some questions about best practices for site structure. I'm a little surprised I can't find the answers via web search, since this seems like a basic question every new SharePoint user must deal with.
Moving from a file share environment, I'm trying hard to get out of that mindset and I understand the many benefits of SharePoint over file shares. I also understand why creating folders in SharePoint forces arbitrary divisions on files whereas one large set of documents with metadata lets you filter and group the files based on different needs.
What's confusing me is that I also read that it's better to have too many sub-sites than not enough. It seems like sub-sites can easily become pseudo-folders and I'm not sure where that line is crossed.
Here's an example.
We have a SharePoint site devoted to our department. We've create a sub-site dedicated to an application we developed to load data into our business systems. It mainly holds technical documentation about the application. This application supports many different data sources, each with its own set of user instructions for loading, its own schedule (calendar), contact lists, supporting files, etc. There's no compelling reason to separate them to restrict access. However, there doesn't seem like a lot of value in having them all in the same sub-site, either, since someone working on a job will only want to see the docs and supporting files for that data source. I just can't foresee someone wanting to view supporting files across all data sources, although, I could see someone wanting to see the schedule for all data sources combined.
My question is, should I create separate sub-sites under the application for each data source or do I just store everything in the application sub-site and use metadata and views to group things by data source? Putting all the items for a specific data source into its own sub-site seems to be much simpler to manage and present than having to specify metadata for every new file and creating a lot of views. However, I can't shake the feeling that I'm still using file share thinking. Or maybe I'm just missing some basic concept of SharePoint.
Any advice or links to good discussions of this topic would be greatly appreciated. Thanks.
I would recommend that you use metadata and views to separate data in one repository/site.
My reasons are as below:
In SharePoint, it is recommended to use metadata than "evil"
folders(or subsites in your case). Keep in mind that maintaining
multiple subsites requires big administrative efforts in long term,
for example, some sites will be inherited while others unique
permission.
As time passes by and people rotate, it becomes vague
that where the data was stored and where the new data should go to,
especially with large volume subsites.
Since confidentiality is not concerned in your case, keep data centralized and open to people working in related field increases sharing and collaborating phenomenon. In contrast, using subsites increases the possibility of data silos.
people are all lazy :). Taken me as example, I dont want to remember all those xyz URLs, I want to go to one place and be able to fetch everything that I need.
I am still a relative newcomer to Expression Engine as a developer and a user. I am faced with the problem that a lot of my knowledge is being passed to me by users who have found ways to accomplish tasks traditionally undertaken by developers (eg product libraries) by using the channels system.
What I wondered was what people's views are on when it is best to advise a client to use this and when not to.
Let me use an example, a client wants a system which had venues where events could take place. The previous developer had chosen to use the membership system for the venues and the channels system for the events and write some custom code to attempt to knit the two together, specifically because there are not enough hooks to accomplish some background automated tasks like looking up the long/lat of the address of a venue when it is created or updated.
I am picking up after someone else's work largely but its not their fault, it was the information they were given as they were also new to the system.
In any other project this would be a master-detail type setup, events belong to venues, i'd probably write 2 custom tables, editors in the admin area via modules and then use regular custom code in the pages to display and act upon the info - this way, I could control what's happening when a user hits submit.
However, the instigating party is a veteran user of Expression Engine and instructed the previous developer in the manner of "oh, just put it all in the channels and then there's this tag and that tag and so on".
So, am I missing the point or am I right that this does not fit the channels system and when should you use channels and when not?
Thanks friends.
This question is very hypothetical and every developer will give you a different answer as it all depends on the requirement and how that EE developer rolls.
Fundamentally ExpressionEngine allows you to approach builds in many ways, none are right and wrong, albeit some are easier, some harder, others just plain daft.
Basically Channels are groups of data "entries" - these can be anything. Using your example, venues could be one channel with fields created relevant to the subject (e.g. location, size, price, etc). And another channel for events with different fields (e.g. date, type, location).
Mostly anything can be slotted into a channel. But member details are best held within the native member functionality (although there is a commercial add-on that holds member data in a channel).
You reference the previous developers approach - this could be because they used a third-party add-on that required the data to be held separately to channels, or a lack of understanding on best approach. Or just because the developer decided to approach it that way! I suspect the last developer then associated a member (venue) to an entry (event) to link the event to the venue. Basic EE functionality allows for related entries which allows you to associate 1 entry with another (e.g. Event -> Venue), or using the excellent Playa add-on, so this approach is really not necessary.
Personally I would always store the data in channels, and people/members in the native membership functionality (e.g. admin, visitors to the site, customers, etc). I'd only build an add-on (utilising it's own tables/data) to store additional information if it was way outside what EE could store.
To answer your practical question (it's stretching the scope of what Stack Overflow questions are supposed be honestly): you should use a channel for Venues and channel for Events, and the Venue field in the Event entry is a "Related Entries" fieldtype linked to the Venues channel. That's the "standard" EE way, and the most similar to a traditional database schema.