ayanova/devdocs/todo.txt

@@ -1,18 +1,3 @@
-@@@@@@@@@@@ ROADMAP STAGE 2:
-
-PRIORITY - ALWAYS Lowest level stuff first, i.e. TODO at server, api route changes etc then back here in order lowest level first as affects the most stuff exponentially so best to do it early
-
-=-=-=-=-
-
-
-
-todo: Test run on v7 laptop
-	https://www.ayanova.com/Downloads/v8/ayanova8.alpha.8-win-x64.zip
-
-
-todo: UI for restart serial number route for widget?
-	Not tested nor ui'd yet
-
 
 =========================================================================================================
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@ -21,74 +6,17 @@ todo: UI for restart serial number route for widget?
 
 This stage is to consolidate the basics and set the final shell form.
 	A lot of it might be rundundent
-	GET THROUGH THIS QUICKLY, REPORTING IS THE GREAT UNKNOWN THE SOONER THE BETTER SO CAN FUCKING GET ON WITH IT ALL
-		reporting might take weeks so need to get to it as soon as fucking possible, it's the final thing before cranking out a demo etc so pretty critical
 
-TODO: GRIDS I'm still on the fence with the grid sort and filter system
-	Filter is ok, it's complex and people don't expect it to be super easy, but sort is a bit of a palaver
-	Column visibility selection is also ok and not used enough to really support it on the outside so that could stay
-	Sorting is the big issue, seems ugly to sort by going into the component when it's such a common need out of it, but we could live with it if necessary
-	TTM rules this decision maybe but usability is a big one here too
-	it seems too difficult to make a quick sort change, can it be supported to just click on column headings?
-	Maybe need a hybrid grid that can be used to select columns and order and filter but sort order is on the outside
-		And can turn off column selection if it's a simple thing so you get all the rest built in but don't see the filter list nor filter icon if set to that mode
-		This way can use it all over and where appropriate
 
 todo: Go through all cases, just glance over them and make sure nothing was missed that impacts the basic shell stuff before I get into the real world objects
 
 
 
