Using Orchard Core, is it possible to add fields to a User?
For example the company they're from, or some sort of preferences?
And then allow the user to change some of them, while keeping others read-only or hidden?
Related
An existing bill has an approval record, due to normal approval map. With the help of SQL, I updated the value EPApproval.ownerID, and assigned a new approver. Next, I logged in as the user who is associated with the updated owner ID. Finally I can Approve the bill. I wanted to see if it's possible to achieve the same success via ACM Framework. The client has some cases in which an employee delegate must be assigned as the document approver. Currently it isn't possible to edit the approval record via UI.
Probably you are aware of this, but in Acumatica it is possible to approve the following documents:
Those assigned to you.
Those assigned to other users of your workgroup.
Escalated documents assigned to users of workgroups that are at lower levels in the company tree but in the node of your workgroup.
Refer to https://help-2018r1.acumatica.com/(W(2))/Wiki/ShowWiki.aspx?pageid=1fe1afcc-e676-466e-8c3f-cbf64857e32a
Therefore, it might be possible to achieve what you need through the use of workgroups and proper configuration of the Organization Chart.
Unfortunately, Acumatica does not have delegate functionality. You might consider upvoting this entry on the Acumatica Ideas site (as it has already been raised previously): https://feedback.acumatica.com/ideas/ACU-I-2162
Regarding your question on whether it is possible to change the Approver, you should be able to develop this as a Customization. For example you could consider doing a Custom screen (or perhaps customize an existing screen) from where you can add this functionality. You can consider using PXDatabase.Update as well to update the entry (although this shouldn't be used in case you are doing a solution which is to be ISV certified)
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.
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.
I am new to share point and still learning all the best practices, but I have a parent site called "Clients" and a sub site for the each of the clients i.e. Walmart, Kmart, Target. Is it a best practice to have a unique document library for each of the sub sites and the parent site. Or to use just one library for all of them. And if I were to use just one how would I set that up?
Thanks
Sites and Pages are not the same!!!
I wish that was more clear. In this case I want a SITE with the customers. Then each customer will have its own page. This way I can use the same apps across all the customers. I will probably need to learn how to create a customer template next.
to start with you need to answer few questions first, and these questions will help you to decide on an approach.
Do you have unique documents per client
will you control access to your users, that is each subsite will have unique permission, users for one client say for instance walmart should not access documents of Kmart
what would be tentative size of each documents and how much will that grow over the year
above are few question which will help you to get started, being said that, I will start creating a site and if the look and feel are the same for my other clients with little changes, then save the site as template.
This template will be my base for other client subsites/ sites.
will also create a global document library, which will store relavant documents which can be sharable across subsites
If required, each client will have their own subsites and own libraries for maintainabilty. this will also help to move subsite to its own site collection if there is hugh growth in data for a particular client.
You can also plan to use search, and webparts like content search query webpart to mashup data from subsites.
Another area to explore is metadata and Information architecture.
When you ask "Is it best practices" for the multiple Libraries or a single Library. From what you have described and Ramakrishnaraja was trying to say, you need to figure out what would work best for the situation. I don't know if you mean to have a different group called "customers" or if that is the same as "Clients" I'm going to respond assuming you mean both parties are the same.
Ramakrishnaraja points out that you have one central log on page "Clients- 'Main'" which leads to the other pages. If you want to the users to be divided into groups that have access only to the documents within their repective page then you should create multiple Document libraries. If you want the users to have access between the sub pages and use/edit files between the sites then best practices would be to have one Library for the Site.
I hope this helps you. Ramakrishnaraja makes a lot of good points and approaches it from a design overview rather than a specific response to your situation so try to use his post from that perspective.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
we are just going to start with XPages and i have the following questions:
We have a system composed of several Notes databases. Now we all want to add a XPage, so that can be edited in the browser and the client.
What is better now:
A database with the XPages and programming and data are fetched from the other databases.
All databases get the XPages and are addressed individually via a navigation.
For me, what is better for performance.
Best practice is to store all XPage design elements for each "application" in a single NSF. This can be the same container as some of the data, or it can be a separate NSF entirely. But what you should definitely avoid is storing XPage elements in separate NSFs just because the data happens to be stored in several NSFs.
Rather, within XPage applications, the data should always be considered philosophically separate from the user interface, even if it is stored in the same NSF. This philosophy makes it easier to design modern, intuitive user interfaces for applications without constraining these design decisions simply as a result of how the back end data is structured.
The ACL of each NSF is still honored, so if you have imposed different access levels for each database, the user will still only be able to access content to which they have access based on the ACL of the NSF that contains each record, regardless of the ACL of the NSF that contains the XPage design elements.
One rather specific performance consideration is that both the application scope and the session scope are unique to the NSF that contains the XPage element a user is currently accessing. As such, if your application consists of 6 databases, for example, and you split the XPage design elements across those databases, you will be unable to cache configuration settings, or other computationally expensive queries, across all of the applications. If, conversely, all of the XPage design elements are in a single NSF, you have a single application scope. Each portion of the user interface, therefore, can access information already cached by any other portion of the interface -- spanning not only different pages within the app, but spanning users as well: if data that is retrieved for one user should be the same data returned to all users, caching it for one caches it for all.
Similarly, since the user will have a different session scope within each NSF they access, any user preferences (or behavior) that is applicable in all areas of the app would be forgotten as the user navigates to a different NSF.
Storing different XPage elements in different NSFs just because that's where the data is removes these, and other, opportunities for performance and interface optimization. It might feel simpler for those new to this type of development to segregate the design, but ultimately the end user experience is bound to suffer, potentially in ways of which they'll be consciously aware. But usually they'll be confused and frustrated and unable to pinpoint exactly why.
In short, here's the best way to determine where each XPage should be: if an end user navigating from one XPage to another would assume that they're still in the same app, then both should be in the same NSF, regardless of the location of the data each XPage accesses.