-todo: INVESTIGATE / REDO THE TOP LEVEL SHELL - TIME TO MARKET / Is my shell layout fucked?
-	- wouldn't it just suck to have all those lists exposed at once in inventory?
-		- Opening that page once they are all there would trigger huge traffic to the server, better to confine things to their own area as much as possible
-	- TTM: isn't it faster to just turn the menu into a tree like v7 or put options in each one's screen? (Like inventory page just shows a bunch of other icons to open details like widgets)
-	- TTM: I'm concerned that the modular UI is a bit too ambitious, yes it makes sense for re-usability but exposing it to users so they can redo their UI seems crazy ambitious at this point
-		- People just want to work and simpler is always better, less to maintain
-	- How about the easiest simplest layout possible even if it's a bit uglier but keep it all clean and focused instead of too much shit on each form?
-	- Really, for maintainability it makes sense to have a very simple clean layout and not try to put a bunch of complex controls all over the fucking place!!
-	- I need to make money from this, not win prizes for design!
-	- Easier to show or not things for authorization purposes when they are each in their own navigation path as much as possible
-	- users are used to a certain thing with v7 why re-invent the wheel, just clean it up and modernize where necessary
-	- There are so many other things I need to focus on, this is just adding complexity in an area that might be a nightmare to maintain and troubleshoot.
-	- DON"T get too fancy with this, my instinct is to make it more complex all the time, but actually ugly and simple and effective is better than pretty but fucky to use
-		- Also, mobile really doesn't go well with fancy but more with clean and simple.
-	- Sounds like my minds made up, this issue is more about changing the SHELL UI
-	- IDEAS:
-		- old fashioned switchboard kind of thing, big buttons for each area sit in a row, on mobile they are vertical full width?
-			- ugly but effective		
-			- Alternative is a Tree control in menu instead, but that would likely be ugly in mobile(could investigate but it's not common probably for reason, look at material apps on phone see what they do)
-		- Don't worry about having to navigate too deep with too many clicks for the top level, yes some won't like it, but it's more important to focus usability and minimizing clicks in the actual path that day to day users take
-			- In other words make the most common tasks quick to do from the top level / HOME screen perhaps and *thats* where to focus on customization so users can surface what they want there as a LINK 
-			- Users can modify what shows by default in the home screen but not the fancy active widgets I had envisioned but instead different task based buttons / links so they can get to where they need to go quickly
-				- e.g. click on inventory, select the Widgets switchboard button, the widgetlist opens full screen to the right side, one of the menu options is "Add to home screen" with a favorite button
-					- They click on add to home screen and next time they are on home screen a new button / link is there to that item, autoamtically pre-grouped by area of functionality or maybe they can just order it how they see fit?
-		- I really like the idea of the widgetlist being full screen to the right rather than in a component sharing that space as it's pretty necessary 
-		to have a lot of columns display at times, yes it's a ui made up of a bunch of lists but that's really what people understand, it's appropriate to the application, 
-		no business software can simply hide everything and it doesn't have to suck or be ugly			
 
-todo: test error conditions with dev mode off
-
-todo: Clean up TODO list, have only actionable, not completed items.
-	- Make a to_test.txt doc so can move todo's to to test doc for testing
-	- anything in this doc that isn't related directly to individual todo's other than a small big picture stuff at top sb elsewhere
-	- Idea is to have a focused, clean actionable list here.
-	- Prioritize any basic stuff that will be replicated over and over again
-		- i.e. regular edit forms, not schedule or workorder form which will require their own separate work and are not replicated 
-		- want to get going with all the background object types like clients and users etc before I try to make the schedule and workorder forms
-	- Identify any unique time consuming items and put them in their own block of todo's 
-		- Self serve server stuff
-		- workorder form
-		- Accounting integration and other plugins
-		- import datadump etc		
-	- There is a lot of crap at the bottom of this document in this todo!
-
-todo: INVESTIGATE - DO I need to institute a back button? (in APP MODE?? installed to "desktop" on device will I be able to easily navigate without back and forward buttons)
-
-
-
-
-
-todo: MRU
+todo: MRU / HISTORY
+	- Make the personal history available under the HOME menu area
+	- When user clicks it takes them to their own personal activity list for their user id
+	
 	- is this covered by history adn should it just be a quick link to personal history instead?
 	- MRU in dashboard...where? https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3723
 	- GOOD case here with two great ideas (using "audit log" event log for mru or AS mru and doing it all locally (which I am, no MRU at backend))

ayanova/src/api/authorizationroles.js

@@ -114,11 +114,22 @@ export default {
     //get the logged in user's role
     let userRole = window.$gz.store.state.roles;
 
+    // console.log("Authorization roles getRights, userRole=", userRole);
+    // console.log(
+    //   `Authorization roles getRights for ${typeName} objectRoleRights=`,
+    //   objectRoleRights
+    // );
+
     //calculate the effective rights
     //a non zero result of the bitwise calculation means true and zero means false so using !! to force it into a boolean value
     //(contrary to some style guides that say !! is obscure but I say it saves a lot of typing)
     let canChange = !!(userRole & objectRoleRights.Change);
-    let canReadFullRecord = !!(userRole & objectRoleRights.ReadFullRecord);
+    //sometimes rights to read are false if change is true since change trumps read anyway so accordingly:
+    let canReadFullRecord = canChange;
+    if (!canReadFullRecord) {
+      //can't change but might have special rights to full record:
+      canReadFullRecord = !!(userRole & objectRoleRights.ReadFullRecord);
+    }
 
     ret.change = canChange;
     ret.delete = ret.change; //FOR NOW
@@ -132,6 +143,10 @@ export default {
   //
   canOpen(oType) {
     let r = this.getRights(oType);
+    // //Am seeing where change is true but read is false, change trumps read so ...
+    // if (r.change == true) {
+    //   return true;
+    // }
     return r.read;
   }
 };

ayanova/src/api/initialize.js

@@ -174,6 +174,14 @@ function initNavPanel() {
       });
     }
 
+    //HISTORY / MRU / ACTIVITY (personal)
+    sub.push({
+      title: "History",
+      icon: "fa-history",
+      route: `/history/3/${window.$gz.store.state.userId}/true`,
+      key: key++
+    });
+
     //SCHEDULE (personal)
     sub.push({
       title: "Schedule",

ayanova/src/views/ay-history.vue

@@ -194,6 +194,10 @@ export default {
       });
     },
     canOpen(otype) {
+      // console.log("Canopen type: ", otype);
+      // console.log("Openable:", this.ayaTypes[otype].openableObject);
+      // console.log("roleCanOpen", window.$gz.role.canOpen(otype));
+      // console.log("Role rights to type:", window.$gz.role.getRights(otype));
       return (
         this.ayaTypes[otype].openableObject && window.$gz.role.canOpen(otype)
       );